On 20/02/13 08:26, Stas Malyshev wrote:
That depends of what your error handlers do. Some may write to log
files, etc. if not configured properly (since error_reporting setting
doesn't have to be considered in it). IIRC, for most of the cases O+
should be able to resolve all includes/requires on cached files
without syscalls - but file_exists is a different matter since caching
it in generic case can be very dangerous.
I am not suggesting caching file_exists but rather encouraging coding
patterns which avoid its use /if/ the application is intended to give
good cached performance -- e.g. apps like mwiki, wordpress and drupal.
I guess that I should bite the bullet and switch to 5.5. I've been
working on an evaluatorfork of APC optimized for CLI/GCI which tackles a
lot of these issues head on and performs reasonable well, but I realise
that this is a dead-end and will never get deployed, but I am currently
considering regressing some of this technology into 5.5 and O+. Are you
interested in a version of O+ which supports all SAPIs?
I think right now O+ can support CLI (provided enable_cli is set) but
for most cases it's kind of useless since scripts are rarely re-included
in common CLI scenarios. So if you know how to improve common CLI
scenarios it may be interesting, though I imagine it's not the most
common use case. But if it adds there without problems for anything
else, why not.
Let me get a dev stack for 5.5 and O+ up and then I can comment on
this. As far as APC's support for CLI goes -- the cache doesn't connect
to the apache2 SMA even if you run the cli process in the same UID, and
since the SMA gets released when the process count goes to zero, caching
doesn't really do anything as the cache discarded between cli
executions, so if practice you always run uncached.
As to the frequency of the use case, maybe not in the case of cli, but
cgi is still tremendously common, as shared hosting providers still need
to implement UID-based separation of scripting environments for
different user accounts. There are still significant scaling issues
with php-fpm in this usecase, so only a few SHPs offer FastCGI support
and then only as a premium option. BTW, I saw that you recommended in
one of your blog posts that you to use a bytecode cache if you care
about performance should do. However, a lot of app maintainers who use a
shared hosting service do care about performance but don't have this as
an option :-(
For example with my cli-based LPC opcode cache, I can do a series of
"make test" runs (1) with the opcache disabled; (2) with it enabled but
the cache empty and (3) with it enabled and the cache(s) primed.
Ideally all three (*) should give the same test results, and this gives
you confidence that the cache is working properly. I would like to do
this with APC or O+, but in practice AFAIK, I can't do (3) so how do I
or the developers know what PHP and extension features aren't being
supported / working properly when the code is cached?
(*) With the tests as currently written, some fail with case (3) because
the runs are missing compiler warnings which are only generated if the
code isn't cached (and in case of my cache at its current build quite a
few fail because it still doesn't play nicely with other extensions like
phar.)
