Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
Certainly it's both my expectation and my experience that opcode caching reduces I/O. Maybe the real reason is to encourage users to upgrade their package? –  symcbean Sep 8 '10 at 8:25
    
To be fair to the guy who responded, he didn't try to pimp a higher package, but to say that people weren't having problems using the shared hosting as-is. –  Andy Sep 8 '10 at 8:42
add comment

5 Answers

up vote 6 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Seems to me that is incorrect, and memory is pretty cheap these days. –  3molo Apr 6 '11 at 6:21
    
There's no need to cache every file. Just like a processor has an instruction cache that doesn't hold entire programs, I would expect substantial gains to be possible by caching those files that are currently being used the most. See 3molo's answer for a possible reason why APC might not work in an appropriate way for this scenario though. –  Andy Apr 6 '11 at 10:39
1  
Incorrect in what way? Your average shared host at this point is providing 'unlimited everything', so it's going to be pretty difficult to obtain enough memory so that APC could cache all the necessary files. APC doesn't have a 'cache files that are only frequently used' mode, it's all or nothing. –  devicenull Apr 6 '11 at 12:46
    
It's my understanding that a short ttl will force old objects out. Might be wrong :) –  3molo Apr 6 '11 at 16:28
    
What @devicenull is pretty true. A shared hosting will have difficult time with RAM. As you know a shared hosting can be used by many clients and any one of them can have sites with many php files. APC will cache every php file that has been executed. A workaround to this problem can be setting cache expire. But that won't guarantee that the RAM will be enough. –  tftd Feb 5 '12 at 20:24
add comment

According to http://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.

share|improve this answer
    
It doesn't actually say it will use LRU, it says it will expunge those whose TTL has passed. (And as the other answer noted, it's important to know what happens if there's no room and nothing has passed its TTL - maybe a complete purge.) Perhaps it's this lack of simple LRU system that makes it unappealing for shared hosting. –  Andy Apr 6 '11 at 10:34
add comment

@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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.