[GitHub] [pulsar] merlimat commented on a change in pull request #5265: [doc] Improve Pulsar Administration load-balance

[GitBox <gi...@apache.org>]

merlimat commented on a change in pull request #5265: [doc] Improve Pulsar Administration load-balance
URL: https://github.com/apache/pulsar/pull/5265#discussion_r328191531
 
 

 ##########
 File path: site2/docs/administration-load-balance.md
 ##########
 @@ -6,96 +6,74 @@ sidebar_label: Load balance
 
 ## Load balance across Pulsar brokers
 
-Pulsar is an horizontally scalable messaging system, so it is a core requirement that the traffic
-in a logical cluster must be spread across all the available Pulsar brokers, as evenly as possible.
+Pulsar is an horizontally scalable messaging system, so the traffic
+in a logical cluster must be spread across all the available Pulsar brokers as evenly as possible, which is a core requirement.
 
-In most cases, this is true out of the box and one shouldn't worry about it. There are, though,
-multiple settings and tools to control the traffic distribution and they require a bit of
-context to understand how the traffic is managed in Pulsar.
+You can use multiple settings and tools to control the traffic distribution which require a bit of context to understand how the traffic is managed in Pulsar. Though, in most cases, the core requirement mentioned above is true out of the box and you should not worry about it. 
 
 ## Pulsar load manager architecture
 
-### Dynamic assignment of topics to brokers
+The following part introduces the basic architecture of the Pulsar load manager.
 
-Topics are dynamically assigned to brokers based on the load conditions of all brokers in the
-cluster.
+### Assign topics to brokers dynamically
 
-When a client starts using new topics that are not assigned to any broker, a
-process is triggered to choose the best suited broker to acquire ownership
-of these topics according to the load conditions. 
+Topics are dynamically assigned to brokers based on the load conditions of all brokers in the cluster.
+
+When a client starts using new topics that are not assigned to any broker, a process is triggered to choose the best suited broker to acquire ownership of these topics according to the load conditions. 
 
 In case of partitioned topics, different partitions are assigned to different brokers. Here "topic" means either a non-partitioned topic or one partition of a topic.
 
-The assignment is "dynamic" because it changes quickly. For example, if the broker owning
-the topic crashes, the topic will be reassigned immediately to another broker. Another scenario is
-that the broker owning the topic becomes overloaded. In this case, the topic is
-reassigned to a less loaded broker.
+The assignment is "dynamic" because the assignment changes quickly. For example, if the broker owning the topic crashes, the topic is reassigned immediately to another broker. Another scenario is that the broker owning the topic becomes overloaded. In this case, the topic is reassigned to a less loaded broker.
 
-The dynamic assignment is made possible by the stateless nature of brokers, so you can 
-quickly expand or shrink the cluster based on usage.
+The stateless nature of brokers makes the dynamic assignment possible, so you can quickly expand or shrink the cluster based on usage.
 
-### Assignment granularity
+#### Assignment granularity
 
-The assignment of topics/partitions to brokers is not done at the topics/partitions level, but done at the Bundle level (a higher level). The reason is to amortize the amount of information that you need to keep track. Based on CPU, memory, traffic load and other indexes, topics are assigned to a particular broker dynamically. 
+The assignment of topics or partitions to brokers is not done at the topics or partitions level, but done at the Bundle level (a higher level). The reason is to amortize the amount of information that you need to keep track. Based on CPU, memory, traffic load and other indexes, topics are assigned to a particular broker dynamically. 
 
-Instead of individual topic/partition assignment, each broker takes ownership of a subset of the
-topics for a namespace. This subset is called a "*bundle*" and effectively it's a sharding
-mechanism.
+Instead of individual topic or partition assignment, each broker takes ownership of a subset of the topics for a namespace. This subset is called a "*bundle*" and effectively this subset is a sharding mechanism.
 
-The namespace is the "administrative" unit: many config knobs or operations are done at the
-namespace level.
+The namespace is the "administrative" unit: many config knobs or operations are done at the namespace level.
 
 For assignment, a namespaces is sharded into a list of "bundles", with each bundle comprising
 a portion of overall hash range of the namespace.
 
-Topics are assigned to a particular bundle by taking the hash of the topic name and seeing in which
-bundle the hash falls into.
+You can take the hash of the topic name and see in which bundle the hash falls into to assign topics to a particular bundle.
 
 Review comment:
   Using "you" here makes it sounds as an operation that will be done by a user/administrator, while in fact this is done by brokers.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services