In the wake of the article "A collection of tips and facts on optimizing PHP scripts"

Yesterday, after reading the post " Collection of tips and facts on optimizing PHP scripts, " I was at a loss on some points of the article. Very often, the work has to deal with large projects. For the past 5 years I have been working with high loads and, as it seems to me, I have gained a good experience in their development and support. I do not want to start holivary and in detail to paint all the subtleties of project optimization. I just want to express my point of view on some of the points voiced in the article and, if the user is supporting me, with great pleasure this article will be the beginning of a series of articles on optimization.

The most important rule to remember when optimizing is: premature optimization is the root of all ills.


')

Optimization Tips

Clear code is 99% better optimized

• Very often, the code that you wrote will be used by someone else and the time they spend on understanding your code is very important.
• Try to create a separate file for a separate class.
  Yes, your number of require (include, require_once, include_once) will increase, but it will be much easier to find a certain class
• Do not attempt to use short names for classes and variables.
  If instead of $ videos you call the variable $ a, then in terms of speed the gain will be ridiculous, but the understanding of the code will fall sharply and the probability of an error that is difficult to catch will increase.
• If speed is really important to you, write a simple script-collector of your code for production (you can also look towards compiling PHP)
  But remember that in this case, if there is any problem in production, it will be harder to debug (if you replace the name of the variables, for example)

A few simple requests are easier to cache than one complex

• It is much easier to reset the data of several simple queries than one complex
  For example, to get information about a user in the comments (when drawing a nickname), it is easier to make a separate request (of course by caching it) than JOIN to the user table
• If it is possible to make the calculation of any data on the PHP side without appreciable loss in time, then it is better to do it
  Scale the base hard. Scaling back-end is much easier.
• When spreading tables to different database servers, JOIN requests may stop working altogether.

Try to cache all the data that comes to you from the database

• Even if you have dynamically changing content, you can still put it in the cache
  For example, the list of current broadcasts of users can be cached for 1 minute and this significantly reduces the load on the database (provided that the broadcast page is very visited). However, in the case of caching for a short time, it is imperative to pay attention to the fact that several back-ups are not useful to update the cache simultaneously.
• Use cache reset mechanisms
  User updated information about yourself? So you need to reset the caches that relate to it.

Architecture Tips

• To render static content, use nginx or lighttpd.
• To speed up PHP, you can use for example eAccelerator
• Use gzip
• Combine js and css files into one
  It is also very good to use different compressors to reduce the size of these files (Google Closure Tools, YUI Compressor and others)

PS The topic does not pretend to be innovative and is only a look at optimization from the development of large projects.
PPS If you are minus in karma, then at least write in the comments for what.