radiumtesting.blogspot.com
|
Contents
Browser Cache Emulation in OpenSTA
In Load Runner there is option available to emulate the browser cache, there is no such facility in OpenSTA directly, but through the scripting you can emulate this cache.
First we will go through the background of HTTP cache.
HTTP caching is of the best ways to reduce roundtrips and bytes transferred. Caching provides a mechanism for a client or proxy to store HTTP responses for later use, so that requests need not cross the network.
Other than performance, another benefit of maximizing use of HTTP caching comes from the fact that bandwidth isn't free
Cache-Related Request Headers
To enhance performance, Microsoft Internet Explorer and other Web clients maintain a local cache of resources downloaded from remote Web servers.
When a resource is needed by the client, there are three possible actions:
- Send a plain HTTP request to the remote Web server asking for a resource
- Send a conditional HTTP request to the origin server asking for the resource only if it differs from the locally cached version
- Use a locally cached version of the resource, if a cached copy is available
When sending a request, the client may use one of the following headers:
Table 1. Client Cache Headers
- Pragma: no-cache
- The client is unwilling to accept any cached responses from caches along the route and the origin server must be contacted for a fresh copy of the resource.
- If-Modified-Since: datetime
- The server should return the requested resource only if the resource has been modified since the date-time provided by the client.
- If-None-Match: etagvalue
- The server should return the requested resource if the ETAG of the resource is different than the value provided by the client. An ETAG is a unique identifier representing a particular version of a
A client indicates that it has a cached response available for use by sending a "Conditional request" containing the headers If-Modified-Since or If-None-Match. If the server replies to a conditional request with HTTP/304 Not Modified, the client is directed to reuse its cached response. Otherwise, the server should return a new response and the client should discard its outdated cache item.
Observe two consecutive requests for an image file in the following code sessions. In the first session, no locally cached version of the file is present, so the server returns the file along with an ETAG value and the date-time of the last modification of the file. In the subsequent session, a locally cached version of the file is now available, so a conditional request is made, passing up the ETAG of the cached response as well as the Last-Modified time of the original request. Since the image has not changed since the cached version (either because the ETAG matches or the If-Modified-Since value matches the Last-Modified value) the server returns a 304 to the client to direct it to use the cached response.
Session #1
GET /images/banner.jpg HTTP/1.1Host: www.bayden.com HTTP/1.1 200 OKDate: Tue, 08 Mar 2006 00:32:46 GMTContent-Length: 6171Content-Type: image/jpegETag: "40c7f76e8d30c31:2fe20"Last-Modified: Thu, 12 Jun 2003 02:50:50 GMTSession #2
GET /images/banner.jpg HTTP/1.1If-Modified-Since: Thu, 12 Jun 2003 02:50:50 GMTIf-None-Match: "40c7f76e8d30c31:2fe20"Host: www.bayden.com HTTP/1.1 304 Not ModifiedBecause an HTTP/304 response contains only headers and no body, it crosses the network much more quickly than if the full resource had been re-downloaded. However, even an HTTP/304 requires a full roundtrip to the remote Web server; by carefully setting response headers, a Web application developer can eliminate the need to issue even conditional requests.
OpenSTA SCL Scripting
This is just background of HTTP Cache, we can conclude that HTTP cache will return the 304 HTTP code if it is from cache,
As shown below in yellow mark is responsible for the HTTP cache ,
To correlate the value just follow the very first same request in OpenSTA script . then into server header pan from right side and just correlate that value
GET URI "HTTP/1.0" ON 2 & HEADER DEFAULT_HEADERS &
,WITH {"Accept: */*", &
"Referer: http://localhost/MercuryWebTours/home.html", &
"Accept-Language: en-us", &
"Cookie: "+cookie_2_1, &
"If-Modified-Since: Sun, 10 Jan 1999 23:07:04 GMT; length=22548", &
"Connection: Keep-Alive"}
HTTP throughput in OpenSTA Results Graphs
OpenSTA Results Graphs
Below is a list of the graphs available in OpenSTA, an expanded description of the meaning, and any hints on its intended use.
HTTP Monitored Bytes/Sec v Elapsed Time - Amount of HTTP throughput (just on the VUs selected to be monitored) throughout the run of the test.
Amount of HTTP throughput
HTTP Response Time v Number Of Responses - The time to get a response from a HTTP request while a number of responses was being received throughout the test run.
HTTP Response Time v Number Of Responses
HTTP Errors / HTTP Requests - Number of HTTP requests returning with error codes while a given number of HTTP requests was being made throughout the test run.
HTTP Errors / Elapsed Time - Number of HTTP requests returning with error codes throughout the test run.
HTTP Responses / Elapsed Time - Number of replies to HTTP request received (per second) taken throughout the test run.
HTTP Response Time / Elapsed Time - The time to get a response from a HTTP request throughout the test run.
HTTP Active Users / Elapsed Time - The number of active VUs taken throughout the test run. This graph shows how well any ramp up and down works and can provide data points of the time given numbers of users were active. The Timer Value graphs usually make most sense when only one Timer, or type of Timer, is selected.
Timer Values / Active Users - Averages of the Timer values taken for each period where a given number of users were active. This graph works best if the number of VU's if ramped up and down slowly. It is next to useless if you only have 1 VU or start all your VU's simultaneously.
Timer Values / Elapsed Time - Averages of the Timer values taken throughout the test run. This graphs works best if you are introducing certain types of performance effecting activity during different periods of the test run. The various results listed as throughout the test run are probably the either a actual number of occurences (eg. HTTP Responses) or an average of the values returned (eg. HTTP Response Time) in 1 second time intervals throughout the test, although this needs to be confirmed.
