Minor edits to the documentation

docs/configuration.rst

@@ -87,7 +87,7 @@ Customization of statistics settings
 
 Default configuration for Locust statistics is set in constants of stats.py file.
 It can be tuned to specific requirements by overriding these values.
-To do this, import locust.stats module and override required settings
+To do this, import locust.stats module and override required settings:
 
 .. code-block:: python
 

docs/developing-locust.rst

@@ -9,7 +9,7 @@ You want to contribute to Locust? Great! Here is a list of `open bugs/feature re
 Install Locust for development
 ==============================
 
-Fork Locust on `Github <https://github.com/locustio/locust/>`_ and then run
+Fork Locust on `GitHub <https://github.com/locustio/locust/>`_ and then run
 
 .. code-block:: console
 
@@ -53,7 +53,7 @@ Then you can build the documentation locally using:
 
     make build_docs
 
-Then the documentation should be build and available at ``docs/_build/index.html``
+Then the documentation should be build and available at ``docs/_build/index.html``.
 
 
 

docs/further-reading.rst

@@ -22,4 +22,4 @@ You'll also find a lot of answers on `stackoverflow <https://stackoverflow.com/q
 
 In other words, just google whatever problem or error message you're getting and you are likely to find good answers out there.
 
-If you think Locust is missing some obvious feature (like stopping after a certain number of iterations/requests, setting goals/thresholds for when to fail a test run, support for additional User types like Kafka, Selenium/WebDriver etc), chances are it is implemented in `locust-plugins <https://github.com/SvenskaSpel/locust-plugins/>`_
+If you think Locust is missing some obvious feature (like stopping after a certain number of iterations/requests, setting goals/thresholds for when to fail a test run, support for additional User types like Kafka, Selenium/WebDriver etc), chances are it is implemented in `locust-plugins <https://github.com/SvenskaSpel/locust-plugins/>`_.

docs/increase-performance.rst

@@ -32,7 +32,7 @@ Just subclass FastHttpUser instead of HttpUser::
 
 .. note::
 
-    FastHttpUser/geventhttpclient is very similar to for HttpUser/python-requests, but sometimes there are subtle differences. This is particularly true if you work with the client library's internals, e.g. when manually managing cookies.
+    FastHttpUser/geventhttpclient is very similar to HttpUser/python-requests, but sometimes there are subtle differences. This is particularly true if you work with the client library's internals, e.g. when manually managing cookies.
 
 API
 ===

docs/installation.rst

@@ -3,7 +3,7 @@
 Installation
 ============
 
-`Install Python <https://docs.python-guide.org/starting/installation/>`_ 3.7 or later, if you dont already have it.
+`Install Python <https://docs.python-guide.org/starting/installation/>`_ 3.7 or later, if you don't already have it.
 
 Install Locust:
 

docs/quickstart.rst

@@ -4,7 +4,7 @@
 Getting started
 ===============
 
-A Locust test is essentially a Python program. This makes it very flexible and particularly good at implementing complex user flows. But it can do simple tests as well, so lets start with that:
+A Locust test is essentially a Python program. This makes it very flexible and particularly good at implementing complex user flows. But it can do simple tests as well, so let's start with that:
 
 .. code-block:: python
 
@@ -55,17 +55,17 @@ Number of users:
 
 .. note::
 
-    Interpreting performance test results is quite complex (and mostly out of scope for this manual), but if your graphs start looking like this, the most likely reason is that your target service/system cannot handle the load you are hitting it with (it is overloaded or "saturated")
+    Interpreting performance test results is quite complex (and mostly out of scope for this manual), but if your graphs start looking like this, the most likely reason is that your target service/system cannot handle the load you are hitting it with (it is overloaded or "saturated").
 
     The clearest sign of this is that when we get to around 9 users, response times start increasing so fast that the requests per second-curve flattens out, even though new users are still being added.
 
-    If you're having trouble generating enough load to saturate your system, or need some pointers on how to start digging into a server side problem have a look at the `Locust FAQ  <https://github.com/locustio/locust/wiki/FAQ#increase-my-request-raterps>`_
+    If you're having trouble generating enough load to saturate your system, or need some pointers on how to start digging into a server side problem have a look at the `Locust FAQ  <https://github.com/locustio/locust/wiki/FAQ#increase-my-request-raterps>`_.
 
 
 Direct command line usage / headless
 ====================================
 
-Using the Locust web UI is entirely optional. You can supply the load parameters on command line and get reports on the results in text form:
+Using the Locust web UI is entirely optional. You can supply the load parameters on the command line and get reports on the results in text form:
 
 .. code-block:: console
     :substitutions:
