Re: Using an APC-lite in a GCI / SuPHP environment

Just to pick up and update on this thread about my suggested development of an APC-lite (which I call LPC) for a GCI / SuPHP environment, and Rasmus alternative suggestion of extending APC functionality within a PHP-FPM context

So you run an instance for each version. That doesn't seem like much of a problem to me. Whether you have 1 parent process with 1000 children at any one time versus 4 parent process with 250 children each really doesn't make that much of a difference. I'm just trying to save you guys some time and energy. It will take you months to build this opcode caching solution and in the end it is very likely actually run slower and use more memory than not having it at all.

Rasmus you were correct about the "taking months" point. In the end I've pretty much had to recode this from scratch as there are too many implicit and explicit differences between the APC SMA-based and the LPC file-based approach. However, development is progressing well, and I've a got a reasonably sold Alpha version of the code base -- which is incidentally about one third of the size of APC. I've been running it against my own test vectors as well as the ~800 test scripts in the php tests suite. I've got 7of the PHP tests scripts which currently fail for known issues and I am working through these. MediaWiki works OK, for example. Incidentally do you run APC against the PHP test suite as part of its release tests? As far as runtime performance goes, initial indications are that the APC and LPC run times are much of a muchness. After all if the file-based cache is in the VFAT caches then this is basically SMA albeit accessed though some kernel mode APIs, but of course LPC maintains this level of performance for usecases where APC can be used. I agree that as LPC always does a deep copy for execution then the per active-thread memory requirements are higher, but again in typical LPC use cases there are usually 0 or 1 active threads running a given script, and higher concurrency numbers are quite rare, so in practice this isn't a material issue. I still have some know issues to complete before I move my git repository into publicly accessible github: - Close off these test failures - Debug ZE 2.4 changes (I am currently testing on 2.3) - Kill off remaining emalloc leaks. (Typically 1 or 2 strings per source file included and they're emalloc leaks which get garbage collected during request shutdown anyway -- so this isn;t really a high priority.) - Do some some further performance optimization and fuller performance benchmarking of MediaWiki for LPC vs APC. At this point I'll have something reasonable complete, consistent and full working version, accessible from github. I will have performance data to post back here for an evidence-based discussion of the SWOT of this LPC approach. Hopefully, I'll complete this work before the new year. If I don't hear from you before that, then in the meantime I hope wish you a merry Xmas and happy New Year :) Regards Terry Ellison