The Silk Performer replay engine provides emulation of Web browser document cache. A real Web browser stores cached Web documents in files in a central document cache. To save memory and optimize performance, Silk Performer stores just references to the documents in the physical memory, without writing them to the hard drive. Each virtual user has its own independent document cache and does not store any files to the disk.
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 in his/her client will therefore experience more timely responses in his/her 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 following caching options:
Once per session
Every time
Never
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.
Images are the best example of documents that can be cached. Also, static HTML documents which may have the file extension .htm or .html. In regards to 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.
When to use the document cache emulation:
The document cache is recommended when replaying traffic with the page-level web function (the functions with the WebPage prefix). The page-level web functions parse HTML and use the document cache emulation to filter out duplicate requests of a single document, just like a real Web browser does.
The document cache emulation can also be used with the low-level replay web functions. However, it is not recommended to do so since the SilkRecorder does not include documents cached by the browser in the script. Besides, document cache emulation can decrease the performance of the low-level replay.
Document cache emulation functions
Combinations
User behavior/Cache strategy | Never | Once per session | Every time |
---|---|---|---|
Disable | 1 | 2 | 3 |
First time user | 4 | 5 | 6 |
Revisiting user | 7 | 8 | 9 |
The user never clears document cache and never resets the cookie database throughout all transactions. No conditional requests for already cached documents.
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.
Similar to 1., but conditional requests will be sent to the server if the document can be found in the cache.
Documents will be retrieved from the cache unless they are expired. Each time a virtual user is done with a transaction, Silk Performer clears the cookie database and document cache. Persistent cookies cannot be maintained over the execution of transactions.
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.
As 5.
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.
and 9. The only difference to 7. is the frequency of conditional requests.
As you can see with Silk Performer, you can design your 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.