Three first steps to optimizing LAMP

    There is an opinion that the LAMP bundle (Linux + Apache + Mysql + PHP) does not require special configuration and works out of the box. This is far from the case. After I persuaded a friend for a long time to install a PHP xcache cache accelerator, I decided to conduct a little experiment and try to turn off xcache on my virtual server, which is under a small load (about a hit per second). In real life, the load on the processor is small, but the memory is heavily loaded, because its a bit (256MBytes).

    The results of the experiment exceeded all expectations.I think you can easily find on the graphs of CPU and memory utilization the period when the cache was turned off.




    After half an hour of experimentation, the system crawled into a cruel swap and I could barely get the caching back in place:



    This experiment, unfortunately, was not clean, because I configured Apache exactly to the existing configuration, and turning off the cache led to a swap. Xcache (like other PHP accelerators) allows you to immediately save CPU time, memory, and disk access by storing intermediate code for PHP scripts in RAM. Despite the fact that the cache occupied as much as 64 MB of mine, its absence led to the growth of each of the work processes so that they crawled out of the physical memory.

    We will take out three optimization lessons - one per AMP component:

    1. Always configure Apache so that running ab -n1000 -c100 yoursite / bigscript.php does not result in a swap. To do this, read this article . “Boxed” Apache plus moderate scripts are a sure way to the abyss with increasing load. Especially for memory-limited VDS.
    2. Always install the PHP accelerator. On ordinary projects and CMS (Drupal / Joomla / WP) this will bring acceleration of return and reduction of processor load by 2-4 times, as well as saving of RAM. Configure the cache amount sufficient to store active scripts (cache busyness can be monitored).

    Third lesson - enable Query Cache in MySQL. It is clearly illustrated by the following graph:

    For more detailed MySQL tips, refer to the scripttuning-primer.sh by running it on a live DB.

    Other measures (except for optimizing the applications themselves) give a weaker effect, but can save a lot of resources. If you are interested, I recommend reading these articles.

    Also popular now: