Description:
------------
We have just switched from eA to APC. Previously we had 
segfault problems with APC on our, but it seems much 
better now, great work! Both exhibit the same problem.

We are caching around 400-500 files on a 2 x Dual core 
Opteron machine (ie 4 cores, 64Bit). 

We have 128MB of cache configured, about 40-50MB is needed 
for the 400-500 files. When the load is small loading the 
files from the cache takes 100ms. When the number of pages 
per second increases the loading of the class files 
quickly becomes the bottleneck and takes 1-2s. 

We have discussed this problems with the devs over at eA 
and it appears that eA obtains RW locks on the relevant 
memory block for each cache request. When 4 CPUs are 
trying to do this at 10 pages/sec for 400 files per page, 
you quickly get into a runaway lock situation.

Question:
a) Does APC have a similar locking stratgy (ie RW) as eA? 
It seems that maybe it does, since even when non of the 
files are being changes (ie a RW lock seems unnecessary, 
when a read-only lock may have sufficed) the runnaway lock 
situation quickly occurs.

b) do you experience with testing APC on SMP systems and 
if so do you have any advice on how to make APC scale to 
this kind of hardware.

The only way we are managing to run our application 
successfully with this many files/cpus is by using "load 
on demand", ie autoload..etc. We are also experimenting 
with a "package file system" where many files are grouped 
together into one larger one. However this presents quite 
a few problems too, not least the fact that debugging line 
numbers are no longer correct.

Thanks in advance for your help

Oliver




Reproduce code:
---------------
40-50MB is needed for the 400-500 files

Expected result:
----------------
no significant locking delays with 4 CPUS

Actual result:
--------------
very significant locking slow down