Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74846
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.212.170 as permitted sender)
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Content-Type: text/plain; charset=windows-1252
In-Reply-To: <557316051.20140611021641@cypressintegrated.com>
Date: Wed, 11 Jun 2014 15:01:06 +0200
Cc: Kevin Ingwersen <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <7E0ACCCC-54E6-4CAC-9813-4FF86E0F55C4@googlemail.com>
References: <2C3AA922-B514-45C0-940E-EBF6F931BCE1@googlemail.com>  <FE44E607-D3F0-4697-B513-245737695BF2@samplonius.org> <C3EE09E2-F9D1-41EA-8526-BA82F335E9A8@googlemail.com> <557316051.20140611021641@cypressintegrated.com>
To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Subject: Re: [PHP-DEV] Own webserver, with PHP plus opcache/similar?
From: ingwie2000@googlemail.com (Kevin Ingwersen)


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 =84recompile=93 the script. I thought =
this
>> is doen using OPcache=85
>=20
> OPcache and other bytecode caches accelerate PHP in two ways that meet
> your needs as described:
>=20
> [1] They enable PHP to run compiled bytecode, if available, instead of
> your raw(er) script code, improving response time and reducing CPU
> demand.
>=20
> [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.)
>=20
> So far, so good.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> -- Sandy
>=20
>=20
> * 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.
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

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.=