1

First of all, we're not interested in the file cache at all for the time being, its the user cache that is important.

We need to store information about database structures and query results in a cache for some applications we are developing.

Our server has dozens of sites on it, some of which are controlled by customers with ftp access.

I'm worried about a virtual host (one where we don't control the php files) screwing with the cache of another virtual host. We can code our applications so that their cache keys don't collide, but we can't garuntee that a customer won't clear or modify our cached values.

We have mod_php on a CentOS 5.3 server with plesk. We have apc.cache_by_default=0 and apc.filters="-/.*" as it having it on seems to break a lot of third party apps we have installed.

I've tried php_admin_flag apc.enabled off and php_admin_value apc.enabled 0 in the vhost, but it seems to have no effect.

Is there any way to completely disable apc for some sites only?

Alternatively, is there any way to have a seperate user cache per vhost? Or a different caching solution? We're considering memcached but I worry that it will have similar problems.

Thanks.

Improve this question

3 Answers 3

Reset to default
1

This kind of usage asks for memcache. Go get memcache, read the documentation at http://memcached.org.

Improve this answer
1
  • Fairy nuff. From what I've read memcache is a little slower than APC (all other considerations aside) so its a shame APC isn't a little more flexible.
    – DaedalusFall
    Nov 1, 2011 at 16:41
1

The issue with APC and mod_php is that mod_php is inside the same process as apache. This means you only get to have one configuration for PHP for all your vhosts.

Try looking into PHP's FastCGI interface. Unfortunately I don't have a lot of experience with setting this up on apache (we use nginx), but we've used this to great effect to separate configurations for different sites on a shared hosting server. Separate configurations means separate everything: You can enable different PHP modules for different sites, have different session stores for different sites, have different upload limits for different sites, etc, etc. Basically, it boils down to having a separate PHP-FCGI server for (at least) every client. Each FCGI server has it's own configuration; we use /srv/$domain/fcgi/php.ini, but whatever works for you and Plesk.

CGI may also work; I'm not 100% on how APC does it's caching. If it's in-memory, then CGI won't help as it creates a new process for every request, which means any in-memory cache would be lost on every request. To be clear, this isn't recommended even if it does work, but it's easier to set up for testing.

Improve this answer
4
  • apc is in-memory cache so it will not work with cgi. It can make sense with fcgi.
    – cstamas
    Nov 1, 2011 at 14:14
  • Thanks. That would be a nicer setup, but what we have works and it'd take a lot of doing to get it set up differently, not to mention retraining people. "Whatever works for you and Plesk." Hah! Thats a tough one. I don't think plesk was designed to do anything vaguely non-standard. I like what I've seen of nginx and its configuration (and mnemory footprint).
    – DaedalusFall
    Nov 1, 2011 at 16:37
  • @DaedalusFall: I've been really happy with nginx. With regards to your problem though, if you're stuck with mod_php, then APC isn't a viable solution ever, so I have to agree with cstamas. Go with memcached.
    – Matthew Scharley
    Nov 1, 2011 at 22:14
  • @DaedalusFall: WRT Plesk, that's why we're moving off Plesk with the new hosting server we're setting up for our clients. Instead, we're using Puppet. There's a bit more upfront cost, but set up well, it's looking like it'll greatly simplify things for us. But that's another conversation entirely.
    – Matthew Scharley
    Nov 1, 2011 at 22:19
1

As stated on this Linux Sysadmin Blog:

enable APC for the particular vhost config or using .htaccess using:

php_flag apc.cache_by_default On
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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