3 ms·
Copying my comment from my comment page. Well like I mentioned I believe that is an implementation detail. For example, if you have the subprocess you have two
by audidude 17y ago
Copying my comment from my comment page.
Well like I mentioned I believe that is an implementation detail. For example, if you have the subprocess you have two fundamental designs. The first being where the master process still manages the client socket (so data is transfered from the worker back to the master). The second being where you pass the client socket (over a UNIX message with send_msg) and allow the worker to flush the buffers and close the socket. The problem with the first is that you increase the amount of wake-ups your event loop needs to do by 2x (since it needs to handle data in and out for the worker) which could increase your handling latency. This is a no-go in some applications. The problem with the second model is you lose the ability to have connections live longer their request (otherwise they are restricted to that workers affinity which will not be evenly balanced).
ODBC is an option (or SQL Relay) but it adds an increased latency without providing the ability to yield on the resource being ready. For example, even with the models I described above to reduce over subscription of resources, your container may not be correct in its assumption that the connection has little contention. So you effectively add latency and reduce correctness in your ability to run efficiently.
- blasdel 17y agoBut why do the otherwise-independent app server processes need to be sharing 'the' socket at all? If you're already going to be running the same app on more than one machine, there's no reasons left to stick to port 80. It seems like you're stuck on the idioms of Apache and 'real web-servers' (as you put it).
- audidude 17y agoIf you don't share the client sockets at a level that can distribute work to all of the processes you will get an unbalanced number of connection:keep-alives amongst the workers.
- blasdel 17y agoBut we have this nice little abstraction called HTTP! The app servers don't have to know anything about load balancing. You're persistently parochial in how you're approaching these things.
- thwarted 17y agoThe second being where you pass the client socket (over a UNIX message with send_msg) and allow the worker to flush the buffers and close the socket. ... The problem with the second model is you lose the ability to have connections live longer their request (otherwise they are restricted to that workers affinity which will not be evenly balanced). Remove this problem by having the worker process pass the file descriptor back to the master process as an open (doesn't need to be accept()'ed) socket to be reprocessed or closed as necessary.