Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74839
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
Date: Wed, 11 Jun 2014 02:16:41 -0400
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Message-ID: <557316051.20140611021641@cypressintegrated.com>
To: Kevin Ingwersen <internals@lists.php.net>
In-Reply-To: <C3EE09E2-F9D1-41EA-8526-BA82F335E9A8@googlemail.com>
References: <2C3AA922-B514-45C0-940E-EBF6F931BCE1@googlemail.com> 
  <FE44E607-D3F0-4697-B513-245737695BF2@samplonius.org>
  <C3EE09E2-F9D1-41EA-8526-BA82F335E9A8@googlemail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Own webserver, with PHP plus opcache/similar?
From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman)

> I run them once, and part of it, like classes and such, stay in
> memory, instead of having to =84recompile=93 the script. I thought this
> is doen using OPcache=85

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.