When selling applications to new prospects, or enhancements to existing sites, I encourage sales people and technicians to speak about user and license counts in more general terms, emphasizing site-specific ratios rather than actually quoting numbers. If the numbers change after installation you’ll have a credibility issue. Once a client/prospect understands the factors involved they may start asking what your application-specific ratio guidelines are for specific modules. As in “how many licenses might an optimized site need to run 50 users on module X and 100 users on module Y?” Now this is a great question that can only be answered by someone who has seen the application performing in the field. Software developers would do well to embed logging into their application so that they can derive such metrics to answer these tough but valid questions.

So that ever-present "how many and how much" question can’t really be answered up front. (Sorry Sales guys.) During the sales cycle you may have no idea what kind of hardware will be used and there might already be issues on the server(s) which will affect the actual performance. (This is actually an opportunity for a performance review.) You don’t want to quote numbers without knowing the deployment topology, and then find after deployment that inferior hardware is being used with a saturated network and a DBMS that hasn’t been properly administered in years. Sites must start with some number of licenses and then work up to their comfort zone where there is little or no waiting for licenses.

Some sites might not have a problem with occasional periods of high traffic and “passable” performance. Others might insist on best-possible performance at peak times, and acknowledge that they’ll have a lot of unused licenses during off-time. These sites may be very inclined to add new enhancements to take advantage of the unused resources, or to pay for QoS enhancements. The best way to approach this is to understand your own application, gather metrics from existing sites, and use this experience to provide best-guess but realistic estimates which serve as a starting point for discussion and deployment.

 Notes (1) Factors affecting web application performance include the following:

• Network speed: The further away the user is the more hops they have to make through networks and the longer it will take to get data from the client to the server. The Ping command from any PC to a web server will tell you how much time is lost in transit. The Tracert command tells you how many connections every transaction goes through.
• Network hardware: The more traffic a network card handles the slower the throughput. It may be helpful for a web server to have one NIC for the WAN and one for the LAN. Filtering firewalls and port-forwarding routers, while required, contribute to traffic delays and should be optimized. Sometimes the cat5 cabling used can make the difference between 10GB and 100GB performance. Wireless users are subject to lots of extra delays.
• Server speed: Faster is better with servers. Having large amounts of memory is very helpful. The DBMS server hardware should be as fast as possible.
• Other applications running on the servers: Performance is seriously affected when the web server is also running the mail server, DNS, PDC, FTP, and other services. While I don’t subscribe to the “one application per server” theory, I do think applications should be properly distributed so as to avoid having one system affect another. DBMS activity like large reports and period-end closings will also affect throughput.
• DBMS speed: All common files should be indexed and properly sized. Logs should be purged periodically – this is a frequent source of latency outside of the application itself.
• Application processing speed: Avoid unnecessary file-open operations. Always code for quick transactions. Never assume the user will be present for more than a few milliseconds. Try to avoid ReadU and other locks as much as possible to keep users from having to wait to access resources – common bottlenecks include sequential item counters, master control records, and locks oriented toward maintaining referential integrity (keeping headers and details in sync, making sure that on-hand and available balances are always accurate, etc ).

 Notes (2) How does using less DBMS licenses help the DBMS companies?

Questions often come up about cheating the DBMS companies out of licensing fees. An application vendor with a GUI has a much higher chance of being able to sell software than someone with only a Character User Interface (CUI). If this vendor sells (as a low example) 1 site with 10 licenses in a year then the DBMS company gets revenue for 10 licenses. With a GUI and the economy of license pooling the vendor might be able to sell to 10 sites. The DBMS vendor now has 100 paid licenses rather than 10. It shouldn’t matter if 1000 people are using the software (10sites x 10licenses x 10:1 ratio) – the people who bought this software would not have purchased 1:1 CUI software anyway. Further, larger companies with thousands of users are much more inclined to buy GUI software with high N:1 ratios. These days a vendor has almost zero chance of selling a CUI app to sites like this, but has a very good chance of selling hundreds of licenses for a feature-rich, attractive GUI application. DBMS companies welcome such opportunities for the revenue and for the marketing benefits. So in all of this discussion about increasing users and decreasing licenses, just remember that better and more economical software sells to more sites than inefficient software with high per-user costs. The DBMS companies are still trying to survive with the decades-old per-seat model. We’re keeping them in business by using third-party tools to build infrastructure around them and make their software more marketable without them having to change the model.