Overview
The goal of Linux Shared Hosting NG (LSH NG) is to provide a solution with maximum server density and site isolation for the mass shared hosting market. It was designed to host large numbers of websites with small applications and limited traffic.
Why aren't FastCGI and PHP cache supported on LSH NG?
In FastCGI mode, the user's PHP processes stay in the memory after requests are made, and additional HTTP requests of the same user go to already existing processes. The result is to save CPU time on interpreter initialization during HTTP request processing.
However, for LSH NG, this approach limits isolation and increases server density for the following reasons:
- Living user processes, such as PHP interpreter instances, lead to memory shortages in the webserver. Currently, there isn't a good eviction strategy for FastCGI processes in mass shared hosting.
- Web applications are extremely dependent on a warm VFS cache, so unused memory is a precious resource, and we need to make sure that OS memory will not get filled with user data. The response time difference between a warm and cold VFS cache is about 20 times quicker for a warm cache.
PHP cache is another approach to speed up PHP applications by saving memory in caching bytecodes for PHP files in the memory. This way, in the next request to the same PHP application, the interpreter can skip the bytecode producing phase. Currently, there are several modules that add this functionality to PHP, such as xcache, eAccelerator, and APC. In the php-5.5 development cycle, a PHP cache solution based on Zend is merged into the PHP package. It's very likely that, on a long term basis, it will replace all other solutions.
None of the widely known PHP cache solutions work with PHP in CGI mode, which is required for LSH NG. Fortunately, there is an ongoing development activity to add CGI mode support to Zend op cache merged in php-5.5, but there is still no usable output. As soon as this solution emerges, we plan to add support for it in LSH NG. Nevertheless, it's still necessary to take into consideration the issues with user memory and VFS cache. A good eviction strategy is required.
Best practice
While it is still not possible to have a prompt solution for PHP cache, if one of the hosted websites on NG starts to have increased traffic and application requests, the recommendation is to upsell these websites to a dedicated VPS.
In POA, we have a special screen that shows website activity. This should be used as the criteria to recommend an end customer to migrate to VPS. The CPU time column in the screen below shows how many seconds each website was executed during the last 24 hours. For example, if this value is equal to 86400, that means this site was busy for the whole day. A threshold of 10000 to 20000 can be used to determine which sites should be promoted to VPS.