@@ -100,4 +100,4 @@ To see all available options type: ``locust --help`` or check :ref:`configuratio
 
 |
 
-Now, lets have a more in-depth look at locustfiles and what they can do: :ref:`writing-a-locustfile`
+Now, let's have a more in-depth look at locustfiles and what they can do: :ref:`writing-a-locustfile`.

docs/running-distributed.rst

@@ -64,7 +64,7 @@ Optionally used together with ``--worker`` to set the port number of the master
 ``--master-bind-host=X.X.X.X``
 ------------------------------
 
-Optionally used together with ``--master``. Determines what network interface that the master node
+Optionally used together with ``--master``. Determines which network interface the master node
 will bind to. Defaults to * (all available interfaces).
 
 ``--master-bind-port=5557``
@@ -118,7 +118,7 @@ order to coordinate data. This can be easily accomplished with custom messages u
             environment.runner.send_message('test_users', users)  
 
 Note that when running locally (i.e. non-distributed), this functionality will be preserved; 
-the messages will simply be handled by the same runner that sends them.  
+the messages will simply be handled by the runner that sends them.  
 
 A more complete example can be found in the `examples directory <https://github.com/locustio/locust/tree/master/examples>`_ of the Locust 
 source code.
@@ -139,5 +139,5 @@ See :ref:`running-distributed-without-web-ui`
 Increase Locust's performance
 =============================
 
-If you're planning to run large-scale load tests you might be interested to use the alternative
-HTTP client that's shipped with Locust. You can read more about it here: :ref:`increase-performance`
+If you're planning to run large-scale load tests, you might be interested to use the alternative
+HTTP client that's shipped with Locust. You can read more about it here: :ref:`increase-performance`.

docs/running-in-debugger.rst

@@ -8,7 +8,7 @@ Running Locust in a debugger is extremely useful when developing your tests. Amo
 
 But debuggers sometimes have issues with complex gevent-applications like Locust, and there is a lot going on in the framework itself that you probably aren't interested in. To simplify this, Locust provides a method called :py:func:`run_single_user <locust.debug.run_single_user>`:
 
-Note that this is fairly new feature, and the api is subject to change.
+Note that this is a fairly new feature, and the api is subject to change.
 
 .. literalinclude:: ../examples/debugging.py
     :language: python
@@ -28,12 +28,12 @@ Make sure you have enabled gevent in your debugger settings. In VS Code's ``laun
 .. literalinclude:: ../.vscode/launch.json
     :language: json
 
-There is a similar setting in `PyCharm <https://www.jetbrains.com/help/pycharm/debugger-python.html>`_
+There is a similar setting in `PyCharm <https://www.jetbrains.com/help/pycharm/debugger-python.html>`_.
 
 .. note::
 
     | VS Code/pydev may give you warnings about:
     | ``sys.settrace() should not be used when the debugger is being used``
     | It can safely be ignored (and if you know how to get rid of it, please let us know)
 
-You can execute run_single_user multiple times, as shown in `debugging_advanced.py <https://github.com/locustio/locust/tree/master/examples/debugging_advanced.py>`_
+You can execute run_single_user multiple times, as shown in `debugging_advanced.py <https://github.com/locustio/locust/tree/master/examples/debugging_advanced.py>`_.

docs/running-in-docker.rst

@@ -37,8 +37,8 @@ official Locust docker image as a base image::
 Running a distributed load test on Kubernetes
 =============================================
 
-The easiest way to run Locust on Kubernetes is to use a `Helm chart <https://helm.sh/>`_
+The easiest way to run Locust on Kubernetes is to use a `Helm chart <https://helm.sh/>`_.
 
-There is a good helm chart here: `github.com/deliveryhero/helm-charts <https://github.com/deliveryhero/helm-charts/tree/master/stable/locust>`_
+There is a good helm chart here: `github.com/deliveryhero/helm-charts <https://github.com/deliveryhero/helm-charts/tree/master/stable/locust>`_.
 
 Note: this Helm chart is a separate project, and not supported by Locust maintainers.

docs/running-without-web-ui.rst

@@ -83,4 +83,4 @@ Below is an example that'll set the exit code to non zero if any of the followin
         else:
             environment.process_exit_code = 0
 
-(this code could go into the locustfile.py or in any other file that is imported in the locustfile)
+This code could go into the locustfile.py or in any other file that is imported in the locustfile.

docs/testing-other-systems.rst

@@ -10,18 +10,18 @@ Locust only comes with built-in support for HTTP/HTTPS but it can be extended to
 
     It is important that the protocol libraries you use can be `monkey-patched <http://www.gevent.org/intro.html#monkey-patching>`_ by gevent. 
 
