8

I have written a simple load test using Locust (http://locust.io).

Now I noticed that sometimes (using a higher load) the response I get from a post call has a status_code of 0 and a None content. The 0 status code is not automatically recognized as a failure in Locust, so I have to test it manually.

My code fragment is this:

with self.client.get(path, catch_response=True) as response:
    if response.status_code != 200:
        response.failure(path + ": returned " + str(response.status_code))
    elif check not in response.content:
        response.failure(path + ": wrong response, missing '" + check + "'")

Note: check is a variable for a part of the expected response content.

The question is: is this a expected behaviour? Is this a problem of Locust (or Python) or is this a fault in the tested application?

alecxe
  • 462,703
  • 120
  • 1,088
  • 1,195
obecker
  • 2,132
  • 1
  • 19
  • 23

3 Answers3

11

From the locust documentation in: http://docs.locust.io/en/latest/writing-a-locustfile.html

Safe mode

The HTTP client is configured to run in safe_mode. What this does is that any request that fails due to a connection error, timeout, or similar will not raise an exception, but rather return an empty dummy Response object. The request will be reported as a failure in Locust’s statistics. The returned dummy Response’s content attribute will be set to None, and it’s status_code will be 0.

It looks like the server can´t handle all the requests you are swarming it with and some of them are timing out.

Nettok
  • 156
  • 1
  • 3
  • 2
    Ah, yes, thanks. I missed that. So it seems, using `with self.client.get(path, catch_response=True) as response:` I have to check for the failure myself. – obecker Jun 27 '13 at 16:18
  • safe_mode has been removed a while ago. https://github.com/locustio/locust/commit/0f5b47ee3d10d16f1eeea4df7b5f1934fba27312 – Bill-- Oct 01 '22 at 15:15
0

My test returned the type of the response was locust.clients.responsecontextmanager but had status_code as 0 and no content, and of course unparseable JSON

It turned out to be the the wrong server URL that I had configured. Check your server logs, if the server indeed received the request and processed it.

TechFree
  • 2,600
  • 1
  • 17
  • 18
0

Those errors are being swallowed and replaced with a dummy Response:

HttpSession catches any requests.RequestException thrown by Session (caused by connection errors, timeouts or similar), instead returning a dummy Response object with status_code set to 0 and content set to None.

https://docs.locust.io/en/latest/writing-a-locustfile.html#client-attribute-httpsession

It doesn't look like they have any way to not swallow errors.

Bill--
  • 140
  • 3
  • 6