Represents a “user” which is to be hatched and attack the system that is to be load tested.
The behaviour of this user is defined by the task_set attribute, which should point to a TaskSet class.
This class creates a client attribute on instantiation which is an HTTP client with support for keeping a user session between requests.
Minimum waiting time between the execution of locust tasks
Maximum waiting time between the execution of locust tasks
TaskSet class that defines the execution behaviour of this locust
Minimum waiting time between the execution of locust tasks
Maximum waiting time between the execution of locust tasks
TaskSet class that defines the execution behaviour of this locust
Instance of HttpSession that is created upon instantiation of Locust. The client support cookies, and therefore keeps the session between HTTP requests.
Class defining a set of tasks that a Locust user will execute.
When a TaskSet starts running, it will pick a task from the tasks attribute, execute it, call it’s wait function which will sleep a randomm number between min_wait and max_wait milliseconds. It will then schedule another task for execution and so on.
TaskTests can be nested, which means that a TaskSet’s tasks attribute can contain another TaskSet. If the nested TaskSet it scheduled to be executed, it will be instanciated and called from the current executing TaskSet. Execution in the the currently running TaskSet will then be handed over to the nested TaskSet which will continue to run until it throws an InterruptTaskSet exception, which is done when TaskSet.interrupt() is called. (execution will then continue in the first TaskSet).
Will refer to the root Locust class when the TaskSet has been instantiated
Minimum waiting time between the execution of locust tasks. Can be used to override the min_wait defined in the root Locust class, which will be used if not set on the TaskSet.
Maximum waiting time between the execution of locust tasks. Can be used to override the max_wait defined in the root Locust class, which will be used if not set on the TaskSet.
List with python callables that represents a locust user task.
If tasks is a list, the task to be performed will be picked randomly.
If tasks is a (callable,int) list of two-tuples, or a {callable:int} dict, the task to be performed will be picked randomly, but each task will be weighted according to it’s corresponding int value. So in the following case ThreadPage will be fifteen times more likely to be picked than write_post:
class ForumPage(TaskSet):
tasks = {ThreadPage:15, write_post:1}
Interrupt the TaskSet and hand over execution control back to the parent TaskSet.
If reschedule is True (default), the parent Locust will immediately re-schedule, and execute, a new task
This method should not be called by the root TaskSet (the one that is immediately, attached to the Locust class’ task_set attribute), but rather in nested TaskSet classes further down the hierarchy.
Add a task to the Locust’s task execution queue.
Arguments:
Used as a convenience decorator to be able to declare tasks for a TaskSet inline in the class. Example:
class ForumPage(TaskSet):
@task(100)
def read_thread(self):
pass
@task(7)
def create_thread(self):
pass
Class for performing web requests and holding (session-) cookies between requests (in order to be able to log in and out of websites). Each request is logged so that locust can display statistics.
This is a slightly extended version of python-request‘s requests.Session class and mostly this class works exactly the same. However the methods for making requests (get, post, delete, put, head, options, patch, request) can now take a url argument that’s only the path part of the URL, in which case the host part of the URL will be prepended with the HttpSession.base_url which is normally inherited from a Locust class’ host property.
Each of the methods for making requests also takes two additional optional arguments which are Locust specific and doesn’t exist in python-requests. These are:
Parameters: |
|
---|
Constructs and sends a requests.Request. Returns requests.Response object.
Parameters: |
|
---|
Sends a GET request. Returns Response object.
Parameters: |
|
---|
Sends a POST request. Returns Response object.
Parameters: |
|
---|
Sends a DELETE request. Returns Response object.
Parameters: |
|
---|
Sends a PUT request. Returns Response object.
Parameters: |
|
---|
Sends a HEAD request. Returns Response object.
Parameters: |
|
---|
Sends a OPTIONS request. Returns Response object.
Parameters: |
|
---|
Sends a PATCH request. Returns Response object.
Parameters: |
|
---|
This class actually resides in the python-requests library, since that’s what Locust is using to make HTTP requests, but it’s included in the API docs for locust since it’s so central when writing locust load tests. You can also look at the Response class at the requests documentation.
The core Response object. All Request objects contain a response attribute, which is an instance of this class.
Dictionary of configurations for this request.
Content of the response, in bytes.
A CookieJar of Cookies the server sent back.
Encoding to decode with when accessing r.text.
Resulting HTTPError of request, if one occurred.
Case-insensitive Dictionary of Response Headers. For example, headers['content-encoding'] will return the value of a 'Content-Encoding' response header.
A list of Response objects from the history of the Request. Any redirect responses will end up here. The list is sorted from the oldest to the most recent request.
Iterates over the response data. This avoids reading the content at once into memory for large responses. The chunk size is the number of bytes it should read into memory. This is not necessarily the length of each item returned as decoding can take place.
Iterates over the response data, one line at a time. This avoids reading the content at once into memory for large responses.
Returns the json-encoded content of a response, if any.
Returns the parsed header links of the response, if any.
Raises stored HTTPError or URLError, if one occurred.
File-like object representation of response (for advanced usage).
The HTTP Reason for the response.
The Request that created the Response.
Integer Code of responded HTTP Status.
Content of the response, in unicode.
if Response.encoding is None and chardet module is available, encoding will be guessed.
Final URL location of Response.
A Response class that also acts as a context manager that provides the ability to manually control if an HTTP request should be marked as successful or a failure in Locust’s statistics
This class is a subclass of Response with two additional methods: success and failure.
Report the response as successful
Example:
with self.client.get("/does/not/exist", catch_response=True) as response:
if response.status_code == 404:
response.success()
Report the response as a failure.
exc can be either a python exception, or a string in which case it will be wrapped inside a CatchResponseError.
Example:
with self.client.get("/", catch_response=True) as response:
if response.content == "":
response.failure("No data")
Exception that will interrupt a Locust when thrown inside a task
The event hooks are instances of the locust.events.EventHook class:
Simple event class used to provide hooks for different types of events in Locust.
Here’s how to use the EventHook class:
my_event = EventHook()
def on_my_event(a, b):
print "Event was fired with arguments: %s, %s" % (a, b)
my_event += on_my_event
my_event.fire("foo", "bar")
The wollowing event hooks are available under the locust.events module:
request_success is fired when an HTTP request is completed successfully.
Listeners should take the following arguments:
request_failure is fired when an HTTP request fails
Event is fired with the following arguments:
locust_error is fired when an exception occurs inside the execution of a Locust class.
Event is fired with the following arguments:
report_to_master is used when Locust is running in –slave mode. It can be used to attach data to the dicts that are regularly sent to the master. It’s fired regularly when a report is to be sent to the master server.
Note that the keys “stats” and “errors” are used by Locust and shouldn’t be overridden.
Event is fired with the following arguments:
slave_report is used when Locust is running in –master mode and is fired when the master server recieves a report from a Locust slave server.
This event can be used to aggregate data from the locust slave servers.
Event is fired with following arguments:
hatch_complete is fired when all locust users has been spawned.
Event is fire with the following arguments:
quitting is fired when the locust process in exiting