Skip to main content

Web load test measuring how many concurrent users will get response to their actions quickly - within a second.

Project description

Hence name: WEB Quick RESPonse.


sudo apt-get install --yes gcc libevent-dev python-dev python-pip
sudo pip install webqresp


webqresp --repeat=3 --start=5 --response-seconds=0.5 --header='X-Name: Value' --content='{"name": "value"}' --method=POST
  • --repeat - Number of times to repeat the test, showing aggregated stats in the end. Default: 1.
  • --start - Number of concurrent requests to start with. Default: 1.
  • --response-seconds - Maximal response time in seconds for each request to pass the test. Default: 1.
  • --header - Additional headers, e.g. --header='Content-Type: application/json' --header='X-Name: Value'.
  • --content - Content for POST, etc. E.g. 'name1=value1&name2=value2' or '{"name1": "value1", "name2": "value2"}'.
  • --method - HTTP Method. Default: GET.
  • url - URL to test, e.g.


Maximal number of concurrent requests to the slowest URL while each request gets successful response within a second.


  • Popular criterion Requests Per Second (RPS, req/s) has a great flaw of being confusing when comparing measurement before and after optimization. Please see explanation.
  • Another criterion - Milliseconds Per Request (ms/req) calculated as 1000/(req/s) as proposed in the article above also has flaws:
    • It shows real response duration experienced by a user only when requests are sent sequentially, not concurrently:
      • Let’s take 100,000 requests and send them to a server in a sequence, waiting for each response before sending the next request. If server processes all this in 10 seconds, it is giving 10,000 req/s, and each request gets response in 0.1 ms - great!
      • Now let’s send 100,000 requests at the same time, not waiting for responses. If server processes all this in 10 seconds, it is giving the same 10,000 req/s, however while this criterion still shows false 0.1 ms, each request may get response in up to 10 seconds - that is not acceptable.
    • It still keeps proportion ambiguity:
      • Let’s take 10,000 req/s == 0.1 ms/req == 10,000 concurrent requests with 1 second for each response - this is acceptable.
      • The same 10,000 req/s == 0.1 ms/req == 100,000 requests with 10 seconds for each response - this is not acceptable.
  • Our criterion is constructed so that:
    • It cares about real response duration for each user in the worst concurrent case.
    • It is not a proportion. It is not ambiguous. Once 1 second is reached or failure occurs, it stops incrementing concurrent requests and returns the result.
  • Single slowest URL is chosen to save time configuring the tool, because anyway “A chain is only as strong as its weakest link”.

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Filename, size & hash SHA256 hash help File type Python version Upload date
webqresp-0.1.1.tar.gz (3.5 kB) Copy SHA256 hash SHA256 Source None

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN SignalFx SignalFx Supporter DigiCert DigiCert EV certificate StatusPage StatusPage Status page