Re: [PHP] Re: [PHP-DEV] feature request : easy shared memory

On Mon, Mar 18, 2013 at 3:46 AM, Larry Garfield <[email protected]>wrote:

> 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