نمایش نتایج: از شماره 1 تا 2 از مجموع 2
سپاس ها 4سپاس
  • 1 توسط patris1
  • 3 توسط patris1

موضوع: Optimizing ISA 2004 caching

  
  1. #1
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

    Optimizing ISA 2004 caching

    کد:
    http://www.isaserver.org/tutorials/Optimizing-ISA-2004-caching-Part1.html

    PART-1


    This two part article will serve as an informative map on ISA 2004 caching and as a guide on the optimization of the ISA Server 2004 cache.



    ISA server 2004 aids in the provisioning of efficient communication between local and remote locations. ISA has particularly been designed to provide caching facilities to branch offices and using this feature properly will maximize internet performance in distributed organizations and will maximize bandwidth usage.
    Optimization of internet traffic is essential and by doing so increases performance and capacity. This is achieved through ISA’s specialized caching properties. Enabling caching can improve network performance and response time by saving copies of images, text, and other data that clients download from web and FTP sites on the Internet and making them available to the next client that requests information from that particular site quickly on the LAN rather than slowly over the WAN link. In most scenarios savings of 30-60% on internet bandwidth will be evident, if the solution is properly configured; this is a significant saving that can boost internet utilization. Bandwidth = money and saving bandwidth effectively means saving money especially if speed plays a role as it does in caching.
    ISA services that use caching

    The bundled web proxy and firewall service in ISA 2004 uses caching to improve the performance of the browsing. The caching works by means of checking if the requested object already exists in the local ISA cache. If the object is stored in the local cache and if the object is current, the proxy server sends the object to the client from the cache. If the page is not in the cache, the proxy server sends the request to the appropriate server on the Internet. The retrieved content is then passed back to the requesting client.
    This portion of the caching can be streamlined by investigating what is being downloaded from the internet. This is done to optimize ISA caching process. For example, everyday users visit their webmail.com website. ISA caches this site but new daily content is uploaded. A caching job rule can be created that regularly caches the content prior to the user requesting the website. If this is for a large organization, significant bandwidth gains may be achieved.
    Rule structure improves cache performance

    The order of the ISA rules may affect the speed of the object's retrieval. Let’s examine the process. ISA server first checks if the content is not blocked, ISA Server then saves a copy of the content in its cache and then the object is returned to the client application that made the original request. The firewall rules should be ordered correctly so that the content is quickly filtered, some mis-configurations that I have seen have resulted in slow responses.
    Branch offices

    If an organization has more than one ISA server, consider the disturbed caching approach as this will allow you to leverage off the sum of the accumulated caching across all branch office and head office ISA servers. ISA server 2004 has this feature incorporated, and it is a great advantage of the caching mechanism. All the servers running ISA Server in the branch offices can be configured to forward their requests to the head-office ISA Server. The head office ISA Server will accumulate a large cache that contains the requested items from the subordinate offices. This ensures that the Internet content can be delivered to the client with the least use of WAN bandwidth. Further distributed caching at branch offices can be configured for greater efficiency.
    Storage of the cached content

    RAM caching storage
    ISA server 2004 Caching stores the web content on the computer running ISA Server, in the server RAM or on the hard disk. The more RAM that is available, the faster the performance of stored objects in RAM. However note that the default amount of RAM that will be used for caching purposes is 10%. I typically recommend that, for best results, at least 1 gigabyte of RAM be used on caching ISA servers that have significant load.
    Hard disk caching storage
    Caching location may also be stored on the hard disk depending on the sequence of the request. Recent content is typically stored in RAM while older requests are stored on the hard disk. On large installations of ISA it is recommended that the hard disk also be one of high performance. New disks with low seek time and 15000rpm are now available and improve cache performance substantially.
    The Cache file
    The cache file is a single file. For the purpose of efficiency this file can be located on each disk partition. However it's recommended that the file be located on a separate physical disc other than where the ISA, operating system and the page files are installed. This will reduce contention on the system and boot disk. On start up of the ISA services ISA will re-index the cached objects. The disk partition has to be formatted with NTFS. The cache file will have a .cdat extension and will grow to the limit that the ISA admin has preset.
    Network systems with low internet bandwidth
    Millions of networks are connected to the internet and continuously millions are being connected as connectivity becomes more wide spread and inexpensive. The fact still remains that there is a cost associated with bandwidth and the more users connected, the less bandwidth is available, both on the internet, but more importantly, behind the firewall. In developed countries, 100mbps connections are common; in developing countries the equivalent in terms of cost is a 1-4 Mbps connection. Both need to be managed and optimized. It is recommended that monitoring and logging of the usage be done in order to understand the dynamics of the load and protocol share. This practice helps in designing the cache system and optimizing its performance. Protocols other than HTTP and FTP do not benefit from caching, for this reason it is important to know what percentage of traffic is HTTP, HTTPS and FTP.
    ISAs two types of caching

    Figure 1: Forward Caching
    Forward caching occurs when a user on the internal network initiates a request for Web content located on an external Internet Web server. The user initiates an HTTP, HTTPS or FTP request to an Internet Web server, the request passes though ISA Server, ISA Server retrieves the content from the external Internet Web server, on the client’s behalf, stores the content in its cache and returns the content to the requesting user.

    Figure 2: Reverse Caching
    Reverse caching occurs when users on the Internet request Web content located on the internal network and are allowed through a Web publishing rule. The Internet user requests content from the internal web server, ISA Server forwards the request to the Web server on the user’s behalf. The Web server sends the requested content to ISA Server, which then returns the content to the originating Internet user. A cached copy of the requested information is kept in the ISA cache for the next request for the same information.
    Optimizing the cache configuration

    ISA Server caches can be configured to limit certain types of content that are being cached; the size of certain cached objects can be manipulated to reserve cache space and capacity for additional smaller objects. Each environment has different needs so some analysis maybe required.
    Another key consideration would be the location of the caching server within the organization. The centralized approach is not always the best approach as some remote sites may have slow links to the central Internet stream that originates at Head office. The preferred solution would be to layer the caching environment so that the ISA server at the branch office chains upstream to the main ISA server but the subordinate ISA server also keeps a local cache. The reason for this is that the ISA server will not need to traverse across a slow link to retrieve content if it caches the content locally. In the next article in this series, this will be explained in more detail.
    Summary

    In the first part of this series we covered performance improvements that can be implemented when using ISA 2004. We also looked at the different types of caching and how ISA handles regularly accessed content both inbound and outbound. In the following article different optimization methods will be described that further improve caching on ISA 2004




    موضوعات مشابه:
    th95 سپاسگزاری کرده است.

  2. #2
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.isaserver.org/tutorials/Optimizing-ISA-2004-caching-Part2.html

    PART-2



    In the second part of this article we will cover additional optimization techniques that can be used.



    This article will focus on ISA 2004, compression within ISA 2004 and modifications to features of ISA 2004 brought about by the introduction of ISA service pack 2.
    There are two modes of caching; Active and passive caching. Active caching pre fetches content from the web server and caches it. Passive caching fetches content from the web server only when the user requests the content and then caches the content.
    Passive caching is used to improve Internet access performance and to decrease the use of Internet bandwidth. The best way to understand the traffic needs to be pre fetched, one will need to setup logging, this in turn will help build a baseline, and it will help identify which traffic should be logged (the traffic that one would monitor is HTTP, HTTPS and FTP).
    Performance impact on ISA

    Most ISA scenarios only make use of one caching server but scenarios change and larger organizations have more scalable requirements. ISA is capable of handling more than 30,000 cached requests. It is recommended that performance monitoring be performed before going live. A stress test is an excellent way of ensuring that your hardware is able to perform.
    To setup performance monitoring follow the below instructions:

    1. Open the Performance console from the Administrative Tools folder.
    2. Ensure that the Pages/sec counter is selected and press DELETE. Press DELETE two more times, deleting all the performance counters.
    3. Click the Add (+) button on the Performance console tool bar.
    4. In the Add Counters dialog box, in the Performance Object list, click ISA Server Cache.
    5. Click All counters, and then click Add.
    6. Click Close to close the Add counters dialog box.
    7. Press Ctrl-R to switch the performance view to a report view.

    ISA Server Cache and Compression

    ISA Server cache and compression work together to provide a more efficient serving of compression requests. The content is cached in one of three formats:

    • Compressed: The content is requested and cached in compressed format.
    • Uncompressed: The content is requested and cached in uncompressed format.
    • Uncompressed and Uncompressible: If a request for compressed content is received, and it arrives at the cache uncompressed, it is stored in the cache as uncompressible. Subsequent requests received for the same compressed content enables ISA Server to recognize that the content is uncompressible, and ISA thus serves it from the cache uncompressed rather than from the Internet.

    ISA 2004 sp2 support for BITS Caching

    The Background Intelligent Transfer Service (BITS) aids in transferring large quantities of data without degrading network performance, thus maintaining efficiency of communication between networks. This is achieved through transferring data in small groups. By doing this, unused bandwidth is utilized as it becomes available. The groups of data are reassembled once their destination is reached in typical TCP fashion. This service is designed for Windows update and software update service, other content does not benefit from this feature.
    HTTP Compression

    HTTP compression decreases file size by using algorithms to do away with unnecessary data. These algorithms compress static files, and are able to perform on-demand compression of dynamically generated responses before sending them over the network. These same algorithms which are used to compress the files are also used to decompress the static files and dynamic responses. HTTP compression applies to all HTTP traffic passing through the ISA server.
    Three Web filters are responsible for HTTP compression, they are listed below:

    • Compression Filter
      The compression filter is responsible for the compression and decompression of HTTP requests and responses. It is a high priority filter because it is responsible for decompression; and decompression is essential before an alternative web filter can be utilized.
    • Caching Compressed Content Filter
      The Caching Compressed Content Filter does just what it says. It is responsible for caching of compressed content and serving a request from the compressed content in the cache. It is the filter with the lowest priority, because caching can take place after all other filters have handled the content.
    • Range compression filter
      Range compression is the compression of a specific portion of Web content. ISA Server supports range compression, thus it is a good practice to enable it between two ISA Server computers. It must be noted that range responses are not stored in the ISA sever cache.

    Understanding the cache rules

    ISA is made more adaptable through the addition of specific caching rules, if these rules are understood; ISA caching can be adapted to meet many requirements. Each caching rule allows for specific types of content to be processed in various ways. If the caching rules are not configured, default caching is enabled based on the defaults set in place by the ISA professional.
    Each rule configured allows for the following customizations:

    • Source and destination networks
    • What types of items are retrieved and stored in the cache
    • HTTP caching settings, such as the Time to Live (TTL) of objects retrieved
    • File Transfer Protocol (FTP) caching settings
    • Secure Sockets Layer (SSL)–specific settings
    • Object size limitations

    Deleting Cache Contents

    ISA server stores cached content in a cache content file which resides in the URL cache folder on each drive that is configured for caching. With each start up of the Microsoft Firewall service, the cache content file on each drive is verified to ensure that it is present on the drives that are configured for caching. If it is found to be deleted new cache content file is automatically created.
    The cached content stored in these files can be deleted manually by deleting all the cache content files and restarting the Firewall service.
    Cache Array Routing Protocol (CARP)

    In ISA Server 2004 Enterprise Edition, the Cache Array Routing Protocol (CARP) mechanism used hash-based routing that depended on the URL to determine which array member would handle the request. CARP exceptions were the sites that you wanted to be handled by a single array member. The array member that was assigned to handle the request was selected based on the host name as it appeared in the host header. This has changed in Service Pack 2, to better complement Internet Explorer functionality and provide better control over the distribution of requests that produce heavy Web traffic.
    In Service Pack 2, the CARP hash-based routing uses the host name to determine which array member handles the request. CARP therefore assigns all of the requests for a particular host. This also maintains the context of the session, as the requests and responses are handled by a single array member. CARP exceptions are the sites that you want to be distributed to all array members, because they generate too much traffic to be handled by a single array member. For example, you may want all Microsoft update requests to be distributed, and not assigned to a single array member. You would therefore add the Microsoft Update site to the list of CARP exceptions.
    Summary

    In the second part of this series we covered performance improvements that can be implemented when using ISA 2004. We also saw modes of caching within ISA 2004 and improvements that were added to ISA 2004 in service pack 2. We looked at CARP and the enhancements it has over simpler strategies like ISA chaining. ISA caching performance needs to be closely monitored in order to achieve optimal performance



    th95، pardazande و hamid khan سپاسگزاری کرده‌اند.

کلمات کلیدی در جستجوها:

isa2004 clear proxy cache

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •