eZ Community » Forums » Install & configuration » Tip: Use APC filters to optimize...
expandshrink

Tip: Use APC filters to optimize cache usage

Tip: Use APC filters to optimize cache usage

Saturday 27 November 2010 8:05:09 am - 9 replies

APC is a great opcode cache for PHP that provides significant performance gains for eZ Publish and other PHP applications.

If you run a large eZ Publish installation with proper caching you might end up in a situation where your APC cache keeps filling up with eZ Publish cache files. You'd rather have the kernel, etc. code in the cache than HTML snippets.

Look into APC filters to manage which files are cached by APC and which are not: http://www.php.net/manual/en/apc.configuration.php#ini.apc.filters

something along the lines works for me:

 apc.filters = "-(.*/cache_siteaccess1/.*\.php)|(.*/cache_siteaccess2/.*\.php)" 

This could probably be further optimized, but it aint' broken.

Modified on Saturday 27 November 2010 8:12:13 am by Jani Tarvainen

Saturday 27 November 2010 5:32:30 pm

Very good advice !

Cheap, efficient. There are other caches you might be interested in:

  • anonymous user info cache
  • translation cache
  • expiry cache
  • wildcard cache ?

Saturday 27 November 2010 10:21:06 pm

I agree excellent piece of advice !
Have you tried the before/after performance test after applying it ?

Cheers,

Monday 29 November 2010 5:57:49 pm

CentOS server with multiple virtual instances of eZ Publish running on one server.

Installed APC 3.0.19, got only 15 percent cache hits with default configuration and no apc.filters set.

Added to php.ini:

apc.filters = "-cache.*\.php"

This instantly boosted cache hits to 25 percent and noticeable speed improvement versus before APC install.

Surely more tweaking to be done, but very much thanks to Jani for the heads up!

Monday 29 November 2010 6:59:52 pm

@Doug excellent idea, even though I'd normally go for putting as much stuff as you can in your APC cache.

But the best thing is: if you remove from the APC cache all the files generated by eZ, you can then simply

1. tell APC not to check the staleness of its cached files vs. timestamp of original pph files on the fs (apc.stat=0 in php.ini) and get a speed boost and IO pressure decrease on your fs (great if your install is eg. on NFS)

2. remember to clear APC cache by hand after every delivery of a new site update

Could you provide us with some numbers about page load times / reqs per sec. before and after the change?

One thing to note though: you might want to tune your templates, you might have cache-blocks that keep churning (use ggsysinfo to get a graph of the number of files-added-in-the-cache-per-minute on your install), as otherwise your apc cache hits should be much higher - f.e. the php files in the template cache should never expire, and be good candidates for APC caching.

Or you have just too little of shmem given to apc. What is your usage of it's allocated memory?

Going slightly OT: a lil' while ago I experimented with the best format to be ideally used for storing those caches that are basically data structures: plain php or json or serialized php.

The goals:

- try to use a format that is not cached by APC and friend by default, as it is basically memory wasting

- have the format that is both faster to load and using less memory for deserialization

It is to be noted that right now eZP uses all of those formats for different caches - picking a single format would also help in the overall goal of cleaning up cache management mechanics.

In the end my tests where not conclusive: depending on php/os version and presence or not of an accelerator the results changed.

But I'd be happy to pick them up again if anybody else is interested...

Thursday 24 March 2011 6:15:17 pm

2. remember to clear APC cache by hand after every delivery of a new site update

Hi Gaetano and all. Actually we're having some randomly perfomance problems in one of our developments. hosting company has pointed me to this topic.

about your reply, for 'new site update' i suppose you are talking about code updates right? (not content updates).

thanks in advance.

Thursday 26 May 2011 5:03:50 pm

@Carlos: yes, I do talk of code updates, not content updates. The point is that you can do this iff php code generated as part of "content caches" is not stored in the apc cache...

Friday 14 December 2012 10:50:38 am

Hi, 

are there some updates about this topic by you, experienced apc users? happy.gif Emoticon

our apc production server's memory is always full (apc.shm_size=90M), so we better tune apc.
What is the best approac? filter our cache? set apc.stat=0?

thanks

/francesco 

 

our server:
RHEL 6 (2.6.32-279.11.1.el6.x86_64)
Nginx 1.2.4-1.el6.ngx
APC Version 3.1.13
PHP Version 5.3.18  (php-fpm 1.2.4-1.el6.ngx)

Saturday 15 December 2012 11:17:21 am

@Francesco don't be "avaro", bump the memory allocated to APC to at least 128 - maybe 256 MB.

As for apc.stat, I've been told that recent versions of apc take a much lesser performance impact from it, so you might want to leave it enabled...

Tuesday 18 December 2012 10:56:50 am

Quote from Gaetano Giunta :

@Francesco don't be "avaro", bump the memory allocated to APC to at least 128 - maybe 256 MB.

As for apc.stat, I've been told that recent versions of apc take a much lesser performance impact from it, so you might want to leave it enabled...

thank's a lot Gaetano, apc.shm_size=256M: that was it.  

all warnings, as the follow, disappeared indeed:

 PHP Warning:  require(): Unable to allocate memory for pool. in .../html/autoload.php on line 101
expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from