Re: Embedding PHP, few additional questions.

Am 27.06.2014 um 17:29 schrieb Johannes Schlüter <johannes@schlueters.de>: > 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. Okay. I will be looking into the source of PHP and documentation, going to try and understand it further. Looks like, that what I have learned so far, is like just 1% of what I really need to know - kinda scary, but also a challenge I wish to take on. >> 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. Well, I tried to understand all the odd TSRM macros before, but I couldnt find a real answer - just that I had to put them into certain places, but never why. Now it just clicks in and makes sense. Sadly, some parts of PHP are not documented - or, the documentation is very outdated… (I.e. I found an embedding guide for PHP 4 before finally finding one for 5.) > >> 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. Now that you notified me of this thing that I did not think about, I will have to really make a new design. I have not used Solaris, but I heared many good things. Currently I have stuck to Debian - but this enhancement sounds like one point to consider switching distros. I am getting a new server anyway, good opportunity to learn new things. o.o >> 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 It’s definitively not the first time somebody said that…haha. I know that PHP and NodeJS have by -far- different ideas of how things should be handled and worked. But currently available webservers dont support Websockets too well. So my last solution was to use nodejs directly. And since I am often on environments where ports other than 80 are blocked (my school, for example). So I was looking for a way to use it all thru one port, and many things behind the scenes. Which in the end made me end up with getting to the point, where I needed to run PHP underneath nodejs. Its not truely a „language-to-language“ binding - its just giving PHP something to process and return the output. The both are completely isolated - except the fact that they are stuck in the same memory/program space - and dont really interact with each other. Basically, I just want to write a SAPI under nodejs, simialr to Apache. And that is why I am currently sitting here, with mod_php5.c open. Kind regards, Ingwie.