Re: APC and CGI

On 09/19/2012 12:39 PM, Marten Lehmann wrote: > Hello, > > I can't find any usable documentation for the usage of APC with PHP as > CGI. But PHP as CGI behind a CGI wrapper in a shared hosting environment > is the mostly used PHP configuration because this is what you get when > you buy an effordable hosting plan to setup some small or medium sized > websites with WordPress, Joomla, osCommerce etc. if you don't have a > high traffic or lots of paying customers. > > CGI means: There is no permanent process or daemon running. Each PHP > process is created from scratch after Apache preforked a child process > that calls the CGI wrapper which in turn calls PHP. That means the > typical way - using shared memory to store opcode - doesn't work. This > also means, that instead of using shared memory, another method to > serialize and deserialize opcode has to be used. This might be files in > a special cache directory or a memcached instance. > > Unfortunately, I really can't find anything on that, but this is the use > case, where page load speed would benefit most from caching by keeping > and reusing the opcode. FastCGI daemons or mod_php keep a lot of stuff > in memory anyway, so while the boost when using APC is surely noticable, > it's not that much compared to what would be possible if a newly created > PHP CGI process didn't had to load and parse a PHP-file and all its > includes each time the script is called. > > APC is not a young project, so I wonder that I can't find discussions > about that. We haven't done anything about making APC work for CGI for two main reasons. 1. If you are using a fork-per-request CGI model you are obviously not that concerned about performance. Dedicated VM hosting prices have dropped dramatically in the past couple of years, so it is within reach of just about anyone to get a decent setup. 2. We point the executor directly at the op_array in locally mapped shared memory. We also have top-level function and class caches for each op_array in shared memory with the opcodes to create these NOP'ed away. If we were to read an op_array from something like memcache we wouldn't be able to do any of this. We would do extremely well to just match the performance of simply re-parsing from disk with having to connect, copy, munge and execute these from a remote source on every request. Plus you have added latency in actually caching these to a slower storage mechanism along with the stat check overhead on each request. -Rasmus