from http://www.php.net/manual/en/apc.configuration.php
... the apc.php script ...
Cache full count number (on the left)
will display the number of times the
cache has reached maximum capacity and
has had to forcefully clean any
entries that haven't been accessed in
the last apc.ttl seconds. This number
is minimized in a well-configured
cache. If the cache is constantly
being filled, and thusly forcefully
freed, the resulting churning will
have disparaging effects on script
performance. The easiest way to
minimize this number is to allocate
more memory for APC. Barring that, the
apc.filters ought to be used to cache
fewer scripts.
when dealing with mesure problems, measurement tools and a quantitative approach(asking yoursel "how much?") works better than "try and fail", so you could invest some time in finding a resonable tool to mesure exactly the problem, say
free -mot
and a testing environment, say your distro in a VirtualBox instance snapshoted to remember sensible configurations, than monitor memory usage under tests with different conf, ie.
ab -n 500 -c 30 http://example.com/mytestapp/myheavyloadaction
tests are meaningless if you try static html page or the helloword in php, you need to test the real application/s and probably modify the application itself to log where it spends time doig what.
we cant reach 0ms per request anyway, so we should define what "fast enough" is for users. 500ms is enough for me, knowing downloading a single gif in the template will vanish hours of effort on the server side.
furthermore, spending real effort on software configuration will not, will never achieve what a blessed RAM addition will.
in my personal experience with LAMP stacks, but for the reasons stated above we cant generalize, mysql usage of RAM is the bottleneck, not php itself (nor apache).
if, and only if, you are absolutely forced to use such poor amount of RAM and you cant insist in purchasing more(2Gb is reasonable for my uses), which is probably the less expensive scenario (kindly insist on the economic aspect of loosing dev hours without real benefit had worked for me...), knowing the real work and expertise this optimization will require,
using your web framework file cache(@see drupal.org/project/filecache) , @see drupal.org/project/memcache or sqlite could be worth experimenting with, too.