Why does APC (or similar) cause performance problem for shared hosting?

Question

I'm using shared hosting, and I can't enable APC. There was a thread about that here, and the only reason suggested was for security (php-cgi vs mod_php). I queried the host, and they said it was due to performance reasons, specifically that the I/O would bring the box down. I don't really understand that - surely with a shared memory opcode cache there would be less I/O? Basically if I was setting up a shared hosting company (not that I could!) I would've thought it would make a whole load of sense to use a cache (if security permitted) to improve the performance for all the clients.

Can anyone shed some light on this for me? TIA

Answer 1

I would say APC on Shared Hosting plans is generally not a good idea.
The answer of your hosting is right but that's not the only reason.

When you get a Shared hosting you should be aware that you're not the only one who's using the server where your site is hosted. Depending on the hosting company's server, there may be 300 (or more) clients who're also hosting their sites on that machine.

Often those sites have MANY php files. For example a joomla 1.6 driven site has ~3000 php (~10mb) files (includes the site and admin panel). Imagine all of those 300 clients are using the Joomla platform and the sites are

1. Visited very often
2. Generate average server load

That means all of those clients will have ~900000 files to be eventually cached - ~3000mb RAM will be used only for caching the php files. As you know in APC you can also store "User cache entries" where you can usually store settings or serialized objects. I can't say how much RAM will go there because it depends on what you store, but let's say another extra 50-100mb.

For now we've used about 3,1GB RAM.
Now add some RAM needed by the basic services to run - Apache, FTP, PHP, MySQL, PostgreSQL, SendMail and server backup tools. You'll probably end up somewhere near 5-6GB RAM that will be almost permanently in use.

The other problems with APC come when you cache - everybody can see what you've cached (as far as I know). So you'll probably need to encrypt what you store - this will require more CPU because you'll be encrypting/decrypting all the time. Also if somebody accidentally clears the all of the cached files/user entries the server will go mad trying to re-cache.

Bottom line is no system administrator will go through all the pain in the *ss to enable and support APC. This is also not a benefit for the company. They would rather have 300 more clients paying them money than dealing with APC and wondering if their server won't go down or something won't go wrong any moment.

A better solution would be if the client gets a (managed) dedicated server. That way the client will be the only one hosting a site on that server and he could ask the support to install whatever hi wants on the server. This will be a lot more easier and will save the clietn, the sys admin and the hosting company from growing white hair :)

I hope this helps you understand a bit better why APC is not included in shared hostings.

Answer 2

Per: http://www.php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask

apc.mmap_file_mask string
If compiled with MMAP support by using --enable-mmap this is the mktemp-style file_mask to pass to the mmap module for determining whether your mmap'ed memory region is going to be file-backed or shared memory backed. For straight file-backed mmap, set it to something like /tmp/apc.XXXXXX (exactly 6 Xs). To use POSIX-style shm_open/mmap put a .shm somewhere in your mask. e.g. /apc.shm.XXXXXX You can also set it to /dev/zero to use your kernel's /dev/zero interface to anonymous mmap'ed memory. Leaving it undefined will force an anonymous mmap.

If using file backed that would definitely increase your IO depending on the amount of traffic coming into the server.

Answer 3

This would kill performance of any shared host unless you have enough memory to keep every PHP file loaded in memory. When you have a whole bunch of users trying to cache files that might not be commonly hit, the server is going to start swapping, which is going to kill the performance of everything on that machine.

Answer 4

According to https://stackoverflow.com/questions/1053810/php-apc-what-happen-when-apc-cache-is-full, the cache is flushed when memory is full and if the ttl is 0. If not set to zero, it will use a LRU (Least Recently Used) mechanism.
It seems to me it's always beneficial to use APC.

Answer 5

@tftd stated the primary reasons for not enabling APC, Memcached etc in shared hosting. But a use case may arise if your shared server is not really shared but only used by your own projects (or web design/development customers and if you are NOT giving them FTP/panel access), then that server can still benefit from APC/Memcached/etc.

At any case, I'd figure that I/O issue depends on the RAM available to APC, as it would constantly try to invalidate some entries and cache new ones if the available RAM is low or if the number of sites/PHP files is very high (a common case in shared hosting). This shouldn't be a problem if there is enough RAM and you are keeping an eye on the apc.php (APC's info page).

Besides that, the benefit of APC would be felt best in moderate/high traffic sites, as the caching of rarely visited PHP files wouldn't matter much.