Open Topic Series: State Management & Scalability
This topic is designed to provoke curiosity.
Beginning with the introduction of the .asp model for web applications, Microsoft shifted the management of state information to the client from being stored on the server, thus allowing the client to be decoupled for extended periods without the server having to maintain state information, We have all observed the result, the information flowing back and forth related to state management for asp and asp.net applications. This also represents an opportunity for tuning.
By default all items go into state. Developers being who they are unless someone asks them to change an element or a requirement is ties to state management then the default is not addressed. This leads to very large state management variables which have to be passed back and forth across a finite resource, the network interface. This impacts older browser usage where such large state management variables are allowed and it impacts the storage and validation of state information passed back to the server from the client, consuming finite resources of CPU and RAM for out of application use. It also leads to crazy things such as these items directly observed from applications under test: view states in the 16-20MB range when a web page had a large Microsoft access database embedded within the page, the total size of the state management variables exceeding 100MB for a multi-frame multi-step application, and the scalability of the application being limited by its most restricted resource, the network, because of large state management variables. Microsoft is not alone as there are some items in the wild with quite large jsessionstate variables as well.
Consider a static analysis of your script just after recording, how large and numerous are the state management variables? What is the likely outcome of a user using this application over a restricted or already congested link versus someone using it at the central office? What if someone still has an AOL browser on their desk and wants to use this, or even from a Smartphone (which would face restrictions on both network and browser variables)? How can such static analysis of the application and its behavior provide you with information to feed back to development about their application which is useful for tuning the use of restricted|finite resources?
Replace ineffective offshore contracts, LoadRunnerByTheHour
. Starting @ $19.95/hr USD.
Put us to the test, skilled expertise is less expensive than you might imagine.
Twitter: @LoadRunnerBTH @PerfBytes