diff --git a/docs/writing-a-locustfile.rst b/docs/writing-a-locustfile.rst index 9422d04b01..0db2173d98 100644 --- a/docs/writing-a-locustfile.rst +++ b/docs/writing-a-locustfile.rst @@ -17,13 +17,13 @@ The :py:attr:`task_set ` attribute The :py:attr:`task_set ` attribute should point to a :py:class:`TaskSet ` class which defines the behaviour of the user and -is described in more details below. +is described in more detail below. The *min_wait* and *max_wait* attributes ---------------------------------------- -Additionally to the task_set attribute, one usually want to declare the *min_wait* and *max_wait* -attributes. These are the minimum and maximum time, in milliseconds, that a simulated user will wait +In addition to the task_set attribute, one usually wants to declare the *min_wait* and *max_wait* +attributes. These are the minimum and maximum time respectively, in milliseconds, that a simulated user will wait between executing each task. *min_wait* and *max_wait* default to 1000, and therefore a locust will always wait 1 second between each task if *min_wait* and *max_wait* are not declared. @@ -85,9 +85,8 @@ and—if we were load-testing an auction website—could do stuff like "loading When a load test is started, each instance of the spawned Locust classes will start executing their TaskSet. What happens then is that each TaskSet will pick one of its tasks and call it. It will then wait a number of milliseconds, chosen at random between the Locust class' *min_wait* and *max_wait* attributes -(unless min_wait/max_wait has been defined directly under the TaskSet, in which case it will use -its own values instead). Then it will again pick a new task which will be called, then wait again, -and so on. +(unless min_wait/max_wait have been defined directly under the TaskSet, in which case it will use +its own values instead). Then it will again pick a new task to be called, wait again, and so on. Declaring tasks --------------- @@ -106,7 +105,7 @@ Here is an example:: class MyLocust(Locust): task_set = MyTaskSet -**@task** takes an optional weight argument that can be used to specify the tasks' execution ratio. In +**@task** takes an optional weight argument that can be used to specify the task's execution ratio. In the following example *task2* will be executed twice as much as *task1*:: from locust import Locust, TaskSet, task @@ -130,7 +129,7 @@ the following example *task2* will be executed twice as much as *task1*:: tasks attribute -------------- -Using the @task decorator to declare tasks is a convenience, and usually that's the best way to do +Using the @task decorator to declare tasks is a convenience, and usually the best way to do it. However, it's also possible to define the tasks of a TaskSet by setting the :py:attr:`tasks ` attribute (using the @task decorator will actually just populate the *tasks* attribute). @@ -151,8 +150,7 @@ the task. Here is an extremely simple example of a locustfile (this locustfile w task_set = MyTaskSet -If the -tasks attribute is specified as a list, each time a task is to be performed, it will be randomly +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:: @@ -189,7 +187,7 @@ we could define TaskSets with the following structure: * About page The way you nest TaskSets is just like when you specify a task using the **tasks** attribute, but -instead of referring to a python function, you point it to another TaskSet:: +instead of referring to a python function, you refer to another TaskSet:: class ForumPage(TaskSet): @task(20) @@ -211,14 +209,14 @@ instead of referring to a python function, you point it to another TaskSet:: def index(self): pass -So in above example, if the ForumPage would get selected for execution when the UserBehaviour +So in the above example, if the ForumPage would get selected for execution when the UserBehaviour TaskSet is executing, then the ForumPage TaskSet would start executing. The ForumPage TaskSet -would then pick one of its own tasks, execute it, then wait, and so on. +would then pick one of its own tasks, execute it, wait, and so on. There is one important thing to note about the above example, and that is the call to -self.interrupt() in the ForumPage's stop method. What this does is essentially that it will +self.interrupt() in the ForumPage's stop method. What this does is essentially to stop executing the ForumPage task set and the execution will continue in the UserBehaviour instance. -If we wouldn't have had a call to the :py:meth:`interrupt() ` method +If we didn't have a call to the :py:meth:`interrupt() ` method somewhere in ForumPage, the Locust would never stop running the ForumPage task once it has started. But by having the interrupt function, we can—together with task weighting—define how likely it is that a simulated user leaves the forum. @@ -302,7 +300,7 @@ statistics, using the :py:meth:`get `, :py:meth:`delete `, :py:meth:`head `, :py:meth:`patch ` and :py:meth:`options ` methods. The HttpSession instance will preserve cookies between requests so that it can be used to log in -to websites and keep a session between requests. The client attribute can also be reference from the Locust +to websites and keep a session between requests. The client attribute can also be referenced from the Locust instance's TaskSet instances so that it's easy to retrieve the client and make HTTP requests from within your tasks.