in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Load Balancing Servers, Firewalls and Caches - Kopparapu C.

Kopparapu C. Load Balancing Servers, Firewalls and Caches - Wiley Computer Publishing, 2002. - 123 p.
ISBN 0-471-41550-2
Download (direct link): networkadministration2002.pdf
Previous << 1 .. 59 60 61 62 63 64 < 65 > 66 67 68 69 .. 70 >> Next

When a client initiates the TCP connection with a TCP SYN packet, the load balancer does not have the URL information yet to determine the destination cache. So the load balancer sends a SYN ACK and waits for the ACK packet from the client. Once the client establishes the connection, the client sends an HTTP GET request that contains the URL. Now the load balancer can use the URL to compute the hash and determine to which cache it goes. Sometimes the URLs may be long and span multiple packets. In that case, the load balancer will have to buffer the packets and wait for multiple packets to assemble the complete URL. All of this can be pretty computing intensive on the load balancer. Alternately, the load balancer may also limit the URL used for hash computation to the first few bytes, or whatever URL string is available from the first packet. Whether the load balancer can support the URLs that span multiple packets and how much impact this has on performance varies from product to product. In many cases, the cache may become a performance bottleneck before the load balancer becomes one, although the performance impact always depends on the specific cache and load-balancing products used.
URL hashing can be used with the hash-buckets method to provide efficient cache load balancing, as just discussed.
Content-Aware Cache Switching
Caches are primarily designed to speed up delivery of static content. Static content can be loosely defined as content that does not change often. For example, if you look at Yahoo’s home page, it is composed of several objects. Of those objects, some are dynamically generated, and others are static. Examples of static objects include Yahoo’s logo, background color, basic categories of text, and links in the page. Examples of dynamic objects include the current time and the latest headlines. Attributes of the “current time” object are different from attributes of the “headlines” object, in the sense that the current time is different every time you retrieve it, whereas the headlines may only be updated every 30 minutes. Caches can help speed up the delivery of objects such as headlines as well because although these objects are dynamic, they only change every so often. The content publisher can specify a tag called time to live (TTL) to indicate how long this object may be considered fresh. Before serving the object, the cache checks the TTL. If the TTL has expired, the cache sends a request to the origin server to see if the object changed and refreshes its local copy. But the caches cannot speed up delivery of objects such as current time, or real-time stock quotations, as they are different each time you retrieve them.
When deploying load balancers to perform transparent-cache switching, we have so far discussed redirecting all traffic for a specific destination port (such as port 80 for HTTP) to the caches. But why send requests to the caches if the request is for a dynamic object that cannot be cached? If only the load balancer can look at the URL in the request and identify the dynamic objects, it can bypass the caches and forward them directly to the origin servers. This will save the caches from processing requests that the cache cannot add any value to, and focus instead on the requests where it can add value. This process is referred to as content-aware cache switching, since the load balancer is switching based on the content requested.
We need to specify URL-based rules to the load balancer so that it can distinguish the dynamic objects and bypass the cache for those requests. Exactly how you specify rules and the granularity of the rule specification varies from product to product. For example, we can specify a rule that makes the load balancer look for .asp at the end of the URL, or look for a ? in the URL to identify requests for the dynamic objects, as shown in Figure 7.9.
Figure 7.9: Content-aware cache switching.
Content-aware cache switching can also be used for other purposes. For example, we can specify a rule that makes the load balancer bypass the cache for specific host names. In this way, an administrator can control what sites are cached or not cached. We can also organize the caches into different groups and allocate a group for each type of content or site. For example, an ISP may decide to devote a certain group of high-speed caches for caching a particular Web site because of a business agreement with that Web site owner.
Caching improves the client response time and saves network bandwidth. When used with origin servers, caches improve server performance and scalability. Load balancers make it easy to deploy, manage, and scale caches. Special load-distribution methods such as hash buckets and URL hashing help improve the cache-hit ratio, a measure of cache efficiency. With content-aware cache switching, load balancers can selectively direct content to the caches or origin servers based on content rules in order to further improve the efficiency of caches.
Previous << 1 .. 59 60 61 62 63 64 < 65 > 66 67 68 69 .. 70 >> Next