The disclosure will provide details in the following description of preferred embodiments with reference to the following figures wherein:
In accordance with illustrative embodiments, a Remote Latency-based Management (RLM) system, which includes a novel approach for managing the client perceived response time of a web server, will be described. Remote Latency-based Management (RLM) indicates a focus on managing the remote client perceived response time. RLM is different from existing approaches in several ways. First, the RLM approach manages the response time as perceived by the remote client for an entire page download. Existing approaches manage the server latency associated with processing a single URL request. Second, the present approach takes into account the effect which admissions control rejects has on the remote client response time. Existing approaches which perform load shedding ignore the impact a dropped request has on the response time of the page view, reporting results in terms of only accepted URL requests. In this vein, some notable effects are uncovered that occur in web browsers under conditions of connection failures, and a novel mechanism is introduced. This mechanism, fast SYN and fast SYN/ACK retransmission, can be used in the context of load shedding and lossy connections to combat the previously referred to effects.
Third, the present system tracks the progress of each page download in real-time, as each embedded object is requested, allowing the present system to make fine grained decisions on the processing of each request as it pertains to the overall page view latency. Existing approaches place a URL request into a service class, oblivious of the context in which the object is being downloaded. The approach presented herein is non-invasive and manipulates the latencies experienced at the remote web browser by manipulating the packet traffic in/out of a server complex. As such, this approach requires no changes to existing systems. Experimental results demonstrating the key issues and the effectiveness of the present techniques are provided.
Embodiments of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment including both hardware and software elements. In a preferred embodiment, the present invention is implemented in a combination of hardware and software. The software includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that may include, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code to reduce the number of times code is retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
Referring now to the drawings in which like numerals represent the same or similar elements and initially to
Referring to
In
The measure of response time does include the TCP connection establishment latency, which may be important to capture, especially in the presence of admissions control. Obtaining this measure of response time needs tracking the client-server interaction at the packet level. As such, mechanisms which attempt to measure response time via timestamping server-side user-space events do not measure client perceived response time. For example, measuring response time within Apache™ when a request arrives (i.e. ty−tx) ignores the TCP 3-way shake that occurs to establish the connection, as well as time spent in kernel queues before the request is given to apache.
Such Apache™ level measurements have been shown to be as much as an order of magnitude less than the response time experienced by the remote client. Likewise, measuring the time needed to service a single URL (i.e. tj−ti) is simply not relevant to the remote client who is downloading not just a single URL but an entire page view. As such, it is the client perceived response time associated with an entire page view that is sought to be managed.
RT will be employed hereinafter as shorthand for remote client perceived page view response time. Response time manager 32 (
REMOTE LATENCY-BASED MANAGEMENT: a new model for specifying and achieving RT service level objectives is based on tracking a page view download as the download happens. Service decisions are made at each key juncture based on the current state of the page view download.
Referring to
1. Tconn TCP connection establishment latency, using the TCP 3-way handshake. Begins when the client 20 sends the TCP SYN packet to the server 22.
2. Tserver latency for server complex to compose the response by opening a file, or calling a common gateway interface (CGI) program or servlet. Begins when the server 22 receives an HTTP request from the client 20.
3. Ttransfer time needed to transfer the response from the server to the client. Begins when the server 22 sends the HTTP request header to the client 20.
4. Trender time needed for the browser to process the response, such as parse the HTML or render the image. Begins when the client 20 receives the last byte of the HTTP response.
Each of these four latencies are serialized over each connection and delimited by a specific event. As such, a page view download can be viewed as a set of well defined activities needed to complete the page view.
Referring to
What differentiates the present approach from other QoS approaches is, e.g., that response time manager 32 (
Web Browsers and Connection Establishment Latency: A great deal of work has been done in applying admissions control to prevent web servers from overloading or to shed the load imposed by low priority tasks so that high priority tasks can achieve shorter processing latencies. What has not been studied with regard to admissions control is the effect that admissions control drops have on the behavior of the remote web browser.
Since the remote client is watching a web browser that is displaying a page view including a container page and a set of embedded objects, it is advantageous to know how exactly load shedding affects the latency perceived by the client viewing the web browser. To answer this question, a series of experiments were performed using Microsoft Internet Explorer™ v6.0 and FireFox™ v.1.02 in which various types of connection rejection was performed by performing SYN drops to emulate an admissions control mechanism at the web server. The end result was that the resulting response time at the browser is greatly affected not only by the number of SYN drops, but also by the connection for which the SYN drops occur.
Server SYN drops are not a denial of service, but rather a mechanism for rescheduling the connection into the near future. Although this behavior is effective in shedding load, it has significant effects on the RT perceived by the remote clients. Existing admission control mechanisms which perform SYN throttling simply ignore this effect and report the response time once the connection is accepted, beginning from time tA. Ignoring this effect misrepresents both the client response time and throttling rate at the web site.
The browsers studied open more than one connection to the server, as depicted in
Suppose the first connection gets established immediately, but all SYNs on the second connection are dropped by the admissions control mechanism, causing a connection failure to be reported to the browser after 21 s. Our study of web browsers indicates that the browser never retrieves the first object which would have been retrieved on the second connection. This would be obj1.gif in
Referring to
In addition to the above mentioned reasons, for a partial page download such as this, tx cannot be considered the end of the client perceived response time—the one object not retrieved could be a significant portion of the entire page view. Likewise, suppose that the SYN transmitted at tz+9 was accepted by the server, the connection was established, and an object was requested and obtained over that connection. The end of the client perceived response time would have to be the time that the last byte of the response for that object was received by the client 20.
A variety of SYN drop combinations could occur, across multiple connections causing various effects on the client perceived response time. Obviously, if all SYNs on the first connection are dropped, then the client 20 is actually denied access to the server 22. If both connections are established, each after one or more SYN drops, then the TCP exponential backoff mechanism plays an important role in the latency experienced at the remote browser. Of course, the effect becomes more pronounced under HTTP 1.0 without KeepAlive where each URL request needs its own TCP connection. The retrieval of each embedded object faces the possibility of SYN drops and possible connection failure.
Although the majority of browsers use persistent HTTP, the trend for web servers is to close a connection after a single URL request is serviced if the load is high. Apache Tomcat™ behaves in this manner when the number of simultaneous connections is greater than 90% of the configured limit, and reduces the idle time if the number of simultaneous connections is greater than 66%. This, in effect, reduces all transactions to HTTP 1.0 without KeepAlive.
The maximum number of SYN retries that lead to a connection failure is dependent on the operating system being used by the remote browser—this defines the connection timeout. In most situations, the number of SYN retries will not be modified by the client and as such the default configuration will apply, which is 3 for Windows XP systems. After 3 tries are exhausted, the elapsed time would be about 21 seconds. Realistically, few people desire to wait 2 minutes to connect to a web site. No study has been published as to how long people do wait before canceling the page view by hitting stop or refresh. As such, a frustration timeout of 21 s will be used. This means that if a client does not see anything in the browser after 21 s, the client kills the page view download by closing the browser or hitting refresh. This is equivalent to a connection failure being reported to the browser after TCP transmits three SYN packets without receiving a reply from the server. 21 s is also used in our experiments, noting that this is something of a conservative value. To use a larger value, the effect connection failure has on the response time would be greater, exaggerating the benefit of the mechanisms described herein. Other times may also be employed instead of 21 s.
If, on the other hand, the browser is painting the screen in a piece-meal manner, indicating that progress is being made, then it is more likely that clients will tend to read the page view as it slowly gets displayed on the screen. This behavior would occur if SYN drops occur on the second connection. In this situation, the page view response time could exceed 21 s, which is apparent in the distributions depicted herein.
There is a significant, coarse-grained impact that server SYN drops have on the page view response time. A technique can be used to reduce this coarse-grained effect, which will be referred to as fast SYN retransmission and is depicted in
Referring to
SYN/ACKS dropped in the network cause the exact same latency effect as a SYN dropped at the server. From the client perspective, there is no difference between a SYN dropped at the server and a SYN/ACK dropped in the network—a SYN/ACK does not arrive at the client and the TCP exponential backoff mechanism applies.
Referring to
Referring again to
Transfer Latency: Much work has been done in applying scheduling and bandwidth allocation to control TCP transfer latency, both at the end host and in the network. In such cases, the end host or network device is a bottleneck where long queuing delays are experienced. More recently, however, work has been done on reducing the size of the response to manage response time. In such cases the network connection between client and host is the latency bottleneck, Ttransfer is known to be a function of object size, RTT and loss rate: Ttransfer=f(size, RTT, loss) (1) where f( ) is Cardwell's transfer latency function.
Several analytic models of f(size,RTT,loss) have been developed. For example, Padhye et al. in “Modeling TCP Throughput: A Simple Model and Its Empirical Validation”, ACM SIGCOMM Computer Communication Review, 28(4):303-314, 1988, developed a transfer latency function for modeling latencies of TCP bulk transfer (i.e. steady-state). Cardwell et al. in “Modeling TCP Latency”, IEEE INFOCOMM, vol. 3, pages 1742-1751, 2000, extended this model to include short lived TCP flows, which are typical of a web server transaction. Sikdar et al. in “Analytic Models and Comparative Study of the Latency and Steady-State Throughput of TCP Tahoe, Reno and Sack”, IEEE GLOBECOMM, pages 100-110, San Antonio, Tex., November 2001, have also developed a model for short-lived TCP flows.
Referring to
The region below the line is labeled as infeasible. Although it is not entirely impossible for such latencies to be observed, they are highly unlikely to occur. The model predicts that under higher loss rates and longer RTT, reducing object size can reduce Ttransfer by half.
Assuming that both RTT and loss rate are a function of the end to end path from client to server through the Internet and therefore uncontrollable, the web server is left with varying the response size as a control mechanism for affecting the Ttransfer latency. The following capabilities were implemented within response time manager 32 as mechanisms for controlling the size of the response from the server to the client:
1. Translate a request for a large image into a request for a smaller image: Capture the HTTP request packet, if the request is for a large image then modify the request packet by overwriting the URL so that is specifies a smaller image, and then pass the request onto the server.
2. Remove references to embedded objects from container pages: Capture the HTTP response packets, if the response is for a container page then modify the response packet by overwriting references to embedded objects with blanks, and then pass the request packet onto the client.
In the first technique the size of the response is greatly reduced resulting in a reduction of the Ttransfer latency for that embedded object, a reduction in Tserver on the server, and a reduction in Trender at the remote browser. An object is returned, but it is of much smaller size. In this case the quality of the content is affected since the remote client sees a smaller gif instead of the full size image. By modifying the client to server HTTP request, response time manager 32 can decide on a per request basis, during the middle of a page view download, whether or not to change the requested object size. This presumes the existence of smaller objects—for some web sites, maintaining all or some of their images in two or more sizes may not be possible. This technique can also be applied to dynamic content, where a less computationally expensive common gateway interface (CGI) is executed in place of the original, or the arguments to the CGI are modified (i.e. a search request has its arguments changed to return at most 25 items instead of 200).
In the second technique, the Ttransfer, Tserver, and Trender latency are entirely eliminated since the embedded object is completely removed from the container page. Possibly Tconn is also eliminated for the second connection, if the second connection was not already established. This has a greater load shedding and latency reduction effect than the first technique, but the quality of the content viewed by the remote client can be severely affected. Instead of viewing thumbnail images, the client only sees text. Unlike the first technique which can be applied for any image retrieval during page view download, the decision as to whether or not to blank out the embedded gifs in the container page can only be made at one point in the page view download—when the container page is being sent from the server to the client, which is transition 3→4 in
Like fast SYN and fast SYN/ACK retransmission, these techniques do not require changes to existing server systems. These techniques do not require that response time manager keep buffers of packet content to be applied. Response time manager 32 only modifies a packet and forwards the modified version. If the modification cannot be applied to a single packet, then it is not. For example, if a request for an embedded object is found to cross a packet boundary (e.g., not be wholly contained within a single packet), response time manager 32 will not blank out the reference (although, adding this capability is conceptually not difficult). Response time manager 32 is not a proxy (the response time manager is not a TCP endpoint), and as such, it ensures the consistency of the sequence space for each connection. This means that changing the HTTP request/response is constrained by the size and amount of white space in each packet.
Referring to
In block 64, managing the response time is performed based on downloading of an entire page or more than one object. In block 65, progress of the downloading is tracked for the entire page as each of a plurality of objects is downloaded. Fine-grained decisions about the response time can be made by the response time manager to reduce perceived response time based upon download latencies of portions of the entire page in block 66.
In block 67, response time may be managed by providing a retransmission from a response time manager, without the response time manager satisfying the request or response. The retransmitting may include resending the dropped request (or response) from the response time manager. This may include, e.g., a fast SYN/ACK retransmission on behalf of the server, where the retransmission timeout is less than a standard exponential backoff time or any other action in accordance with the present principles.
Packets received by the response time manager are passed through. In block 68, packets sent between the client and the server may or may not be modified and if modified, a modified version is forwarded. In block 69, substituting objects of lesser size for requested objects of larger size may be performed. In block 70, removing references from the request for at least one embedded objects may be employed to manage latency.
Referring to
A response module 82 is included in the response manager 76 and is configured to monitor perceived response times of the client 83 (e.g., a seen on a web browser) on the network 78. The response module 82 measures response times, access times, etc. and makes adjustments to processing of requests and portions of requests to reduce overall page view latency as perceived by the client 83.
In one embodiment, the response module 82 is configured to track progress for downloading of an entire page as each of a plurality of objects is downloaded. The response manager 83 makes decisions to reduce perceived response times based upon download latencies of portions of the entire page. The response time manager 76 provides a plurality of actions which are employed at preset junctures (e.g., the request for an embedded object in a page or at a response time for a handshake, etc.) in a communication session between the client 83 and the server 80. The perceived reduction in latency may be provided in a plurality of ways, which may be used independently or in combination.
In addition, response module 82 may include one or more response mechanisms 85, which may be triggered to transmit a response on behalf of the client 83 or the server 80. Examples of response mechanisms include a fast SYN retransmission on behalf of the client, where the retransmission timeout is less than an exponential backoff time, a fast SYN/ACK retransmission on behalf of the server, where the retransmission timeout is less than an exponential backoff time, etc.
The response module 82 may perform other actions to reduce perceived latency by the client 83. For example, the response module 82 may substitute objects of lesser size for requested objects of larger size, or remove references from the response or portions of the response for at least one embedded object.
Experimental Results:
Results obtained when applying the present techniques in an experimental setting are presented using a TPC-W workload. We experimented under both the single-class and multi-class environment and report on their effectiveness in both. We note that several of our techniques act as both load shedding and response time accelerators; albeit for a tradeoff in the quality of the content returned to the remote client. Our goal is to manage the shape of the client perceived response time distribution for all offered load.
Referring to
TPC-W is a transactional web e-Commerce benchmark which emulates an online book store. We used a popular Java implementation of TCP-W but made several modifications to the client code (e.g., emulated browser or EB) to make it behave like a real web browser. Although the HTTP request header sent by the EB to the server contained HTTP/1.1, the EB was actually using one connection for each GET request. The EB was emulating HTTP/1.0 behavior by opening a connection, sending the request, reading the response and closing the connection. We modified the EB code to behave like Internet Explorer™ (IE)—using two persistent connections over which the container object, then embedded objects are retried. These connections were not closed by the client but remained open during the client think periods (as per the behavior of IE). We also modified the EB so that it behaved as IE does under connection failure as depicted in
Apache™ was installed as the first tier HTTP server; Apache Tomcat™ was employed as the 2nd tier application server (servlet engine); and MySql™ was used as the backend database. Depending on the experiment Apache™ 2.0.55 was configured to run 600 to 1200 server threads using the worker multi-processing module configuration. Tomcat™ 5.5.12 configured to maintain a pool of 1500 to 2000 AJP 1.3 server threads to service the requests from apache. TomcatT™ was also configured to maintain a pool of 1000 persistent JDBC connections to the MySQL™ server. MySQL™ 1.3 was set to the default configuration with the exception that the max_connections was changed from 100 to accommodate the persistent connections from Tomcat™.
The three client machines were all IBM® IntelliStation™ M Pro 6868 with 512 RAM and a 1.0 GHzP3. The Apache™ machine was an IBM IntelliStation™ M Pro 6868 with 1 GB RAM and a 1.0 GHzP3. The Tomcat™ machine was an IBM IntelliStation™ M Pro 6849 with 1 GB RAM and a 1.7 GHzP4. The MySQL™ machine was an IBM IntelliStation™ 6850 with 768 MB RAM and a 1.7 GHz Xeon. The entire set of machines were linked via 100 Mbps ethernet switches (netGear™, CentreCOM™ and Dell™). The ksniffer box is identical, hardware wise, to the DB server. All machines were running RedHat Linux™ v2.4 or v2.6.
The TPC-W e-Commerce application included a set of 14 servlets. Each page view download included the container page and a set of embedded gifs. All container pages were built dynamically by one of the 14 servlets running within Tomcat. First, the servlet performs a database (DB) query to obtain a list of items from one of more DB tables, then the container page is dynamically built to include that list of items as references to embedded images. After the container page is sent to the client, the client parses it to obtain the list of embedded gifs, which are then retrieved from Apache™. As such, all gifs are served by the front end Apache™ server, and all container pages are served by Tomcat™ (and MySQL™).
Client Perceived Response Time Distribution under Network Latency and Loss: We began by developing a set of baselines for our experimental system under light load (400 clients)—the DB server, which is the bottleneck resource in our multi-tier complex, is executing at 60-70% load. We incrementally added network RTT and then network drops to show the effect this has on the RT distribution. We then increased the load to a point in which the response time indicates that a quality of service mechanism would be warranted.
Unfortunately, it is a very unrealistic scenario for an Internet web site being accessed by remote clients.
The TTransfer latency now becomes more significant due to the longer RT—larger page views we take longer to download than smaller page views.
It is the RT distribution in
Load Shedding via Admissions Control:
In such a scenario, it is usually desirable to apply a load shedding technique to prevent the web server from overloading or to simply improve server response time by reducing the load. We apply one such common technique which is to limit the number of simultaneous connections being served. The simplest mechanism for performing this load shedding technique is to manipulate the Apache™ setting for MaxClients. MaxClients is an upper bound on the number of httpd threads available to service incoming connections; it bounds the number of simultaneous connections being serviced by Apache™.
We instrumented the TPC-W servlets to capture their response time by taking a timestamp when the servlet was called and a timestamp when the servlet returned; this covers the time it takes to build the container page, including the DB query but does not include the time to connect to the server complex or transmit the response. As shown in Table 1, as the number of simultaneous connections decreases, the time to query the DB and create the container page decreases, but the overall page view response time increases due to SYN drops. Some clients are experiencing response times which can be considered as better than required while other clients are experiencing significant latencies due to SYN drops.
This mechanism is effective in reducing server response time but when measuring on a page view level, and including those pages which experienced the default admissions control drops, the mean page view response time actually increases. The significant effect that SYN drops have on the response time distribution makes providing service level agreements based on meeting a threshold for the 95th percentile impossible to achieve.
In a multi-class QoS environment, it is desirable to maintain a specific RT threshold for a certain class of clients. Given a finite set of resources under a heavy load (as in
We apply a multi-class load shedding technique that is commonly used to achieve multi-class response time goals which is to perform SYN throttling for admissions control. SYNs arriving from low priority clients are dropped when the high priority clients are exceeding their RT threshold. Given that clients from subnet 10.4.*.* are high priority clients, we engage the following rule within ksniffer:
Although we set the page view response time goal for high priority clients to 3 s, we only achieved a mean RT of 3.34 ss, which is an error of 11.3%. The reason for this is that some clients within the high priority class are experiencing SYN/ACK drops in the network. To alleviate this effect we configured ksniffer to perform fast SYN/ACK retransmissions:
As shown in
Since fast SYN/ACK only becomes relevant once the server accepts a SYN, it could be applied indiscriminately to all service classes. To demonstrate, we extend the previous rules by introducing a third class of service:
All clients receive fast SYN/ACK, but only high priority clients from 10.4.*.* always receive fast SYN. If high priority clients are not meeting their RT goals of 3 s, then SYNs from mid and low priority clients are dropped, without fast SYN+SYN/ACK retransmit. If mid priority clients from 10.3.*.* are not meeting their RT goals of 6 s, then SYNs from low priority clients are dropped, without fast SYN and fast SYN/ACK retransmit.
Managing Latency Due to RTT and loss: Previously, we presented a situation where the load on the system was severely affecting the RT. Now, we discuss our techniques for affecting the page view latency when load shedding would have no affect—under situations of large RTT and network loss.
We modified our environment by increasing the client RTT from 80 ms to 300 ms, and we reduced the number of clients from 900 to 400 to ensure that the DB server was no longer the bottleneck. The RT distribution for this scenario is shown in
To determine the maximal effect that embedded image rewrite would have on RT, we configured ksniffer to rewrite all embedded images from the client to the server:
Each URL request for an embedded object was captured and rewritten specifying a smaller object. This can be done whenever ksniffer receives an HTTP request: e.g., states 6, 8, and 11 in
We split our clients into three groups, one having 60 ms RTT, another with 160 ms RTT and the third with 300 ms RTT.
Unlike the previous section where the decision to drop a SYN or apply fast SYN and fast SYN/ACK was made based on the RT for a class of clients, here the decision is being made on a per page view basis, based on the elapsed time for that specific page view down. We chose 2 s as the threshold to achieve a RT slightly larger than that. Although the requests are much smaller than the original objects, the RTT still comes into play during the embedded object downloads. As such, this technique needs more modeling to determine the point at which rewriting should begin to be applied to achieve a specific RT for that page. This depends on the RTT, loss and number of remaining objects left to obtain.
Embedded object rewrite is effective, but still incurs the latencies associated with Tserver, Ttransfer, Trender and possibly Tconn—although the objects are much smaller, they still have to be processed. In another technique, embedded object removal, eliminates these latencies. To determine the maximal effect this technique has on the page view response time we configured ksniffer to perform embedded object removal for all page views:
Each reference to an embedded image was blanked out of the HTML during transition 3→4 (
Referring back to
The work presented is unique in regard to the ability to track a page view download as it occurs, properly measure its elapsed response time as perceived by the remote client, decide if action ought to be taken at key junctures during the download and apply latency control mechanisms for the current activities. To our knowledge, this is also the first work to examine how web browsers behave under failure conditions and how that affects the client perceived response time. Wei et al, in “Provisioning of Client-perceived End-to-end QoS Guarantees in Web Servers”, International Workshop on Quality of Services (IQWoS) 2005), seeks to measure and control the page view response time. Wei employs a self-tuning fuzzy controller to adjust the number of simultaneous connections being services for each class of. The RT measurement module is based on ideas from ksniffer but differs in that it tracts the activity between client and Apache in user space by intercepting socket level transactions made by Apache. As such, it is unable to detect packet loss and measure RTT, and requires modifications within the server complex. Among of differences, the system is independent from, and not coordinated with, any admission control mechanism, which they suggest ought to be used under heavy load.
Remote Latency-based Management (RLM) includes a novel approach for managing the client perceived response time of a web server. RLM manages the response time as perceived by the remote client for an entire page download by tracking, online, the progress of a page view and making service decisions at each key juncture. RLM takes into account the effect of admissions control rejects, something rarely considered when applying load shedding to achieve service level agreements. In this vein, the present embodiments are able to uncover some notable effects that occur in web browsers under conditions of connection failures and introduce a novel mechanism, fast SYN+SYN/ACK retransmission, which can be used in the context of load shedding to combat these effects. The approach presented is non-invasive and manipulates the latencies experienced at the remote web browser by manipulating the packet traffic in/out of a server complex—without requiring any changes to existing systems.
Service decisions during the course of a page view download are based on elapsed time. A prediction of the remaining work required to complete the page view download (i.e. number/size of the remaining embedded objects and their expected processing latency) may be made. Orthogonal to page view response time management is the development of traffic generators which accurately mimic the behavior of real web browsers in all aspects of behavior. This would entail a more comprehensive analysis of how web browsers behave under all conditions.
Having described preferred embodiments of a system and method for management of client perceived page view response time (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments disclosed which are within the scope and spirit of the invention as outlined by the appended claims. Having thus described aspects of the invention, with the details and particularity required by the patent laws, what is claimed and desired protected by Letters Patent is set forth in the appended claims.