Skip to content

Commit

Permalink
Showing 1 changed file with 14 additions and 16 deletions.
30 changes: 14 additions & 16 deletions docs/writing-a-locustfile.rst
Original file line number Diff line number Diff line change
@@ -17,13 +17,13 @@ The :py:attr:`task_set <locust.core.Locust.task_set>` attribute

The :py:attr:`task_set <locust.core.Locust.task_set>` attribute should point to a
:py:class:`TaskSet <locust.core.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 <locust.core.TaskSet.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() <locust.core.TaskSet.interrupt>` method
If we didn't have a call to the :py:meth:`interrupt() <locust.core.TaskSet.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 <locust.clients.HttpSession.get>`,
:py:meth:`delete <locust.clients.HttpSession.delete>`, :py:meth:`head <locust.clients.HttpSession.head>`,
:py:meth:`patch <locust.clients.HttpSession.patch>` and :py:meth:`options <locust.clients.HttpSession.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.

0 comments on commit 4c765b6

Please sign in to comment.