On Mon, Mar 18, 2013 at 3:46 AM, Larry Garfield la...@garfieldtech.comwrote:
On 03/14/2013 01:21 PM, Bob Weinand wrote:
Sharing active memory between processes goes against the shared nothing
design of PHP. The lack of the feature you're describing is itself a
feature. :-)
If you had real shared memory, then you're now writing a multi-threaded
app. Even if you aren't using threads per se it's the same level of
potential for spooky action at a distance. If your problem space really
requires that (and there certainly are those that do), Java or NodeJs will
suit you better because those are built specifically for a
persistent-server model, rather than PHP's shared-nothing design. However,
in practice most PHP/web applications don't need that, because HTTP is a
stateless request/response system. Shared-nothing more closely models what
the actual environment is doing, and can still be very performant as long
as you don't do anything naive.
If you're doing something stateful like Web Sockets, then you can run
PHP as a cli application that is its own persistent server rather than as
an Apache add-on. For that, look at Ratchet: http://socketo.me/
--Larry Garfield
If PHP should be so restrictive against sharing, why are there extensions
like memcached, ...? Someone must have missed this possibility to share
rapidly...
If I need something like websockets, I use the pthreads extension:
perfectly suited for stateful applications.
For example: I want to have the database in memory (no, no mysql
Memory-tables; this is too slow...) and only do the updates into the
database for faster access when most contents are read-only. What are these
good reasons against such a feature except it violates the shares-nothing
superlative of PHP. (Even if this feature would exist, you can still write
PHP without sharing)
Bo Weinand
Memcache is out of process. There are possible race conditions there, but
FAR fewer and FAR more contained than true multi-threaded environments.
This list has debated the merits of shared-nothing many times before; it
was a deliberate design decision in the interest of simplifying development
for the overwhelming majority of users. If your app is so performance
sensitive that a memcache lookup is going to bring it to its knees, then
either you're misusing PHP or you're better off using something other than
PHP. (PHP is not the tool for every use case.)
In any event, adding true shared memory to PHP would be nearly impossible
without completely redesigning the way it interacts with web servers. The
alternative is to write your own PHP CLI application that connects to
sockets itself and runs as a daemon (possibly using the pthreads extention
as you mention), and cut apache/nginx out of the picture entirely. If your
use case calls for that, knock yourself out. But the good reasons
against adding such a feature is that it would require rewriting everything
and rearchitecting the entire Apache SAPI, which is not happening any time
soon.
--Larry Garfield
I don't see why you would need to cut out apache/nginx. I would set up the
server just like you (Larry) describe, with socket pthreads, but it would
be far more easier to just create a simple php file inside your
apache/nginx directory. Use something like mod_rewrite to redirect all urls
to this php file. In this file, connect to the application server, send the
request data ($_GET, $_POST, etc) to the application server, and pass all
data retrieved from the application server back to the user.
And there you go, you have an application server.
- Matijn
