For web applications that are expected to have significant load, best practices is to create load simulators. Load simulators are good for pro-active tuning of applications and verifying scalability. Additional benefit of load simulators includes the creation of sizing tables and estimates for the Total Cost of Ownership (TOC). There is nothing like acquiring an enterprise license for $10K and discovering that it takes $200K of hardware to handle the load when you could have purchased a different product for $30K that only needed $30K of hardware.
A single load simulator is usually insufficient. Below is an image of a contemporary web application:
Since systems are layered with lower levels bottlenecking higher levels, the following load simulators should be created:
- Direct to Stored Procedures. This is usually the absolute speed limit for the system
- If a higher level bottlenecks, scalability can be increased by parallelism (i.e. N computers holding one layer).
- Direct to WCF Interface. If this does not scale as well as the database, then options are:
- Refactoring – See MSDN' Magazine’s “Discover Mighty Instance Management Techniques for Developing WCF Apps” as a starting point.
- Create multiple instances on the same box.
- Install on multiple boxes.
- Direct to WCF via JSON etc. – This simulation can be critical to determine is time-outs are likely to happen. A time-out may be a software time out OR a human-ware time-out (user is feed up with the sluggishness). Human-ware timeout are actually nasty because many users will start clicking refresh repeatedly (resulting in a request spike).
- Direct to IIS Server Controller – this will often detect memory use issues or session management issues (for example, using an in-memory session manager and having so many users that you run out of memory!)
- Direct to Aspx Page – this is often the nastiest to create because you may have to do a logon and maintain session state and post backs.
The bottom line is the ability to specify:
- Number of IIS Servers for a specific load
- Capacity of a specific SQL Server Session Manager configuration to handle a specific load (this allows non-sticky load balancing across a group of servers)
- Capacity of an in-memory Session Manager to handle a specific load (which would require sticky web sessions/load balancing)
- Number of WCF Servers for a specific load
- Capacity for a specific SQL Server (# of cores & RAM) to handle a specific load
By “handle a specific load”, we mean generally:
- Zero Percentage of Timeouts and deadlocks.
- For SQL Server, we may add a criteria of no more than N items blocked at any moment
- Response time is acceptable for the layer.
- For SQL Server, < 0.5 seconds for any query is suggested
- For WCF, < 2 seconds for any query
- For Aspx page, < 6 seconds for any post or get.