Hey.
I am not particulary sure if this is the right list to ask this, but I decided I would just try (besides, its the only list I subscribed to).
For an application that I run, I have bumped against apache’s edge: WebSocket support. But the main application is written in PHP, Yii Framework, so I do not want to move away from this - and cant do that very easily either. So I was thinking about writing my own webserver, maybe in nodejs or the like, but also take best advantage of PHP.
What I mean is, that I read somewhere, that php-fpm, or something similar?, can stay open as a background process and cache scripts, so they are executed faster.
Again, I only skimmed over an article, but sadly do not have access to my browser history at th emoment - and will not for a bunch of weeks - so I can not get back there.
What would you recommend for this? I want to max out the speed of my PHP execution time.
Kind regards,
Ingwie.
Hey.
I am not particulary sure if this is the right list to ask this, but I decided I would just try (besides, its the only list I subscribed to).
For an application that I run, I have bumped against apache’s edge: WebSocket support. But the main application is written in PHP, Yii Framework, so I do not want to move away from this - and cant do that very easily either. So I was thinking about writing my own webserver, maybe in nodejs or the like, but also take best advantage of PHP.
...
You may want to look at how this is done in Phabricator (http://phabricator.org/). Besides, overall being a very interesting piece of modern PHP code, Phabricator uses a very simple node.js server for websockets. The PHP code sends messages to node.js, and node.js distributes them to any listening users. Phabricator is released under the Apache license, so you can cherry pick code easily.
Tom
Am 11.06.2014 um 04:16 schrieb Tom Samplonius tom@samplonius.org:
Hey.
I am not particulary sure if this is the right list to ask this, but I decided I would just try (besides, its the only list I subscribed to).
For an application that I run, I have bumped against apache’s edge: WebSocket support. But the main application is written in PHP, Yii Framework, so I do not want to move away from this - and cant do that very easily either. So I was thinking about writing my own webserver, maybe in nodejs or the like, but also take best advantage of PHP.
...
You may want to look at how this is done in Phabricator (http://phabricator.org/). Besides, overall being a very interesting piece of modern PHP code, Phabricator uses a very simple node.js server for websockets. The PHP code sends messages to node.js, and node.js distributes them to any listening users. Phabricator is released under the Apache license, so you can cherry pick code easily.
Tom
I can pretty much imagine how this works, I am trying to obtain some osurce at the moment.
But what I was really interested in, is how to make PHP use previously ran scripts. Like I run them once, and part of it, like classes and such, stay in memory, instead of having to „recompile“ the script. I thought this is doen using OPcache… Any way I can take advantage of somethin glike this?
I run them once, and part of it, like classes and such, stay in
memory, instead of having to „recompile“ the script. I thought this
is doen using OPcache…
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.
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 „recompile“ the script. I thought this
is doen using OPcache…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.--
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.
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?
I feel the Embed SAPI is better for your case.
The FastCGI protocol is built for the classic HTTP request/response
cycle, not for Websockets' continuous bidirectional pump. You would
find yourself synthesizing HTTP-like requests just to interact with
FCGI. That way madness lies.
I think for the goal "Process websocket messages in PHP code,"
assuming no time/technical limitations, you should lean as little on
other protocols as possible. Sticking to the websocket server's async
I/0 model, with PHP loaded into its memory space so you can write in a
familiar language, would be ideal.
Note I do not know which, if any, opcode caches will load under the
Embed SAPI. You have a lot of moving parts here.
-- S.
On Wed, Jun 11, 2014 at 2:03 AM, Kevin Ingwersen
ingwie2000@googlemail.com wrote:
Hey.
I am not particulary sure if this is the right list to ask this, but I decided I would just try (besides, its the only list I subscribed to).
For an application that I run, I have bumped against apache’s edge: WebSocket support. But the main application is written in PHP, Yii Framework, so I do not want to move away from this - and cant do that very easily either. So I was thinking about writing my own webserver, maybe in nodejs or the like, but also take best advantage of PHP.
What I mean is, that I read somewhere, that php-fpm, or something similar?, can stay open as a background process and cache scripts, so they are executed faster.
Again, I only skimmed over an article, but sadly do not have access to my browser history at th emoment - and will not for a bunch of weeks - so I can not get back there.
What would you recommend for this? I want to max out the speed of my PHP execution time.
Kind regards,
Ingwie.
Hi, Ingwie
Yesterday, I stumbled over something that might be helpful for your -
maybe not ;)
I found out, that there are projects on the way out, that let you
store stuff accross requests. I don't know how production-ready these
ideas are, but you can use them. They work in development ;)
A complete redesigned server in PHP only. Worth a view, I think ...
they borowed much from Java. That's also how I found that one.
http://www.appserver.io/
React is a project, that should let PHP work as Node.JS works.
http://reactphp.org/
I think this is the reason, why you think of using Node.JS at all,
right? Having one process, that has some resources in memory and that
handles all incoming requests - not an engine that has to be turned on
and turns off after each request.
Bye
Simon
Am 11.06.2014 um 14:03 schrieb Simon Schick simonsimcity@gmail.com:
On Wed, Jun 11, 2014 at 2:03 AM, Kevin Ingwersen
ingwie2000@googlemail.com wrote:Hey.
I am not particulary sure if this is the right list to ask this, but I decided I would just try (besides, its the only list I subscribed to).
For an application that I run, I have bumped against apache’s edge: WebSocket support. But the main application is written in PHP, Yii Framework, so I do not want to move away from this - and cant do that very easily either. So I was thinking about writing my own webserver, maybe in nodejs or the like, but also take best advantage of PHP.
What I mean is, that I read somewhere, that php-fpm, or something similar?, can stay open as a background process and cache scripts, so they are executed faster.
Again, I only skimmed over an article, but sadly do not have access to my browser history at th emoment - and will not for a bunch of weeks - so I can not get back there.
What would you recommend for this? I want to max out the speed of my PHP execution time.
Kind regards,
Ingwie.Hi, Ingwie
Yesterday, I stumbled over something that might be helpful for your -
maybe not ;)I found out, that there are projects on the way out, that let you
store stuff accross requests. I don't know how production-ready these
ideas are, but you can use them. They work in development ;)A complete redesigned server in PHP only. Worth a view, I think ...
they borowed much from Java. That's also how I found that one.
http://www.appserver.io/React is a project, that should let PHP work as Node.JS works.
http://reactphp.org/I think this is the reason, why you think of using Node.JS at all,
right? Having one process, that has some resources in memory and that
handles all incoming requests - not an engine that has to be turned on
and turns off after each request.Bye
Simon
Hey!
I have seen Appserver before, it looks pretty interesting indeed, and I found it originally due to the pthreads extension.
Yes, I want to use nodejs to drive the very root - to handle incoming requests and to even support Websockets, which are a thing for my new project. :)
But thanks for pointing these out, Ill look at them!
Kind regards, Ingwie.