From 9c0387274e43fdf744063a8ad3fd523df1b41a56 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Wed, 19 Aug 2020 10:10:02 +0545 Subject: [PATCH] Doc review changes --- README.md | 4 ++-- docs/api.rst | 2 +- docs/extending-locust.rst | 4 ++-- docs/running-locust-distributed.rst | 4 ++-- docs/running-locust-in-step-load-mode.rst | 2 +- docs/testing-other-systems.rst | 6 +++--- docs/what-is-locust.rst | 2 +- docs/writing-a-locustfile.rst | 4 ++-- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 1bd1b79e16..9043cd4041 100644 --- a/README.md +++ b/README.md @@ -21,7 +21,7 @@ Locust is an easy to use, scriptable and scalable performance testing tool. You define the behaviour of your users in regular Python code, instead of using a clunky UI or domain specific language. -This makes Locust infintely expandable and very developer friendly. +This makes Locust infinitely expandable and very developer friendly. ## Features @@ -33,7 +33,7 @@ This makes Locust infintely expandable and very developer friendly. * **Distributed & Scalable - supports hundreds of thousands of users**
Locust makes it easy to run load tests distributed over multiple machines. - It is event-based (using gevent), which makes it possible for a single process to handle many thousands concurrent users. While there may be other tools that are capable of doing more requests per second on a given hardware, the low overhead of each Locust user makes it very suitable for testing highly concurrent workloads. + It is event-based (using gevent), which makes it possible for a single process to handle many thousands of concurrent users. While there may be other tools that are capable of doing more requests per second on a given hardware, the low overhead of each Locust user makes it very suitable for testing highly concurrent workloads. * **Web-based UI**
diff --git a/docs/api.rst b/docs/api.rst index 6c8d56bdc8..43a43f0bb7 100644 --- a/docs/api.rst +++ b/docs/api.rst @@ -89,7 +89,7 @@ Environment class Event hooks =========== -Locust provide event hooks that can be used to extend Locus in various ways. +Locust provides event hooks that can be used to extend Locust in various ways. The following event hooks are available under :py:attr:`Environment.events `, and there's also a reference to these events under ``locust.events`` that can be used at the module level diff --git a/docs/extending-locust.rst b/docs/extending-locust.rst index 8ded85c635..b02e07499b 100644 --- a/docs/extending-locust.rst +++ b/docs/extending-locust.rst @@ -2,7 +2,7 @@ Extending Locust using event hooks ================================== -Locust comes with a number of events hooks that can be used to extend Locust in different ways. +Locust comes with a number of event hooks that can be used to extend Locust in different ways. Event hooks live on the Environment instance under the :py:attr:`events ` attribute. However, since the Environment instance hasn't been created when locustfiles are imported, @@ -26,7 +26,7 @@ Here's an example on how to set up an event listener:: .. seealso:: - To see all available event, please see :ref:`events`. + To see all available events, please see :ref:`events`. diff --git a/docs/running-locust-distributed.rst b/docs/running-locust-distributed.rst index 3bc15a0a78..3886e34f00 100644 --- a/docs/running-locust-distributed.rst +++ b/docs/running-locust-distributed.rst @@ -27,7 +27,7 @@ processor core** on the worker machines. Otherwise - due to the current implementation - you might end up with a distribution of the User classes that doesn't correspond to the User classes' ``weight`` attribute. And if the spawn rate is lower than the number of worker - nodes, the spawning would occur in "bursts" where all worker node would spawn a single user and + nodes, the spawning would occur in "bursts" where all worker nodes would spawn a single user and then sleep for multiple seconds, spawn another user, sleep and repeat. @@ -38,7 +38,7 @@ To start locust in master mode:: locust -f my_locustfile.py --master -And then on each worker (replace ``192.168.0.14`` with IP of the master machine, or leave out the parameter altogether if your workers are on the same machine as the master):: +And then on each worker (replace ``192.168.0.14`` with the IP of the master machine, or leave out the parameter altogether if your workers are on the same machine as the master):: locust -f my_locustfile.py --worker --master-host=192.168.0.14 diff --git a/docs/running-locust-in-step-load-mode.rst b/docs/running-locust-in-step-load-mode.rst index 86b3abbb1d..17e55b8c6c 100644 --- a/docs/running-locust-in-step-load-mode.rst +++ b/docs/running-locust-in-step-load-mode.rst @@ -48,5 +48,5 @@ Running Locust distributed in step load mode --------------------------------------------- If you want to :ref:`run Locust distributed ` in step load mode, -you should specify the ``--step-load`` option when starting the master node, to swarm locusts by step. It will then show the ``--step-users`` option and ``--step-time`` option in Locust UI. +you should specify the ``--step-load`` option when starting the master node, to swarm locusts by step. It will then show the ``--step-users`` option and ``--step-time`` option in the Locust UI. diff --git a/docs/testing-other-systems.rst b/docs/testing-other-systems.rst index 44470c1b7b..f1142856c4 100644 --- a/docs/testing-other-systems.rst +++ b/docs/testing-other-systems.rst @@ -20,12 +20,12 @@ Here is an example of a User class, **XmlRpcUser**, which provides an XML-RPC cl If you've written Locust tests before, you'll recognize the class called ``ApiUser`` which is a normal User class that has a couple of tasks declared. However, the ``ApiUser`` inherits from ``XmlRpcUser`` that you can see right above ``ApiUser``. The ``XmlRpcUser`` is marked as abstract -using ``abstract = True`` which means that Locust till not try to create simulated users from that class -(only of classes that extends it). ``XmlRpcUser`` provides an instance of XmlRpcClient under the +using ``abstract = True`` which means that Locust will not try to create simulated users from that class +(only of classes that extend it). ``XmlRpcUser`` provides an instance of XmlRpcClient under the ``client`` attribute. The ``XmlRpcClient`` is a wrapper around the standard -library's :py:class:`xmlrpc.client.ServerProxy`. It basically just proxies the function calls, but with the +library's :py:class:`xmlrpc.client.ServerProxy`. It basically just proxies the function calls, but with the important addition of firing :py:attr:`locust.event.Events.request_success` and :py:attr:`locust.event.Events.request_failure` events, which will record all calls in Locust's statistics. diff --git a/docs/what-is-locust.rst b/docs/what-is-locust.rst index 8e94714ded..40ed0c0e46 100644 --- a/docs/what-is-locust.rst +++ b/docs/what-is-locust.rst @@ -6,7 +6,7 @@ Locust is an easy to use, scriptable and scalable performance testing tool. You define the behaviour of your users in regular Python code, instead of using a clunky UI or domain specific language. -This makes Locust infintely expandable and very developer friendly. +This makes Locust infinitely expandable and very developer friendly. To start using Locust, go to :ref:`installation` diff --git a/docs/writing-a-locustfile.rst b/docs/writing-a-locustfile.rst index e235ec584f..ad685f6b70 100644 --- a/docs/writing-a-locustfile.rst +++ b/docs/writing-a-locustfile.rst @@ -118,7 +118,7 @@ Tasks When a load test is started, an instance of a User class will be created for each simulated user and they will start running within their own green thread. When these users run they pick tasks that -they execute, sleeps for awhile, and then picks a new task and so on. +they execute, sleep for awhile, and then pick a new task and so on. The tasks are normal python callables and - if we were load-testing an auction website - they could do stuff like "loading the start page", "searching for some product", "making a bid", etc. @@ -192,7 +192,7 @@ Here is an example of a User task declared as a normal python function: If the tasks attribute is specified as a list, each time a task is to be performed, it will be randomly chosen from the *tasks* attribute. If however, *tasks* is a dict - with callables as keys and ints as values - the task that is to be executed will be chosen at random but with the int as ratio. So -with a tasks that looks like this:: +with a task that looks like this:: {my_task: 3, another_task: 1}