But let’s get more realistic. Not all transactions can be processed in 250ms. On a fast system some are 100ms (1/10 second) and others might in fact take a couple seconds as the application reads data from disk, computes totals, writes logs, etc. So while optimum throughput could be in the 100ms or 250ms range (and quite often are in that range or much better down to 50ms on fast hardware), real world transactions skew the averages so that one transaction will take 100ms, another 800ms, another 1500ms, etc. This real world usage makes it impossible to figure out how many licenses a site will really need until the application is actually deployed and in-use for some period of time.
A good rule of thumb is to assume about a 10:1 ratio and sell based on that. If users need to wait for DBMS licenses then more licenses need to be added. Factors that affect this 10:1 baseline include:
What about prioritization? What if you don’t care if some users wait but others must always have rapid response? In this case the N:1 ratio is unimportant because each license is not equally available to all N users. Licenses can be allocated into specific pools for specific functions, and critical functions will not be delayed because they are sharing resources with other functions. Servers now also have Quality Of Service (QoS) features which allow network traffic to be prioritized based on where it’s coming from, where it’s going to, and the kind of transactions being processed. Clicks on the public website, for example, may be set to have less priority than inbound inquiries from active trading partners.
Earlier I mentioned third-party software that manages pools of connections to create this whole N:1 scenario. Free connectivity libraries written by DBMS vendors do not provide any form of pooling. Examples include UniObjects, the D3 Class Library, jBASE OBjEX and jRCS, and QMClient. If you want to save money by pooling you need to purchase software that is designed to save you money – you do the authors a favor by spending a little money with them and they do you a favor by helping you to save a lot of money on DBMS licenses. Products that including pooling include DesignBais, FlashCONNECT, Visage, mv.NET, PDP.NET, RedBack, and WebWizard. These products differentiate themselves by offering more in terms of application development tools and extended libraries for special functions. Some cost more than others but you really need to compare the features offered with your specific development and deployment needs. The “free” tools offer nothing more than connectivity. If you want pooling with these tools you need to write it yourself. Without pooling you’re looking at a 1:1 ratio of users to licenses, and for web-based applications that is usually unacceptable.
If you haven’t written your web-enabled application yet, or haven’t written the new UI for an existing app, then you have no idea what the user:license ratio is going to be. There will be per-program ratios which are completely dependent on each program, and once a program is deployed, if the N:1 ratio is unacceptable you might want to target that program for optimization. In the end, your going to find N:1 ratios are calculated as averages, not absolutes. You might get 100:1 for sites that do mostly inquiries and 1:1 if they are intense data entry shops. Sites with more data or improperly sized files will find their ratios dropping – this is perceived as the application getting “slower”, meaning response times are getting longer. The answer to this problem isn’t to just add more licenses, but to target site-specific factors.
If you’re wondering about how all of this N:1 DBMS usage affect the DBMS vendors themselves, see my Notes (2) at the bottom of page 3.