One of the most
common questions we get goes something like this: “I have a forum with 3,000 users and the VPS license says it has a limit of 500 concurrent connections. That's not enough for me, right?” Actually, 50 concurrent connections is probably enough for you. This misconception stems from a misunderstanding as to what a concurrent connection is. In this post, I will try to address this misunderstanding.
What Is a Connection?
First of all, what are we talking about when we say, “a connection”? We mean you server communicating with a client (a browser, probably), sending HTTP requests and responses back and forth. Ideally, a client should open a connection with your server, exchange the necessary requests and responses, and then close the connection. Thus, a user reading your web page is not a connection. When that user requested your web page and your server sent it to them, that was a connection. Now that it's been loaded and the user is reading it, the connection should be closed. Once we're clear about this, the idea of concurrent connections is pretty simple.
And a Concurrent Connection?
A concurrent connection is a connection happening at the same time as another connection. And when I say, “at the same time,” I mean the exact same time. If one connection stays active for 443 milliseconds (asking for the page contents, then receiving them) and, 8 milliseconds later, another user clicks on a link, those connections are not concurrent. (Don't ask me how far down this time-splicing goes. I don't know.) This is why I say that a forum with 3,000 users is not likely to get more than 50 concurrent connections. Let's do some oversimplified math:
Let's say that the forum with 3,000 users has 300 users on the forum at any one time. We track these users for an hour and and find out they they each make 30 clicks an hour. That's 9,000 total clicks on the forum in an hour. If each request/response combo takes 2 seconds (which might be a little slower than standard for a forum), that's 18,000 seconds of active connections in 3,600 seconds of time. I don't know the actual probability, but even 50 connections is going to handle any spikes in that usage. And if you switch to LiteSpeed and your page load time drops to 700 milliseconds, you'll get even fewer concurrent connections. The 500 concurrent connections the VPS license offers is overkill. (It's the RAM limit that you need to pay attention to.)
Keep-Alives and Other Monkey Wrenches
Now, this is an oversimplification and there are some wrenches that can mix things up. If you're serving larger or more cumbersome content than just forum pages, those responses will take longer and increase the chance of concurrent connections. If you're streaming content, well those are some very long connections, but, at that point, your problem is going to be with RAM, not concurrent connections.
One simple thing that you can control is keep-alive connections. Keep-alive (or persistent) connections artificially keep a connection alive after the request and response communication is done. Keep-alive connections were created to lessen the significant overhead of creating a new connection. Most sites are not loaded with a single request and response, but rather piecemeal through a number of requests and responses. Keep-alive connections allow a client and server to use an already open connection to handle more than one request and response, and thus dispense with the time it would take to create new connections for every piece of the site. (I really like this explanation of the benefits on the IEInternals blog.) If you have a fast loading site, though, keep-alive connections can become a hinderance. The default length of keep-alive connections in LiteSpeed Web Server is five seconds (WebAdmin Console > Configuration > Server > Tuning > Keep-Alive Timeout). If your pages take five seconds to load, that's the perfect setting. Clients will get all the responses they need without having to open too many connections. But if your pages take two seconds or less to load, you might be keeping connections open unnecessarily.