On Mon, Mar 18, 2013 at 3:46 AM, Larry Garfield <la...@garfieldtech.com>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
