0

As we know, PHP works in the "share nothing" phylosophy. It therefore is bound with serious performance limitations.

While a compiled script can be accelerated by some caching extensions we cannot avoid very heavy initialization (for example, we have a web-service and every call will at least require parsing and bootstrapping DTO schemas, setting up data bindings, connecting database (persistent mysql connections is really dirty hack from that perspective), opening another remote services and so on).

Also this problem seems to be solved by ReactPHP framework, but... do any lightweight non-framework solutions exist? Anything from hack ways, one-file examples to lightweight libraries (not frameworks) accepted. No complex web-server recreated functionality required. Just handling plain POST requests is enough.

<offtopic>

The task itself is so essential so I wonder why PHP is not providing this out-of-the-box yet...

</offtopic>

Mikhail Karakulov
  • 193
  • 2
  • 9
  • With opcache and all, this shouldn't have a very big impact. Most framework will only load the required modules to handle the current task. While I am not sure about HTTP POST, sockets could work. – Salketer Sep 08 '17 at 12:46
  • Let us suppose module loading is not a bottleneck, but initialization where we must share set up resources. ReactPHP (the only such framework?) solves it but using it means dependency on complex framework with not very high support. Too risky for such simple task. – Mikhail Karakulov Sep 08 '17 at 12:54
  • Don't you think if it was really such a simple task there would be other solutions too? Everything in PHP is stateless. Unless you'd use stateful resources with exec() and keep PHP very slim, that's gonna be hard. But I really doubt that this "bottleneck" causes you harm while Facebook has no problem with it... – Salketer Sep 08 '17 at 13:01
  • Saying "bottleneck" I mean efficiency of hardware and network usage. Of course we can add 100 another servers and go drink beer. But we are not Facebook and have no such resources. And source code of facebook is not open who knows maybe they solved that in their own way. – Mikhail Karakulov Sep 08 '17 at 13:09
  • Anyway the answer could also be "move to node.js", but php as a language is too powerful to be abandoned just for it poor available out-of-the-box "stateless" environment. – Mikhail Karakulov Sep 08 '17 at 13:12
  • @MikhailKarakulov: No, ReactPHP isn't the only such framework. There are others like [Amp](https://amphp.org/). These exist, because PHP's internal APIs for non-blocking streams are a PITA. The advantage of Node is that the whole ecosystem is built around non-blocking streams and the event loop, blocking APIs just don't exist. – kelunik Sep 17 '17 at 08:35

2 Answers2

1

One fine way to do it is have a CLI script that would act like your normal Java/nodeJS server. And use a light PHP gateway to receive the HTTP requests and require the needed info from the CLI through socket.

An interesting read is http://liveforeverbook.info/blog/2008/01/31/persistent-web-apps-in-php/

The key to this is that the CLI script keeps the message store in-memory (like the Java service), and communicates with the client through a web-based PHP “gateway”.

IRC server <--> PHP Gateway <--> Client The gateway step is not actually required, but helps to filter out the rubbish that might come through if the IRC server was connected directly to the net.

You start the IRC server running as a script from the console (php server.php), and leave it running. CLI scripts have no timeout, so it will keep running until you manually turn it off.

Salketer
  • 14,263
  • 2
  • 30
  • 58
1

do any lightweight non-framework solutions exist? Anything from hack ways, one-file examples to lightweight libraries (not frameworks) accepted.

Depends on what you're looking for. You will need some sort of event loop / scheduler, which is mostly what amphp/amp / react/event-loop provide. If you don't want to die in a callback-hell, you'll need some form of promise implementation, provided by amphp/amp / react/promise.

If you see those parts as a framework and don't want to use those, you can of course write them yourself. But then again you're looking for stable software, any of these will be more stable than your own implementation, because they're way more widely used and bugs are reported and fixed.

Anything on top of these basics are just libraries. You can use them or write your own. If you happen to just need a socket server, why not use the libraries that already deal with PHP's edge cases as well as possible?

No complex web-server recreated functionality required. Just handling plain POST requests is enough.

Oh, what's a complex web-server? "Just" handling plain POST requests? You will need an HTTP protocol parser that deals correctly with pipelined requests, decodes chunked encoding, a multipart parser if you want to deal with uploaded files, etc.

If you're just looking for handling multiple requests in a single PHP process without repeated bootstrapping, I'd suggest taking a look at PHP-PM, but at this point it's not production ready.

kelunik
  • 6,750
  • 2
  • 41
  • 70