Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Ingwie Phoenix <ingwie2000@googlemail.com>
Cc: internals@lists.php.net
In-Reply-To: <69DDB98B-1874-43BA-B6DB-B878C8E54DBF@googlemail.com>
References: <A4851D00-E21D-4A74-8A84-C77B4DE09FAD@googlemail.com>
	 <1403777679.12695.14.camel@guybrush>
	 <0DF815F8-5991-46EC-9BD4-53575F774BAC@googlemail.com>
	 <1403860716.12695.34.camel@guybrush>
	 <02B340AD-6EED-497D-85EC-F5C37A7504B6@googlemail.com>
	 <1403878800.12695.58.camel@guybrush>
	 <69DDB98B-1874-43BA-B6DB-B878C8E54DBF@googlemail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 27 Jun 2014 17:29:28 +0200
Message-ID: <1403882969.12695.97.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Embedding PHP, few additional questions.
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2014-06-27 at 16:53 +0200, Ingwie Phoenix wrote:
> > 
> > Forget Opcache. Get the PHP model of the request based approach
> > which
> > goes through PHP's complete architecture. opcache comes in in the
> > end
> > (more or less) easily.
> What do you mean by that? It might be my english, but I did not very
> much understand what you ment.
> 

You are asking "How can I use opcache in some environment, which I
actually don't know"  while the actual question should be "What's PHP's
internal architecture especially in regards to SAPIs". Opcache fits in,
in the end, once the architecture is understood.

> Actually, I am indeed scrolling thru pconn. It currently has the most
> clean API showcase that I can see, to be very honest. 

It does a trivial thing, has neither user interaction, nor external
systems to interact with. That's one I like to show it as example for
these questions. While it's not perfect. But those are details.

> But now, you actually finally helped me understand soemthing that I
> always wondered: the TSRM_xx macros! Now it makes sense why they are
> everywhere, acting as a sort-of mutex…or more, a thing to
> differenciate between threads. Always got confused about how this
> actually is used - well, now I know. A lesson a day, keeps the
> dumbness away, methinks! ^.^

"thread safe resource manager" ... again try to dive in, into the
architecture of PHP.

> Oh s… That I did not know/consider. So if, for some reason, the PHP
> instance crashes or dies, all other instances, and possibly the rest
> of the application, dies too? Wow. Guess I should create a watchdog
> that keeps track of the service.

Well each service should be watched. On good operating systems (note:
Solaris ad coming up) you can define contracts in regards to processes
the kernel should watch as soon as they misbehave a service manager will
be notified and can take action. But well, that's a generic issue, also
nodejs/v8 can crash in some situations etc.
For a system design the question is: How can you limit the risk and
impact. With your design everything is lost and has to be restarted.


> The goal is to run websockets, a cdn and db cache together with
> HTTP(S). So turning into REST based service would actually make the
> structure more complex.

You seem to have a different definition of "complex" than me. I consider
a monolithic block, mixing multiple language runtimes which follow
completely different paradigms ("stay away from threads an use events
and be light weight" vs. "have a shared nothing conatainer handling one
request after another") and which both are quite sophisticated to be
quite complex, whereas I consider an architecture of smaller independent
components, which I can maintain, scale, ... independently cleaner.

johannes