diff --git a/docs/installation.rst b/docs/installation.rst index 42f251138e..8374d4442b 100644 --- a/docs/installation.rst +++ b/docs/installation.rst @@ -15,7 +15,7 @@ If you want the bleeding edge version, you can use pip to install directly from $ pip3 install -e git://github.com/locustio/locust.git@master#egg=locustio Once Locust is installed, a **locust** command should be available in your shell. (if you're not using -virtualenv—which you should—make sure your python script directory is on your path). +virtualenv-which you should-make sure your python script directory is on your path). To see available options, run: diff --git a/docs/running-locust-distributed.rst b/docs/running-locust-distributed.rst index 171cd68764..9bee41bb80 100644 --- a/docs/running-locust-distributed.rst +++ b/docs/running-locust-distributed.rst @@ -10,7 +10,7 @@ running load tests distributed across multiple machines. To do this, you start one instance of Locust in master mode using the ``--master`` flag. This is the instance that will be running Locust's web interface where you start the test and see live statistics. The master node doesn't simulate any users itself. Instead you have to start one or -—most likely—multiple worker Locust nodes using the ``--worker`` flag, together with the +-most likely-multiple worker Locust nodes using the ``--worker`` flag, together with the ``--master-host`` (to specify the IP/hostname of the master node). A common set up is to run a single master on one machine, and then run **one worker instance per diff --git a/docs/writing-a-locustfile.rst b/docs/writing-a-locustfile.rst index 4fc495e591..f545db320d 100644 --- a/docs/writing-a-locustfile.rst +++ b/docs/writing-a-locustfile.rst @@ -2,8 +2,8 @@ Writing a locustfile ====================== -A locustfile is a normal python file. The only requirement is that it declares at least one class — -let's call it the user class — that inherits from the class :py:class:`User `. +A locustfile is a normal python file. The only requirement is that it declares at least one class - +let's call it the user class - that inherits from the class :py:class:`User `. User class ========== @@ -107,7 +107,7 @@ When a load test is started, an instance of a User class will be created for eac 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. -The tasks are normal python callables and — if we were load-testing an auction website — they could do +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. Declaring tasks @@ -177,8 +177,8 @@ 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 +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:: {my_task: 3, another_task: 1} @@ -338,7 +338,7 @@ simulated user would never stop running tasks from the Forum taskset once it has def frontpage(self): pass -Using the interrupt function, we can — together with task weighting — define how likely it +Using the interrupt function, we can - together with task weighting - define how likely it is that a simulated user leaves the forum. @@ -527,9 +527,9 @@ Manually controlling if a request should be considered successful or a failure ------------------------------------------------------------------------------ By default, requests are marked as failed requests unless the HTTP response code is OK (<400). -Most of the time, this default is what you want. Sometimes however—for example when testing +Most of the time, this default is what you want. Sometimes however-for example when testing a URL endpoint that you expect to return 404, or testing a badly designed system that might -return *200 OK* even though an error occurred—there's a need for manually controlling if +return *200 OK* even though an error occurred-there's a need for manually controlling if locust should consider a request as a success or a failure. One can mark requests as failed, even when the response code is OK, by using the