Re: Own webserver, with PHP plus opcache/similar?

Am 11.06.2014 um 08:16 schrieb Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>: >> I run them once, and part of it, like classes and such, stay in >> memory, instead of having to „recompile“ the script. I thought this >> is doen using OPcache… > > OPcache and other bytecode caches accelerate PHP in two ways that meet > your needs as described: > > [1] They enable PHP to run compiled bytecode, if available, instead of > your raw(er) script code, improving response time and reducing CPU > demand. > > [2] They retain that bytecode in memory, reducing disk I/O demand > (after initial load and compile) to only fast freshness checks. Some > caches allow disabling such checks completely or running them only > periodically. (Those setups require a process restart, manual flush, > or a time delay in order to pick up file changes.) > > So far, so good. > > But be wary of expecting full-time magic from opcode caches. For one > thing, they must be rebuilt across server restarts (being memory-based > and all*). They'll also be destroyed -- necessitating a reload of all > pages -- in other situations, depending on your web server + SAPI. If > no PHP processes are running, there's nothing to hold onto shared > memory: imagine if all FastCGI workers exit due to idle timeout, or if > your webserver launches worker threads and you restart it. And I know > of one cache that is otherwise stable and fast, but forcibly empties > itself every 15m (or maybe it's 30m?). All these are recipes for > periodic resource spikes after long periods of calm, but that's > something you live with. > > Caches also have a policy of automatic eviction of individual records, > after a period of disuse and/or when there is known memory pressure, > i.e. the memory allocated for the cache is running low. Thus a given > page can't be *guaranteed* to be cached at any point in time. > Frequently used pages are *almost* guaranteed to be cached and *on > average* any other pages that see traffic will run from cache. Just > not Every. Single. Time. Caching does not obviate the need to write > tight code and have a worthy disk subsystem and CPU. It just means > well-written code will run even lighter and faster. > > tl;dr: if you use any SAPI that stays running after a request (i.e. > anything other than old CGI) an opcode cache not only meets your reqs > but is, frankly, mandatory (that's why OPcache was added to 5.5). > > -- Sandy > > > * You can also look into caches that use a disk layer to add > persistence. Terry Ellison had worked on a fork of OPcache. Once you > expand into disk caching it is also worthwhile to think about *output* > caching (response fragments, et al.) not just bytecode caching. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hey Sandy. Thank you for this very long, detailed and informative reply! I am sure I learned quite a lot about caching now that I shall keep in my mind for further investigation! :) I am thinking about the difference of using a remote process, or writing my own SAPI ontop of the Embed-SAPI - maybe making a C++ module to nodejs, so I can kick requests and thei rhandles into a different thread, and have nodjs interact directly with PHP, rather than a process. I dont know though, how efficient that is, when looking at caching. Do you think I should rather spawn an array of php workers (and if, -cgi or -fpm?) or write my own layer using the Embed SAPI? Kind regards, Ingwie.