When designing a client/server architecture, is there any advantage to multiplexing multiple connections from the same process to the remote server (i.e. sharing one connection) vs opening one connection per thread/session in the client (as is typically done when connecting to memcached or database servers.)
I know there’s a bit of overhead associated with each connection (e.g. if a server has 50,000 open connections that uses up a lot of RAM) this was one major reason why facebook made a UDP patch for memcached. But I don’t expect to have anywhere near that number. Maybe 10,000 at the most. There’s also savings in establishing a tcp/ip connection and doing authorization, but for now I’d rather leave authorization to firewall software as memcached does.
Are there any reasons to implement multiplexing connections in a tcp/ip client/server application with less than 10K connections?
Edit – Details:
This is for a database server/client I’m working on. I think that Informix and Oracle do actually allow for session multiplexing over one tcp/ip connection. In the Informix documentation they say you may get a performance improvement for nonthreaded clients (no mention of multi-threaded clients, perhaps it’s not a thread-safe implementation.)
Yes, though it depends on the implementation of the simplex. You probably know about the firewall hassle with e.g. FTP, SIP et al, especially when encryption is used partway. This is what influences the decision whether to use multiple, or just one connection.