ReactPHP http server for each user, Is this a good idea?

Question

ReactPHP http server for each user, Is this a good idea?

In my application:

1. Each logged on user sends and receives data from server. In average one request per second.
2. After server response, the server have some extra work to do, which is related to specific user.

I can simply build new ReactPHP http server for each user who logs, and release the server after the user log out.

Is this will work? Am i missing something ?

Answer 1

No, it's not a good idea. You need a separate port per user in that case to route the user to the right server. That'd quickly exhaust your ports.

If you have blocking tasks within the event loop and want to use multiple processes because of that, just stick to traditional PHP with mod_php or php-fpm and start a new event loop for each process, do your thing and then exit.

If you don't have any blocking operations and everything is non-blocking, you can just use a single server and it handles all the things.

Answer 2

I'm not sure if exhausting ports would be the issue. Other services that do just this such as WebRTC SFUs. With 65,535 ports available that your talking 30,000+ concurrent TCP connections.

However, with that many users first obvious problem would be memory. At 10 mb just to start up PHP, that would be 300+ gb of memory without including a single line of code or actually doing anything. If your working with a seriously trimmed php binary you can get down to 4 or 5 mb, so at 5,000 concurrent users you would have around 25 gb.

But the real problem is that it would result in thousands of processes, which is impossible to work around. This would be entirely wasteful considering ReactPHP's eventloop can handle 10k users within a single process. Not saying a single PHP process can do the work for that many users (except maybe the most basic chat) but ReactPHP can handle the IO. Throwing them all into their own process though would a nightmare.

The basic idea has been tried in other languages by giving each user their own thread, but even in C/C++ this is quickly proven to be a bad design.