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

> 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.