A huge question. For several years, we conducted tests and load tests in my company, mainly based on HTTP.
Before moving on to complex scenarios, we often start with simple tests based on Apache Bench (the "ab" command included with Apache). This is not a load test, but performance, because the generated client actually waits for the HTTP request to complete before moving on to the next one. The main idea is to try "ab -c N -t 30" with N = 1,2,4,8,50,100 (for example). You quickly get an idea of the scalability and maximum bandwidth you should expect.
Note : run the command "ab" next to the test server (ideally on the same local network), otherwise you will also say the network (latency here is the main problem). But in some cases, this is a common system (server + network), which is really intended for testing.
Hence, if the results look good (i.e., bandwidth scales to the number of processors on the server side, low or zero error rate), we proceed to load testing. Otherwise, we are looking for bottlenecks , since the load test will only confirm the scalability problem and most likely show terrible results when the load is more than the supported bandwidth (100% of 500 internal errors, connection crashes, large time permissions, server overflow etc.).
BTW, during load testing, I mean using tools that can apply any load to a given server / application , especially loading, which the server cannot process (for example, Jmeter, Tsung). What is very interesting in the load test is what happens when the server is overloaded. Determining the maximum load that the server can handle is up to you when you select the exact breakpoint where performance is not considered acceptable.
Then it is a matter of guessing or observing existing patterns. In many cases, we are asked to perform a load test for a new website, where, obviously, no real behavior is observed. Otherwise, you can use analytics and view ten pages: your script should at least cross them. You will need some navigation paths that:
- obviously gets to the homepage
- use the search function and bounce from one content to another, perhaps by accident
- go to login if function exists
- more generally, these are POST forms, loadtest, which only read / GET data is not very significant.
Other tips:
- avoid difficulties; for example, if you have a shopping cart, you don’t need to set up a real shopping scenario with payment, etc. In an e-commerce store, the shopping cart path is rarely a performance problem, 95% of the traffic elsewhere (browsing products, etc.).
- check the navigation routes one by one before accumulating them in one large test test load; they must provide a good result individually in advance.
- it’s better to allow many paths to really use caches (there are always caches: HTTP, application, SQL, file system, etc.); tools that generate dynamic scripts in which you can change user names or object identifiers from long lists are required
The general idea is to do this gradually, starting with simple tests, otherwise it will be difficult for you to interpret the result if they do not fit the ideal scalability curve. And guess what? They never match the ideal scalability curve ...