-    Almost any libraries that are pure Python (using the Python ``socket`` module or some other standard library function like ``subprocess``) should work fine out of the box - but if they do their I/O calls in C gevent will be unable to patch it. This will block the whole Locust/Python process (in practice limiting you to running a single User per worker process)
+    Almost any libraries that are pure Python (using the Python ``socket`` module or some other standard library function like ``subprocess``) should work fine out of the box - but if they do their I/O calls in C, gevent will be unable to patch it. This will block the whole Locust/Python process (in practice limiting you to running a single User per worker process).
 
-    Some C libraries allow for other workarounds. For example, if you want to use psycopg2 to performance test PostgreSQL, you can use `psycogreen <https://github.com/psycopg/psycogreen/>`_. If you are willing to get your hands dirty, you may also be able to do patch a library yourself, but that is beyond the scope of this documentation.
+    Some C libraries allow for other workarounds. For example, if you want to use psycopg2 to performance test PostgreSQL, you can use `psycogreen <https://github.com/psycopg/psycogreen/>`_. If you are willing to get your hands dirty, you may also be able to patch a library yourself, but that is beyond the scope of this documentation.
 
 Example: writing an XML-RPC User/client
 =======================================
 
-Lets assume we had an XML-RPC server that we wanted to load test
+Lets assume we had an XML-RPC server that we wanted to load test.
 
 .. literalinclude:: ../examples/custom_xmlrpc_client/server.py
 
-We can build a generic XML-RPC client, by wrapping :py:class:`xmlrpc.client.ServerProxy`
+We can build a generic XML-RPC client, by wrapping :py:class:`xmlrpc.client.ServerProxy`.
 
 .. literalinclude:: ../examples/custom_xmlrpc_client/xmlrpc_locustfile.py
 
@@ -47,4 +47,4 @@ gRPC client, base User and example usage:
 .. literalinclude:: ../examples/grpc/locustfile.py
 
 
-For more examples of user types, see `locust-plugins <https://github.com/SvenskaSpel/locust-plugins#users>`_ (it has users for WebSocket/SocketIO, Kafka, Selenium/WebDriver and more)
+For more examples of user types, see `locust-plugins <https://github.com/SvenskaSpel/locust-plugins#users>`_ (it has users for WebSocket/SocketIO, Kafka, Selenium/WebDriver and more).

docs/testing-requests-based SDK's.rst

@@ -4,10 +4,10 @@
 Testing Requests based SDKs
 =============================
 
-If a prebuilt SDK is available for your target system. Locust has a supported pattern for integrating
+If a prebuilt SDK is available for your target system, Locust has a supported pattern for integrating
 its usage into your load testing efforts.
 
-The only perquisite to achieve this; is that the SDK needs to have an accessible ``request.Sessions``
+The only perquisite to achieve this is that the SDK needs to have an accessible ``request.Sessions``
 class.
 
 The following example shows the locust client overwriting the internal ``_session`` object of ``Archivist`` SDK

docs/writing-a-locustfile.rst

@@ -153,17 +153,17 @@ For example, to make each user wait between 0.5 and 10 seconds between every tas
 
 * :py:attr:`constant_throughput <locust.wait_time.constant_throughput>` for an adaptive time that ensures the task runs (at most) X times per second.
 
-* :py:attr:`constant_pacing <locust.wait_time.constant_pacing>` for an adaptive time that ensures the task runs (at most) once every X seconds  (it is the mathematical inverse of `constant_throughput`)
+* :py:attr:`constant_pacing <locust.wait_time.constant_pacing>` for an adaptive time that ensures the task runs (at most) once every X seconds  (it is the mathematical inverse of `constant_throughput`).
 
 .. note::
 
     For example, if you want Locust to run 500 task iterations per second at peak load, you could use `wait_time = constant_throughput(0.1)` and a user count of 5000.
 
     Wait time can only constrain the throughput, not launch new Users to reach the target. So, in our example, the throughput will be less than 500 if the time for the task iteration exceeds 10 seconds.
 
-    Wait time is applied *after* task execution, so if you have a high spawn rate/ramp up you may end up exceeding your target during rampup.
+    Wait time is applied *after* task execution, so if you have a high spawn rate/ramp up you may end up exceeding your target during ramp-up.
 
-    Wait times apply to *tasks*, not requests.  If you, for example, specify `wait_time = constant_throughput(2)` and do two requests in your tasks your request rate/RPS will be 4 per User.
+    Wait times apply to *tasks*, not requests. For example, if you specify `wait_time = constant_throughput(2)` and do two requests in your tasks, your request rate/RPS will be 4 per User.
 
 It's also possible to declare your own wait_time method directly on your class.
 For example, the following User class would sleep for one second, then two, then three, etc.
