Re: APC's performance improvement patch for single process multithreaded php

Basant Kukreja wrote:

Hi, I gave a thought about the multiprocess setup and thought about changing single_proc to use_process_mem but later concluded that this option won't work if multiple copies of cache existed. Here is a case :

Suppose apc.stat is set to 30 seconds and assume "one.php" is served by 2

processes and suppose they create cache for one.php at different interval time. Now suppose one.php is changed, different process will update the cache at different time so same one.php request will be served differently (one from old version and one from new version) at the same time which of course is incorrect.

You can't set apc.stat to 30 seconds, it's a binary flag so it's either on or off. In the off scenario this isn't an issue as the files will never be updated unless you happen to cache two different versions on the first request for each process. If apc.stat=1 then each request should stat the disk for the file, and you're once again ok as the window to get two different responses is only as long as it takes to process the request.

I have refreshed the patch as trunk was changed. Please provide your comments.

Interesting, could you provide some performance metrics with and without this flag set? I wouldn't have thought that anon mmap is actually that much overhead, likewise if it is I'd be also interested to know what the performance difference between that and IPC shared memory configuration is. The biggest difference I could see is the locking mechanisms, but I think there's more memory efficient ways to improve this (ie: spin locks). Please let me know if I'm missing other performance gains somewhere too. -shire