The tool to use is polygraph, but the workloads may need updating to match currently seen traffic patterns.
The tools are there - whats needed is equipment, time and manpower. The project is lacking all of the above. Adrian 2008/7/18 Richard Hubbell <[EMAIL PROTECTED]>: > --- On Thu, 7/17/08, Amos Jeffries <[EMAIL PROTECTED]> wrote: > >> From: Amos Jeffries <[EMAIL PROTECTED]> >> Subject: Re: [squid-users] squid in ISP >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED], "Rhino" <[EMAIL PROTECTED]>, >> [email protected] >> Date: Thursday, July 17, 2008, 6:26 AM >> Richard Hubbell wrote: >> > >> > >> > --- On Fri, 7/11/08, Rhino <[EMAIL PROTECTED]> >> wrote: >> > >> >> From: Rhino <[EMAIL PROTECTED]> >> >> Subject: Re: [squid-users] squid in ISP >> >> To: [EMAIL PROTECTED] >> >> Cc: [email protected] >> >> Date: Friday, July 11, 2008, 6:56 AM >> >> Siu-kin Lam wrote: >> >>> Dear all >> >>> >> >>> Any experience using squid as caching in ISP >> >> environment ? >> >>> >> >>> thanks >> >>> SK >> >>> >> >>> >> >>> >> >>> >> >>> >> >> I'm sure there's much larger ISPs out >> there and >> >> been using it much longer; >> >> just passing along our info. >> >> We're a small ISP serving around 10k >> dialup,dsl,cable >> >> modem and MAN subs >> >> via a dual-homed to different ISP BGP WAN. >> >> We loaded squid on a quad core linux box with >> around 1.2Tb >> >> disk >> >> capacity and 32Gb RAM, using a Cisco 4948 switch >> and WCCP2 >> >> to transparently redirect to Squid. >> >> There were some major hurdles along the way >> >> mostly getting the 4948 to pass the L2 WCCP >> traffic - >> >> 2 IOS bugs and a year in the process) but once >> that worked >> >> and we got our IPTABLES set up properly, >> transparent >> >> redirection >> >> has been working quite well. >> >> Some tweaks needed to our Squid config, but with >> the help >> >> of this list >> >> - particularly Henrik and Amos' posts - at >> this point >> >> we're very >> >> encouraged by the performance and bandwidth >> savings >> >> we're seeing on the >> >> system which has only been truly active for around >> 3 weeks >> >> now. >> >> Again, we're a pretty small shop - so when our >> old >> >> NetApp Netcache >> >> was no longer able to adequately handle the load, >> we needed >> >> an >> >> effective, minimal-cost solution which this is >> >> demonstrating to be. >> >> Hope that helps. >> >> -Ryan >> > >> > >> > Thanks for sharing this. We're doing about 75 >> requests/sec on a quad-core Xeon with 16GB. Still trying >> out some different configs. >> > I have cache_mem set to 2GB and it's working well >> so far. >> > >> > It's not even worked up a sweat and has plenty of >> room for more work. >> >> I'll bet it isn't. >> 75 is not even close to half what squid was doing in Y2K. >> :) >> >> If you want to stress it we'd be glad of the results. > > I can do this. Is there a set of tests that people would like to see? > I think we should concoct a test plan, albeit a very basic one. > > Is there a squidbench? squib for short? Maybe it could start by either > fetching a digest or using one as input? Or just use a list of urls from an > access.log? > > If we don't have a level SUT (system-under-test playing field) we can at > least have a level load-generator. The fewer variables the better. > >> >> Amos >> -- >> Please use Squid 2.7.STABLE3 or 3.0.STABLE7 > > Are there redhat packages for 2.7? > > > > > >
