The fact is that if autotests are still being written to maintain quality in some web projects, then few people are involved in performance control at the development stage in principle. A web project with both autotests and code benchmarks is a rarity. Developers are much more likely and for reasonable reasons to use the following heuristics with a good value-for-money ratio:
- Queries to MySQL (further we will cite this popular database as an example) go through a fairly adequate API that uses indexes (although we do not see exactly how indexes are used by the scheduler and what their cardinality is).
- The results of executing queries to the database and heavy pieces of code are cached.
- The developer checked the construction of the web page 3.14 times in the browser, and if it doesn’t slow down at first glance, then everything is OK.
Let’s take caching. The developer often has no time to think about how often the cache can be rebuilt. But in vain. For example, if it takes a long time to rebuild the product catalog cache and the cache is reset when one product is added, then caching will do more harm than good.
That is why it’s not recommended to use the built-in MySQL query cache, which suffers from a similar problem: the table cache is completely flushed when at least one record of the table changes (imagine a table with 100 thousand rows, and the absurdity of the situation becomes obvious).
Also, often curious features of the operating system are revealed under load, in particular, overflow of the range of outgoing client TCP/IP ports, during intensive work with memcached. Or apache is full of requests for image processing, because during configuration, you forgot to configure their processing by the caching proxy server nginx.
Sometimes they forget to set the path for temporary tables to disk in MySQL, which maps data to RAM («/dev/shm»), which causes the database server to fall down from intensive sorts when the load increases.
Also, requests and algorithms begin to aggressively show their «O-notation» when adding data to a web project in a volume close to the combat one: if the cartesian is invisible for a small amount of data, then when the combat volume appears, the database server turns red from the load. We can give a lot of examples, but we will stop at this example for now. The main thing to understand is that load testing is necessary. Because if you will want to anticipate all possible options for «slowing down» a medium-sized web system in advance, it will be very expensive, very time-consuming and economically impractical.