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:
- High number of events being fired from client UI: If an After Change is event is fired on every single textbox on a form, then more events will be fired per-user, and that increases the requirements imposed on the server. A “thinner” client isn’t as demanding, so more users get access to fewer resources.
- Larger data volumes being passed to/from UI: This includes large grids, having large numbers of dropdown list boxes, and large text areas that are refreshed often, etc. During application UI design, the number of components needs to be considered as well as the amount of data that will be loaded to each component. As an extreme example, you don’t want to load a 10,000 list of customers into a listbox every time the page displays – and you certainly don’t want two such lists on the page, as in to display BillTo and ShipTo customers. It’s more appropriate to create search pages and slowly populate lists with only the data that users need at any one time.
- Large file operations on larger databases: Index large files and try to create small pre-stored lists which can be returned to clients as needed. A database is fully capable of processing large amounts of data, but the disconnected medium of the web tends to drive design toward large numbers of smaller packets of data which can be quickly read, processed, and served back to end-users. This single factor could prompt re-design of some application file structures – or at least the addition of new cross-reference files just for this medium.
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.