{"id":177,"date":"2015-03-16T19:46:36","date_gmt":"2015-03-16T19:46:36","guid":{"rendered":"https:\/\/www.fastcomet.com\/blog\/?p=177"},"modified":"2022-06-10T08:00:24","modified_gmt":"2022-06-10T08:00:24","slug":"apc-xcache-eaccelerator-shared-hosting","status":"publish","type":"post","link":"https:\/\/www.fastcomet.com\/blog\/apc-xcache-eaccelerator-shared-hosting","title":{"rendered":"APC, XCache, and eAccelerator Available on Shared Hosting"},"content":{"rendered":"\n
Remember that one time you asked your host for APC or eAceelerator? Most probably they have directed you to their VPS or Dedicated servers because Opcode caching is not compatible with shared hosting. Well, we have to admit we did this too. We did not like it but that was the reality back then. Not anymore!<\/p>\n\n\n\n\n\n\n\n
We are glad to announce the successful implementation of mod_lsapi on all shared hosting servers which will greatly improve your website performance and introduce some great new features. But before we go into this any further, let’s first discuss some common problems, so we can give real context to this announcement.<\/p>\n\n\n\n
The Problem<\/h2>\n\n\n\n
Of course, the ultimate goal when we speak about website optimization is faster page speed and lower resource consumption, so your website can handle more simultaneous visitors without the need to upgrade your plan. Still, every improvement has some sort of trade-off. For example, OpCode Caching such as APC (made obsolete after inclusion of opcache in php 5.5+ ), XCache (only works up to PHP 5.6), and eAccelerator (works up to PHP 5.4) is not compatible with suPHP, which provides a security layer on the shared hosting environment. So, usually the problem is performance, security, compatibility – pick two – you can’t have them all.<\/p>\n\n\n\n
Some pretty secure and fast configurations are simply incompatible with some Open Source applications which are a huge problem for the shared hosting environment as different customers use different software platforms to build their websites.<\/p>\n\n\n\n
The most secure and user-friendly setup, on the other hand, does not really provide the performance and features we need.<\/p>\n\n\n\n
And last but not least, a high-performance host with great compatibility is pretty much useless if it is not secure.<\/p>\n\n\n\n
After reviewing a large number of different options and our current infrastructure, we were pretty unhappy with this “pick-two” situation:<\/p>\n\n\n\n
RUID2 + mod_php<\/strong> – is a giant security hole that lets any user get a root account<\/li>
MPM ITK<\/strong> – is very slow, as it kills processes after each request<\/li>
suPHP & CGI<\/strong> – are both slow, as they start PHP on each request. They are also incompatible with opcode caching.<\/li>
FastCGI<\/strong> – creates a lot of stability issues, hard to configure due to the way it handles processes, and doesn’t use opcode caching optimally.<\/li>
PHP-FPM<\/strong> – needs a socket\/startup per customer, not that stable with Apache and creates a mess when we tried to integrate it with PHP Selector – as now PHP selector would have to restart PHP-FPM processes.<\/li><\/ul>\n\n\n\n
What is OpCode Caching<\/h2>\n\n\n\n
For those of you that are not familiar with opcode caching, OpCache caches are a performance-enhancing extension for PHP. They do this by injecting themselves into the execution lifecycle of PHP and caching the results of the compilation phase for later reuse. It is not uncommon to see a 3x performance increase just by enabling an OpCode cache.<\/p>\n\n\n\n
This is achieved by skipping the compilation of already compiled PHP scripts as shown in the diagram below:<\/p>\n\n\n
![\"What](\"https:\/\/www.fastcomet.com\/blog\/wp-content\/uploads\/2015\/03\/OpCode-Caching.jpg\")
<\/figure>\n<\/div>\n\n\n![\"\"](\"https:\/\/www.fastcomet.com\/blog\/wp-content\/uploads\/2015\/03\/OpCode-Caching2.jpg\")
<\/figure>\n<\/div>\n\n\n