Introduction
SilkPerformer makes use of HTML parsing (sometimes called "parsing mode"). SilkPerformer perfected parsing mode with its unique caching technology, thus allowing caching of HTML documents and images while handling conditional requests and document expiration. Furthermore, SilkPerformer easily handles images loaded by JavaScript.
Caching with SilkPerformer
This introduction describes what has become so important in the field of load testing: to be accurate in every detail, to provide an easy to understand interface for developing load test scripts, but still be powerful and accurate to the highest extent possible. In this article, we will have a closer look at SilkPerformer"s caching strategy. Specifically, we will look at what caching is and why it must be handled accurately, in the same manner as it is done with a common Web browser. We"ll have a look at what SilkPerformer is doing behind the scenes throughout the caching process. A discussion of caching strategies based on HTTP will explain different methods that are currently used by Web clients. Based on an understanding of caching, we"ll eventually be able to have SilkPerformer run thousands of virtual users, each following a distinct cache strategy - thus, simulating what occurs in the real world.
Caching is basically meant to reduce network traffic; to reuse recently downloaded documents and render them again in your Web client. A Web surfer who enables document caching will therefore experience more timely responses in online sessions, as the time for updating the Web browser"s content can be reduced to a minimum. Logically, most browsers will be operated with one of the options as illustrated below in figure 1.
What we need to be concerned with when choosing one of these caching strategies, is the resulting HTTP traffic - which may vary dramatically depending on the cache strategy used. We are also interested in the type of documents that can be cached. Let"s now take a look at each caching option.
Once Per Session
"Once per session" works as follows: each time you start your browser, it will first look into its cache before sending a request. This request will either be: a conditional request, if the document resides in the cache and is requested
the first time in the session; a normal request, if the document cannot be looked up in the cache; or, a cache hit, if the document has already been requested in the session. But first, before we talk about documents, we should know what a cache engine considers to be a document.
Of course, images are the best example of documents that can be cached. Also, static HTML documents which may have the file extension .htm or .html. How about the HTML generated by Active Server Pages or Servlets? It doesn"t make sense to cache the response data of Active Server Pages or JSP Pages, since it is dynamically generated content. To find out whether a document may be cached or not, the Web client has to examine the HTTP response header of each response.
Let"s do a cache example using SilkPerformer applying the "Once per session" cache strategy:
You can either use the dialog (as above, in figure 2) to set your caching strategy, or you can determine the strategy in the script itself. Note: Settings made in the script override the dialog settings.
We"ll have to execute each transaction at least twice to see how caching works. We used an additional function, WebSetUserBehavior, where we specified the script was to run a returning user, for example, an online shopper that returns to their favorite shopping application.
Let"s analyze the traffic produced by transaction TWeb from our example above:
Understanding the traffic produced by the first cycle of TWeb is straightforward. First, the ASP on the server will be invoked. This returns data that will be examined and, subsequently, an embedded image will be downloaded. Any further attempted requests to this image in the same cycle will result in a cache hit.
The second cycle starts again with a request to an ASP. The request for the embedded document this time is special. It"s a conditional request:
The response (as in figure 3) is HTTP code 304, which means that the document on the server has not changed. Therefore, the picture can be fetched from the cache, saving the time of downloading it once again. Any further references to the same image in the same cycle will result in a cache lookup without involving the server (once per session).
Remember, all we have done so far is to use a browser"s cache strategy to check for newer documents. Utilizing "Once per session", we ran one session, closed our browser, and returned again as a revisiting user.
Every Time
This strategy is slightly different from the "Once per session" caching in that it checks for newer documents each time you reload a page. You would typically write an "Every time" caching strategy in the TInit transaction, as in the following:
You could also use the dialog setting (figure 2). In this Tinit example, we specify the user behavior WEB_USERBEHAVIOR_FIRST_TIME. This means that each execution cycle of a transaction will be interpreted as a new user that has never visited the Web site - which is what document cache and cookies are checking for. To achieve this, each virtual user will reset their connections, clean up their cookie database (persistent or non-persistent) and eventually clear the document cache each time a transaction has completed. When setting first time user behavior, be sure that you do not have a persistent cookie set in the TInit transaction. This cookie will not be accessible to all other transactions. It will be invalidated as soon as the transaction is done.
Let"s again execute our TMain transaction twice and the SilkPerformer"s DataExplorer (figure 4) will demonstrate exactly what we have learned so far.
If we look at the first transaction cycle, we see that the runtime has sent conditional requests for documents (figure 4) that have already been downloaded in the same transaction in another page. The second cycle of TWeb illustrates that standard requests are sent to the server for the first occurrence of our embedded documents. This is because we are simulating first time users that have to reset their document cache, their cookie database, and their connections once they are done with a transaction.
Check Never
Disabled user behavior simply means that document cache and the cookie database will be the same throughout all cycles of a transaction. The cookie database will not be reset and the document cache will not be cleared. The option "Check never" simply means that if a document resides in the document cache, it won"t be reloaded under any circumstances (unless its validity has expired). Let"s go through one theoretical example:
You have a Web application that publishes the latest stock prices using graphs. This is usually achieved using images. Well, all of these graphs will be updated every two minutes on the server. The Web client downloads a graph only once using the "Check never" settings. It would be a fatal error if the client relied on the rest of the session with this image that will eventually contain old data. Luckily, the validity of documents can expire, meaning the client has to send requests for the graphs instead of retrieving them from the document cache. Well, not surprisingly, SilkPerformer can handle these rather complex situations!
Combinations
1) The user never clears document cache and never resets the cookie database throughout all transactions. No conditional requests for already cached documents.
2) The user never clears document cache and never resets the cookie database throughout all transactions. During one execution cycle of a transaction request, only one conditional request will be sent if the document can be found in cache.
3) Similar to 1, but conditional requests will be sent to the server if the document can be found in the cache.
4) Documents will be retrieved from the cache unless they are expired. Each time a virtual user is done with a transaction, SilkPerformer clears the cookie database and document cache. Persistent cookies cannot be maintained over the execution of transactions.
5) Select this combination for Web applications that have to deal with a large or increasing number of new customers; e.g. search engines, or online shopping malls approaching a high-volume retail season.
6) As 5.
7) When the transaction is done, the virtual user simply clears the non-persistent cookies and closes all connections. You can compare the returning user to someone who simply closes the browser when he/she is done with the transaction and returns some random time later.
8) and 9) The only difference to 7 is the frequency of conditional requests.
As you can see with SilkPerformer, you can design your load tests to simulate many different caching strategies. For example, a search engine may experience many new users after running a successful advertisement. Well-known service providers or online stores will have to face a great number of returning users.
Note: This article does not claim to cover the entire caching technology as it is used by Web clients and expertly managed by SilkPerformer. The purpose of this document is to serve as an introduction to help understand the need to accurately emulate document caching in your Web load/performance testing processes.
Old KB# 18217