| ||||||||||||||||||||||||
|
PBR or WCCP? The ISP-Caching list debates the best route for transparent caching.
On the ISP-Caching list in December, TJ posted a question about transparent caching:
A number of respondents had opinions about which system provides the better solution: [LD opined] "WCCP 2.0 will use far less router CPU than PBR would have used, predominantly due to the switching path that WCCP is in. WCCP 2.0 is in the Cisco Express Forwarding (CEF) switching path as an output-switching feature within IOS 12.0T right now. [Cisco is] working on getting it into more ISP mainstream releases (i.e., IOS 12.0S). In this codetrain, the cumulative CPU effect of enabling WCCP is practically zero additional router load." [Ed. note: LD works for Cisco, and IOS 12.0S is a Cisco product marketed to ISPs. 12.0T (where T is for technology) is experimental software.] [MN agreed] "WCCP seems to have a lower CPU hit than PBR. The redundancy is certainly there and the load balancing features are adequate for a small number of caches." [DH expanded] "In addition, WCCP recognizes when your cache is not responding and routes your traffic through the router, bypassing the cache if it's down. PBR does not, although there are scripts available that will telnet into your router and turn off PBR if the cache fails." [ES disagreed] "Regardless of the method (WCCP or hand-configured PBR), the router is still doing essentially the same job (i.e.; examining each packet and forwarding accordingly) so the CPU usage should be nearly identical." Another respondent explained the differences between the two systems: [LD said] "The code that implements PBR and WCCP are completely different: the 'intercept/match' occurs at a different stage of all the steps associated in switching a packet from one interface to another. PBR and WCCP are in different switching paths." Some other respondents favored a completely different solution: [NH wrote] "WCCP 2.0 is better than version 1, but still not as good as using Layer4 switches from Foundry or Alteon." [JF concurred] "I agree that Layer 4 switching is the way to go and that both Alteon and Foundry have solid product offerings. You should also look at ArrowPoint Communications. They make switches that can distinguish between cacheable and non-cachable content, which will significantly improve your cache performance. I have used all the products mentioned above and prefer Arrowpoint's intelligence over the rest." ME directed attention to his company's Layer 4 switching option: "Read the results of an independent test of Foundry Networks' ServerIron XL switch." However, another respondent pointed out a drawback in using Layer 4 switching solutions: [LD wrote] "All Layer 4 switch solutions require you to purchase 'another box' when, in WCCP's case, you probably already have the functionality in your router (the assumption here being that you have a Cisco router). I've yet to see the 'content aware switch' actually improve performance, unless your cache is running at 100%." [Ed. notes again: LD works for Cisco] [KS added] "The problem is that the cache will set a relatively low ceiling on your total requests per second if it has to process both cacheable and non-cacheable requests. By feeding the cache only the content requests it can cache, you get a much higher available rate of requests per second. Improving the available number of requests per second achievable through the cache farm is of some clear benefit; buying the content aware switch would probably be cheaper when you are pushing your cache or anticipate that you would be."
End |
|
||||||||||||||||||||||
![]()
|
||||||||||||||||||||||||