@@ -206,8 +206,8 @@ classes. Say for example, web users are three times more likely than mobile user
 
 Also you can set the :py:attr:`fixed_count <locust.User.fixed_count>` attribute.
 In this case the weight property will be ignored and the exact count users will be spawned.
-These users are spawned first. In the below example the only instance of AdminUser
-will be spawned to make some specific work with more accurate control
+These users are spawned first. In the example below, only one instance of AdminUser
+will be spawned, to make some specific work with more accurate control
 of request count independently of total user count.
 
 .. code-block:: python
@@ -293,7 +293,7 @@ The easiest way to add a task for a User is by using the :py:meth:`task <locust.
             print("User instance (%r) executing my_task" % self)
 
 **@task** takes an optional weight argument that can be used to specify the task's execution ratio. In
-the following example *task2* will have twice the chance of being picked as *task1*:
+the following example, *task2* will be twice as likely to be selected than *task1*:
 
 .. code-block:: python
 
@@ -343,14 +343,14 @@ with a task that looks like this::
 
     {my_task: 3, another_task: 1}
 
-*my_task* would be 3 times more likely to be executed than *another_task*.
+*my_task* would be 3 times as likely to be executed than *another_task*.
 
 Internally the above dict will actually be expanded into a list (and the ``tasks`` attribute is updated)
 that looks like this::
 
     [my_task, my_task, my_task, another_task]
 
-and then Python's ``random.choice()`` is used pick tasks from the list.
+and then Python's ``random.choice()`` is used to pick tasks from the list.
 
 
 .. _tagging-tasks:
@@ -359,7 +359,7 @@ and then Python's ``random.choice()`` is used pick tasks from the list.
 --------------
 
 By tagging tasks using the :py:func:`@tag <locust.tag>` decorator, you can be picky about what tasks are
-executed during the test using the :code:`--tags` and :code:`--exclude-tags` arguments.  Consider
+executed during the test using the :code:`--tags` and :code:`--exclude-tags` arguments. Consider
 the following example:
 
 .. code-block:: python
@@ -552,7 +552,7 @@ Here's an example of how to call a REST API and validate the response:
         except KeyError:
             response.failure("Response did not contain expected key 'greeting'")
 
-locust-plugins has a ready-made class for testing REST API:s called `RestUser <https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/rest_ex.py>`_
+locust-plugins has a ready-made class for testing REST API:s called `RestUser <https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/rest_ex.py>`_.
 
 .. _name-parameter:
 
@@ -573,7 +573,7 @@ Example:
         self.client.get("/blog?id=%i" % i, name="/blog?id=[id]")
 
 There may be situations where passing in a parameter into request function is not possible, such as when interacting with libraries/SDK's that
-wrap a Requests session. An alternative say of grouping requests is provided By setting the ``client.request_name`` attribute
+wrap a Requests session. An alternative way of grouping requests is provided by setting the ``client.request_name`` attribute.
 
 .. code-block:: python
 
@@ -583,7 +583,7 @@ wrap a Requests session. An alternative say of grouping requests is provided By
         self.client.get("/blog?id=%i" % i)
     self.client.request_name=None
 
-If You want to chain multiple groupings with minimal boilerplate, you can use the ``client.rename_request()`` context manager.
+If you want to chain multiple groupings with minimal boilerplate, you can use the ``client.rename_request()`` context manager.
 
 .. code-block:: python
 
@@ -613,7 +613,7 @@ Connection pooling
 ------------------
 
 As every :py:class:`HttpUser <locust.HttpUser>` creates new :py:class:`HttpSession <locust.clients.HttpSession>`,
-every user instance has it's own connection pools. This is similar to how real users would interact with a web server.
+every user instance has its own connection pools. This is similar to how real users would interact with a web server.
 
 However, if you want to share connections among all users, you can use a single pool manager. To do this, set
 :py:attr:`pool_manager <locust.HttpUser.pool_manager>` class attribute to an instance of :py:class:`urllib3.PoolManager`.
@@ -633,7 +633,7 @@ For more configuration options, refer to the
 
 TaskSets
 ================================
-TaskSets is a way to structure tests of hierarchical web sites/systems. You can :ref:`read more about it here <tasksets>`
+TaskSets is a way to structure tests of hierarchical web sites/systems. You can :ref:`read more about it here <tasksets>`.
 
 
 How to structure your test code
@@ -661,7 +661,7 @@ follow Python best practices. Here's an example file structure of an imaginary L
   * ``locustfile.py``
   * ``requirements.txt`` (External Python dependencies is often kept in a requirements.txt)
 
-A project with multiple different locustfiles could also keep them in a separate subdirectory:
+A project with multiple locustfiles could also keep them in a separate subdirectory:
 
 * Project root