How many licenses do I need?

This is an in-depth explanation of how web clients consume licenses with a back-end MV DBMS. It might be too basic for some people but it should help to bring everyone up to a common level for discussions on this important topic.

[Edit July 06, 2006: Because this article is referred to so often, it has been added to the DesignBais and mv.NET categories so that people can find it easily.]

Compared to a 1-to-1 ratio for users to DBMS licenses required for telnet connections, the web allows us to get an N:1 ratio. More users per license means we need less DBMS licenses to support any given number of users. Less licenses means less expense. That’s very attractive to most people and one of the reasons for the explosive popularity of thin-client web apps over thick-clients. So a higher N:1 ratio is always the goal as sites want to increase users or decrease license purchases.

We get the N:1 ratio because users on the web are non-persistent. The server accepts a connection from a user, processes it, then lets the connection go. A single connection does not remain open for use by any single user. A unique token is present in all communications from a given client. This tells the server who the client is. Third-party software on the web server (also called the middle-tier) manages a "pool" of connections to the back-end database. When a connection comes in, this program finds an available DBMS line in the pool (a port already logged into a given account) and sends the transaction to the back-end. The transaction includes "session" variables which tells the DBMS what program is being used, what event fired the transaction, what files need to be open, and of course the data that is to be processed. Application code is executed to satisfy the request, results are released back to the middle tier, the connection is flagged to the pool as available, and the response is returned to the user.

It sounds like a lot but all of this can be handled in milliseconds. Various factors determine how long a transaction takes to process. See Notes (1) at the bottom of page 3. The number of licenses required by any given site is highly dependent on how fast transactions can be processed.

As an extreme example, let’s say it takes 10 seconds for the DBMS to process a single mouse-click transaction and there is only one DBMS port allocated for all users. During that time, the web server can receive requests from other users, but the connection into the DBMS is unavailable. What do the other users do? They have to wait, and waiting for a system to process data makes that system look slow. If you have 3 users waiting, the second user will get processed after 10 seconds. A third user will get processed after that (having waited 20 seconds now), and 10 seconds later, after waiting a total of 30 seconds, the third user will get a response.

To speed things up, you can add another DBMS license. So users 1 and 2 get in immediately, and user 3 only waits 10 seconds to connect and 20 seconds for a response. If there are 3 DBMS licenses, all three users get a 10 second response.

Does this system “need” one license or three? It depends on how important response time is to them. Most people would agree that 30 second response times are completely unacceptable, so they “need” 3 licenses. Some few sites might not care, so they only “need” 1.

Another factor is in play here. Most networks or browser clients are set to timeout after waiting more than some number of seconds for a response. This value is typically 30 seconds but can be as high as 360 seconds. At some point however, it’s likely that rather than waiting patiently for 30 seconds, either the client browser will timeout or the end-user will get impatient and start clicking buttons, which only creates problems. So now we see that a site with a 30 second turnaround time really does “need” at least 2 licenses. So far we see the user:license ratio is 3:2 or perhaps even 1:1.

What about that 10 second turnaround? For most of us that’s equally unacceptable. By optimizing the hardware and software (see below) we may be able to get that transaction time down to sub-second responses. (At least on the back-end – there’s not a lot you can do about latency from the web server to remote clients over the internet.). So if it only takes 250ms (1/4 of one second) to process a transaction, you can get 4 user transactions processed in one second. So this example site is now at a 4:1 ratio. As you add more licenses you find that 4:1 does not equal 8:2, 16:4, 20:5, etc. Because users can only click so fast and take time to read and type data, you’ll find that they click once, use up their 250ms, and you don’t hear from them for several seconds later. During that time many other users can be processed. This effectively raises real ratios from 4:1 to more like 10:1, 20:1, or even 100:1 or better.