December 9, 2013
Rumpus allows you to specify the "Maximum Number Of Simultaneous Connections" for both HTTP and FTP services. For example, by default, Rumpus allows up to 8 FTP connections to be handled at any one time. A 9th connection attempt will stall until one of the active 8 sessions is completed. This causes a problem, of course, because the 9th user will not be able to access the server, so it seems to make sense to set the "max. simultaneous users" to some very high value so that no one is ever denied access.
But look at another example, this time where the server doesn't limit connections at all. You have a finite amount of Internet bandwidth, which is divided by each active file transfer. If your Internet connection speed is 5 Mbps, your actual throughput will be around 600 KBps. If you had 30 people, all trying to download large files at the same time, each user would see roughly 20 KBps in throughput. At that speed, transfers would be so slow that users would start canceling downloads or the overworked Internet connection may start to create errors.
So your number of simultaneous users will be based on your available bandwith, because it is better to deny some users (and have them try again later) than to accept an unlimited number of sessions which will have less than adequate service. Bandwidth isn't the only factor, though... Other things to consider are the size of typical files transferred to and from your server, the speed of typical client connections, what other applications (besides Rumpus transfers) are competing for Internet bandwidth on your network, your outside user's expectations of transfer speeds, etc.
The general rule is to take your total Internet bandwidth and divide it by the lowest possible transfer rate your clients are willing to accept. For example, if your Internet connection speed is 10 Mbps (about 1,200 KBps) and you expect clients to always be able to transfer files at a minimum of 50 KBps, you can never have more than 24 users actively transferring files at any one time. You would then split the 24 maximum connections between FTP and HTTP service.
FTP is pretty simple, in theory. Each user logs in to establish a session, and each session counts toward the maximum number of simultaneous connections allowed. But in practice, some FTP clients will establish several connections at once so that the client can transfer multiple files simultaneously. In most cases, I suggest that you ask your FTP users to disable this feature in their FTP client software. In most network situations, downloading 4 files at one time or downloading those same files one at a time will take roughly the same amount of time, so there is little to be gained. On some networks, individual connections are speed-restricted, so transferring 4 files simultaneously will result in a performance improvement, but in this case, the speed restriction was put in place for a reason (usually to improve overall quality of service), so circumventing the restriction is working against overall network performance, anyway.
An FTP client that establishes multiple simultaneous sessions will quickly consume your available connections, and it is impossible to set the maximum number of simultaneous connections high enough to ensure normal access for all users. If you have a mis-behaving FTP client that is using all of your available connections, locking other users out, and you increase the maximum number of simultaneous connections to compensate, there is still nothing preventing that mis-behaving client from consuming even more sessions.
My recommendation is to set the maximum number of FTP sessions (on the Basics tab of the FTP Settings window) to some reasonable number of sessions you wish to support when the server is at it's busiest, and ask your FTP users to set their FTP client software to transfer only 1 file at a time (or at least only a few files at a time).Web (HTTP) connections are different from FTP in a couple of important ways. First, when a user is logged in but is not actively transfer a file or performing some other action, they are not connected to the server at all. For example, you might have 30 users actively signed into the server via Web browser, but not have any actual connections active. (Rumpus will, however, display each of those sessions, even though there is no active connection back to the clients.)
On the other hand, virtually all browsers will open multiple connections to download multiple files at one time. This most commonly occurs when accessing a directory listing. A thumbnail view directory listing, for example, may include dozens of small file transfers (the thumbnail images being displayed in the listing) and the browser will most likely open 4 or more connections to get those files. This is temporary, though, and as soon as those small file downloads complete, the browser will dispose of all of those connections, freeing them for use by other sessions. When transferring big files over a relatively long period of time, however, each transfer will consume 1 active connection.
For the HTTP maximum number of simultaneous connections (set on the Advanced tab of the Web Settings window), I recommend a value that is about equal to the number of sessions you plan to allow when the server is at it's busiest. You may want to add a few extra allowed connections, to account for exceptionally high levels of short duration activity. The Rumpus default is 20 simultaneous connections, which is generally adequate for moderately busy servers, but that value can be increased if you have a fast Internet connection. But again, setting the value arbitrarily high will lead to transfer failures, so be sure to base the maximum number of connections on your available bandwidth.