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 … Read the rest >>>>