% if (test.last_point) { %>
This rush generated <%= blitz.pp.number(test.last_point.hits) %> successful hits in <%= blitz.pp.duration(test.max_duration) %> and we transferred <%= blitz.pp.bytes(test.last_point.rxBytes+test.last_point.txBytes) %> of data in and out of your app. The average hit rate of <%= blitz.pp.rate(test.average_hit_rate) %> translates to about <%= blitz.pp.number(Math.floor(test.average_hit_rate*3600*24)) %> hits/day. <% if (test.average_response_time > 0.5) { %>
The average response time of <%= blitz.pp.duration(test.average_response_time) %> 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.
<% } %> <% if (test.last_point.timeouts || test.last_point.errors) { %>You got bigger problems though: <%= ((test.last_point.timeouts+test.last_point.errors)/test.last_point.total*100).toFixed(2) %>% of the users during this rush experienced timeouts or errors!
<% } %>The first error happened at <%= blitz.pp.duration(test.first_error_point.timestamp) %> into the test when the number of concurrent users was at <%= test.first_error_point.volume %>. 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 <%= blitz.pp.duration(test.first_timeout_point.timestamp) %> into the test when the number of concurrent users was at <%= test.first_timeout_point.volume %>. Looks like you've been rushing with a timeout of <%= blitz.pp.duration((test.timeout||1000)/1000.0) %>. 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.
<% } %>