APC for PHP: Number of keys, single vs multiple segments

[ffoeg]

Hey all.

I'm not too sure whether this should be filed under the Apache forum, but I reckon it relates more to PHP than Apache.

It's actually a two-part question, both relating to APC:

Question 1
I've been trying to Google some information on this for the past while, and can't seem to come up with anything.

Does anyone know which is better when using APC ([php.net ]):

• A single segment of (for example) 96MB, or
  
• 3 segments of 32MB each.
  

And possibly, under which circumstances each would be preferred? The reason I ask this is I have APC in place on one of my systems, and it's currently running at an available cache size of 512MB. However, the fragmentation on this instance is massive. I'm wondering whether splitting the cache into multiple segments might help.

Question 2
At which point does it become more beneficial (if at all) to start storing cache entries on the file system (in terms of number of cache entries)?

My APC cache currently has more than 15,000 entries in it, and the bulk of them have a key of

dev-________________________________

. I have a feeling that the sheer number of these files is what is causing the cache to become so fragmented (as per question 1). Would anyone please tell me whether or not it would be better to cache these d_* on the file system, or still keep them in the APC cache (and why, if possible :)).

Thanks!
Geoff

[coopster]

Doesn't seem anybody here is using APC, Geoff. What did you end up with?

[ffoeg]

I ended up using a single segment of the size I was looking for.

From the reading I've done, it appears as if the multiple segments are available for those servers that have restrictions in the size of their shared memory segments (Hence the "shm_*" options available for it, I think).

I'm not a hardware or OS specialist at all, so I don't understand all of it, but that's what I understood about it.

As for the second question, I put my hat of understanding on, and read some of the blog posts on it. The fragmentation can't be solved by multiple segments.

As cache entries are added and removed, the amount of contiguous free memory becomes less and less, which is what causes the fragmentation. The best thing I've found for this is to set the cache value TTL to 0.

This allows cache entries to sit, and doesn't expire any of them. As a result the cache becomes fuller and fuller, until it reaches the point where there is no more free memory. At that point, the cache is completely purged, and everything is removed from the cache.

I would have preferred it to not have to purge itself, but I figured that it would be better to have it managing itself as it got full.

It works for me :) And the fragmentation explanation is quite simplistic - but it's there for anyone newcomers that might not quite understand what I mean.

[coopster]

Next question, did you consider any other caching mechanism? Here is a thread from the past ...
[webmasterworld.com...]

[ffoeg]

I did. I was considering Memcache too. I looked at Xcache and eAccelerator, but considering APC is maintained by the guys that maintain PHP - I figured it the better choice.

However, I must admit; I haven't run into any issues with the version of APC I'm running (the default version that comes packaged with Ubuntu Server 64-bit). I have noticed though that Memcache doesn't appear to have any fragmentation issues like APC does - this could be due to the mentioned method in which it invalidates cache items.

Back to the Memcache issue though. I figured that it would be better to stick with APC, as the caching is all in-process with Apache. Using Memcache would mean having to break out of the process.

I suppose it could all be much of a muchness - I'm not a server expert, and most of what I've found out has been via research and reading of *many* blogs!