On Mon, Jan 27, 2020, at 8:19 AM, Robert Hickman wrote: > > > I'm not sure that would work well for Web Sockets, because it still > > relies on the traditional request-response cycle, but I've never really > > used them, so don't know what kind of architectural patterns make sense for > > them. > > > > Considering the Swoole PHP extension (https://www.swoole.co.uk) the > > long-running process would take the place of its functionality and new apis > > to communicate with a long running process could allow communication that > > resulted in regular requests being able to send messages via the web socket > > server, and read queued messages from the web socket server. > > > > You won't be able to process notifications to clients via > > request-response, but where that is needed it would be done by the > > long-running process. So the request-response might "register" a > > notification listener to the long-running process, for example. > > > > A web socket is just a way of re-using the tcp connection from a http > request and holding it open for bidirectional communication. Due to this > you can make assumptions about performance charicteristics from other long > running socket server approaches. > > From what i understand, the main problem with using fork or a thread pool > for handling sockets syncroniously is overhead caused by the switching > between userspace and os kernel space, as well as high memory overhead. > Using fork would have the same behaviour as something like apache prefork. > Handling a long running connection entails a process per connection, which > could mean an awful lot of processes. > > Pretty much everything seems to be switching to async io based on some > event loop, as it allows a single process to handle requests from a large > number of connections, and long tunning but sparsely used connections don't > require holding processes open that are mostly doing nothing. > > Based on what i see from the direction things are going in other languages, > just 'getting with the times' and switching to an event based model > probably makes the most sense. > > Anyway, i think PHP really needs to be able to handle web sockets in core.
async IO and promises (sometimes wrapped into async/await) has been growing in popularity, but I would be highly cautious about adding them to PHP. Async functions are viral, and once you start down the async path, forever will it dominate your code base. Adding a single async call somewhere can force you to refactor large swaths of your code base. This is an excellent writeup of why we should be very skeptical of that approach: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ I want to point out that there's 2 or 3 very different use cases and models being discussed in this thread, and it's important to keep them separate: 1) Faster bootstrap time for shared-nothing requests. This is the "partial start" option that a few have mentioned. This would be mainly to avoid the cost of data initialization like the DIC (as preloading already has the potential to avoid the cost of code initialization), which in turn could allow for different optimizations, like pre-creating all service objects rather than coming up with complex lazy-creation and code compilation logic. But each request is logically separate and cannot interact. 2) Long-lived processes. Currently this can only be done via the CLI, and is more the model used by most compiled languages. Usually this is done with a single process that multiplexes multiple requests, which requires some sort of multiplexing tool; either async IO, threads (including nicer models like Go and Rust use), or process pools. Let's please not assume async IO is the obvious best answer just because that's what Javascript does. 3) Technically, process pools could allow for long-lived processes that don't require inter-process synchronization but still allow processes to stay open until explicitly closed. That might be a more approachable model for most current PHP devs. I cannot speak for how easy any of those would be to implement. But let's be careful which one we're talking about and not confuse them. Also, let's avoid the trap of assuming that a long-lived multiplexed process must be using async IO. That's only one model among many, and one with a lot of very unpleasant implications we should be very wary of. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
