Re: Embedding PHP, few additional questions.

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