Search Engine: Elastic

Article ID: 116306, created on Jun 20, 2013, last review on Jul 14, 2018

  • Applies to:
  • Operations Automation 5.4


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:

  1. 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.
  2. 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.

2554725ed606193dd9bbce21365bed4e caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae ac82ce33439a9c1feec4ff4f2f638899 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF