Boot web application

Question

When testing the load with a basic web application, what health checks do you perform other than the expected response time?

Is it fair to talk about peak memory?
What other checks do you do?

Answer 1

On server

• Requests per second that the application can handle
• Queries per second that fall into the database (if any, are higher than the number, but it is useful to have them as separate digits)
• Transmission bandwidth (if possible, divided by media type)
• CPU usage
• Memory usage

On the client

• Response time
• Middle Page Weight
• Maximum CPU utilization at any time.
• Run something like YSlow to see what you can optimize for output to make it fast for users.

Voltage testing tools usually come with most of these measures (with the exception of memory, processor, and database), like YSlow or Firebug on the client.

Answer 2

When analyzing the results of the load test, we consider a fairly wide range of indicators.

On the server, we start with these basic 4 categories:

• CPU (% of use, context switches / sec, process queue length)
• Memory (% of use, pageview / second, page recording / second)
• Bandwidth (incoming, outgoing, outgoing and outgoing, #connections, connection failures, segment retransmissions / sec)
• Disk (disk I / O time, battery life, queue length, read and write / sec)

We also like to view metrics specific to your web server and application server. For example, in IIS we will consider the number of connections to IIS, the number of hits in the cache and frequency of rotation, etc. In .NET we will consider ASP.NET/sec requests, the execution time of the last ASP.NET request, current ASP.NET requests, ASP.NET queue requests, ASP.NET request timeout, Errors / sec. ASP.NET and many others.

On the client side, we primarily look at the total page load time, duration and TTFB (time to the first byte) for critical transactions, bandwidth usage, average page size and failure rate. We also find the two metrics very useful - we call them "Pending Users" and "Average Wait Time". There are not many tools - they tell you in each sampling period exactly how many simulated users are in the process of receiving a resource from the server, and how long they have been waiting for the resource to arrive on average. We find that they are very useful for

• determining when a server has reached its capacity
• detection that the server stops responding to certain types of queries (usually for certain resources, such as those that require a query to the database)

Answer 3

Another good performance test is to run tests for at least 24 hours. We do this because one application works beautifully for several hours, then gets worse. Some problems were detected with scheduled tasks, as well as with connecting the db pool.

Answer 4

There are a number of services on the Internet that can also perform this type of testing. Of course, one of the drawbacks of this approach is that it is more difficult to correlate data from the service (this is what you can observe from the outside) with your own internal data on disk I / O, database operations, etc. If you end up walking along this route, I would suggest finding a provider that will give you programmatic access to the raw data from the test results.