Rushing | Highlights
makes load and performance testing a fun sport, it comes with post-game
highlights. At the end of each load test, we try and make sense of the
data that we generated, providing you with clues to help you scale out
your app. For a
here's the auto-generated post-game highlights:
This rush generated 57,290 successful hits in 2.0 min and we transferred 1.66 GB of data in and out of your app. The average hit rate of 465/second translates to about 334,931 hits/day or 8,038,366 hits/month.
The average response time of 6.14 seconds is considerably higher than most other sites that are built to scale out. Response times less than 250 ms are what the cool kids strive for.
You got bigger problems though: 14% of the users during this rush experienced timeouts or errors!
The first error happened at 17.62 seconds into the test when the number of concurrent users was at 1253. Errors are usually caused by resource exhaustion issues, like running out of file descriptors or the connection pool size being too small (for SQL databases).
The first timeout happened at 15.11 into the test when the number of concurrent users was at 1465. Looks like you've been rushing with a timeout of 1 second. Timeouts tend to increase with concurrency if you have lock contention of sorts. You might want to think about in-memory caching using redis , memcached or varnish to return stale data for a period of time and asynchronously refresh this data.