This is a pre-production deployment of Warehouse. Changes made here affect the production instance of PyPI (pypi.python.org).
Help us improve Python packaging - Donate today!

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.

Install:

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

Usage:

webqresp http://example.com/
webqresp --repeat=3 --start=5 --response-seconds=0.5 --header='X-Name: Value' --content='{"name": "value"}' --method=POST http://example.com/some/page
  • --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. http://example.com/some/page.

Criterion:

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

Why:

  • 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”.
Release History

Release History

This version
History Node

0.1.1

History Node

0.1.0

Download Files

Download Files

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

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
webqresp-0.1.1.tar.gz (3.5 kB) Copy SHA256 Checksum SHA256 Source Mar 28, 2013

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting