Slashdot Mirror
Squid, FreeBSD Rock the House at Caching Bake-Off
Blue Lang writes: "Saw on the squid mailing list today that the results of the second polygraph Web-cache benchmarks are in, and squid on FreeBSD captured a few top marks, as well as performing exceptionally well overall. Interesting reading, especially as a comparison of free and open systems versus some very well-architected proprietary solutions."
By your logic, NT and IIS are good and solid, too, right?
Thanks for asking!
The kernel http daemon in Linux 2.4 will make reverse http caching obsolete and outmoded.
There are some people who can't spell either. Now, I don't disrespect the occasional typo.. but when you can't spell allowed, that's simply disgusting. And another thing, this is surely not news for nerds, nor stuff that matters!
I'm saving baby elephants shouldn't you help?
I think one of the first developers of squid is the CTO of Akamai. Interesting coincidence.
I do not use BSD. Ever.
I do not use Linux or Bsd. Ever.
WINDOWS ALL THE WAY BABY!!!!!
This is just the kinda crap i'd expect from a classical composer who lived from 1862 to 1918.
Do NOT rise from the dead and troll about Operating Systems Just because the stuff on MTV really sucks.
roflmao
abrasive little turd, aren't you, ahab?
And look closely. Bruce Parens??? Isn't impersonating a public figure in our community worthy of a "TROLL -1" at least?
Go work on your games or something.
Adding quote to sig. ... I mean, if thats ok, John? :)
Where the hell is Novell's BorderManger in this little test? It's dominated every damn benchmark I've ever seen but is it here? NNNOOOOoooooo Piss on that shit.
'cuz it wuz st00pid
Good move - NT has copyfile()- dirty! - so linux can match them at their own game. Although it is not correct , serving something static does not seem terribly high risk when bounded by debug flags, and I can live with this.
At the risk of getting flamed, I've not had good luck with NetBSD. On the Intel platform, I've put Linux, BSD/OS, FreeBSD, OpenBSD, and NetBSD to the test. Of all the platforms, NetBSD was the only one that gave me stability *and* performance problems.
... since I have been nothing but disappointed with squid. This past summer I tried to set it up as a transparent caching proxy for a moderately busy ISP (~800 requests/sec) and it leaked memory like a sieve on both Linux and FreeBSD. The best thing I can say about squid is that it drove me to try FreeBSD in desperation trying to plug the memory leak, and though that didn't solve the problem (certainly not BSD's fault), it did leave me with a very impressive OS that now runs all our DNS and mail services.
And this is why Inktomi weren't present. They go to great pains to be HTTP 1.1 compliant, and yet perform well. A stripped down cache is always going to provide better headline numbers as it simply provides far less functionality. If your product is being sold on this basis, fighting for the highest ops/s isn't going to help your case.
I think it *IS* just FUD. Inktomi seem to have won a lot of big customers on the basis of pretty good performance and very good adherance to HTTP 1.1 which a lot of the other caches don't have. They were first in the market with thrid party WCCP and they also support streaming media, NNTP and a plug in architecture.
Looking at the vendor comments, All but two of the vendors saw their performance as being noteworthy. And the two that didn't had major issues with the testing method.
So, perhaps all of the caching solutions are above average?
As a side note, squid on low end hardware rocks. on a 486/66 it speeds up the common version 4.0 browsers, with only a slight latency hit. on a 128k line. (And it's real fun to be browsing with a Mozilla 0.1 (8bit/CPM) browser id. )
Having just read the article, it is clear that while freebsd had a respectable showing, it certainly didn't "rock the house". To the contrary, it didn't even finish first. Why was this article posted with such a misleading headline? Are legitimate headlines so scarce?
A pair of identical (load balancing and transparent failover via BigIP) rackmount servers, each with a PIII 600 CPU, 256MB, 2940UW and 20Gb of disk.
'killer'? With Adaptec SCSI controllers?
I'd love to pitch in and help, only I'm more intent on spending my all-nighters working on code that means something to me, my friends, and my customers than on code written by some now-millionaires who didn't care enough to do it right the first time.
I know why it's a bad idea! Cause linux sux cox!
Why won't they test Slashdot Effect value, time in minutes before the shit hits the fan..
NetWare 5.1 has a mini-http server built into the kernel. The argument being that you can still administer/fix your server in the event of a problem - pretty much everything can crash 'ceptin' the nic and the os and you can the the think back, all from the comfort of your jellified pooper.
Oh, and Craig - you are GREAT on the Late Show! You're better than Conan! Don't listen to the ratings. Hang in there, champ!
C'mere, you. I love you. Gimmie an ole squirt of pee in your face.
I was always wondered why to spend time and money on stuff like reverse-proxies. IMHO, one can get much better bang/buck by setting up an array of say 100 inxepensive CPUs crunching all the stuff your network would be ever able to deliver to your doorstep.
Note: I am not talking about clusters here, just a simple array with intellectual network cards (so they can negotiate load distribution between CPUs) on the input side.
What is wrong with this picture ?
Seems like you don't use braincells as well...
What about playing Quake 3 using the GLX driver for the S3 Virge? :P
i think he is referring to async io as far as squid (cache_dir asyncufs ....) but of course this works in freebsd as well (i had to --disable-poll) I suppose I shouldnt embarrass you by repeating your .sig
What is the architecture of squid? I read that it was "I/O driven", does this mean it uses asynchronous network access where if data comes in, a thread is chosen to service it, then when it becomes I/O bound it goes back into the pool?
The open source operating systems, on the other hand, really did shine, especially FreeBSD. Then again, this sort of network-heavy workload is a perfect fit for *BSD, so that aspect isn't surprising.
It sucks that they focused only on the performance aspect of the devices. My experiance has been that nearly every single cache out there has HORRIBLE RFC conformance, to the point where they blatently violate the HTTP RFC and don't support critical features from HTTP/1.1.
Sure, netscape and most HTTP clients can connect to them, but try it with something that really works HTTP/1.1 features and it just sucks. So far, I have yet to see a single 'transparent' proxy that even implements HTTP pipelining, let alone the more advanced stuff from the spec :
IMHO, this is the most critical point when choosing a vendor - how well they implement HTTP/1.1 - very little else matters!
Sure. If bandwidth costs more, and in some (non-north american) countries it's staggering.
Where are squid's weaknesses, and what can be done to improve on them?
Squid uses the native filesystem of whatever OS it runs on. Could a better solution be that it doesn't use one at all. Let it write "raw" to partitions you assign it. We don't need permissions checks, don't give a damn about concurrency (one i/o thread per partition), don't care what happens when we crash (other than to know if the file is bad or good). How much could be stripped out and even optimized for this use.
There also seem to be some IP stack issues too. I know you don't want to be doing some of this stuff in user mode, but could squid benefit from jumping in lower down at the IP level and handling http 1.1 and relevant TCP bits it self?
I'm not a kernel hacker (obviously), and I don't even know if these are squid's weak points, but it seems a good place to start teaking.
The response under load is the single biggest difference I've noticed under FreeBSD & debian. At even a load of 2 on this box (P120/24), I notice the lack of response under X (as in: wait several seconds for the cursor to move). Under FreeBSD on a K6-200/64, there is nearly no loss at a load of 10 (from several parallell makes). Yes, that's close to apples/oranges, but the freebsd box used to run debian, and I noticed a similar phenomenon there.
:)
Maybe it's just configuration somewhere; both boxes are pretty much stock. However, it seems to me that I noticed something similar with macbsd and linux
a couple of years ago, when the macbsd box had a slight memory/cpu disadvantage. (However, if you tried to run lyx with the default postscript fonts and not using xfs, both came to a screeching halt
hawk
Err let's see:
/. does not use CGI - it uses a preprocessor (mod_perl) which shares memory and caches compiled Perl bytecode.
/. uses a seperate server for static content (images)
/. content, I'm not sure that a accelerator proxy would be such a big help.
/. uses no CGI in time critical areas, and mod_perl is in many ways superior to fast-CGI.
/. code being scary I'll take your word for it. I can't for the life of me see what's wrong with using DBI though.
1.
2. Last I checked
3. Given (2) above and the highly dynamic nature of
4. As I said
As for
-----
Akamai doesn't seem to be anything more than a network of caches, some load-based routing, and a private network connecting them, plus a few geegaws like special transport of certain stream formats. Not to malign what they're doing, but I wouldn't say caching *vs* Akamai.
While you did address the points of the original article, I still feel the need to say the code is most *certainly* far from being optimized for performance..
-- I'm the root of all that's evil, but you can call me cookie..
Just a quick question regarding the machines and the setting they're in:
A pair of identical (load balancing and transparent failover via BigIP) rackmount servers, each with a PIII 600 CPU, 256MB, 2940UW and 20Gb of disk. And let's not forget the triply-redundant T3's to threee distinct Tier-1 internet providers.Nice setup. What do P3's get you that P2's or even celerons don't? The extra cache won't help a whole hell of a lot and the SIMD or KNI instructions don't do anything for you, either...
...Now I heard that somewhere there is a patch to the Linux kernel that uses MMX to help calculate the packet checksums faster but you said you don't use Linux.
I'm surprised I've not heard much about Oops. I'm trying to get it working here, unfortunately the documentation isn't great. However it does seem like the architecture would make it an extremely fast little proxy, and it seems to have most of the features of Squid.
Anyone got any good stories about using Oops?
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Heh.. I work for Dell, and if the stability of Dell's servers are any indication of the stability of Windows NT, you sure as hell don't want to be using them as an example.
I read the page too, and while it definitely shows that Squid is a viable option, I didn't see it blowing the doors off the competition either. The Microbits pizza box delivered nearly the same performance at significantly less cost, and some of the higher end offerings were able to deliver considerably greater price/performance. The IBM 3500M10, for example, was able to deliver almost double the peak throughput at only a slightly greater cost.
These results are surprising to me - I would have thought that the use of commodity hardware and no-cost software would have created a compelling price advantage. What happened?
If there's something I'm missing, could someone please spell it out for me?
LILO boot: linux init=/usr/bin/emacs
nWo for life!
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
this sig limit is too small to put anything good h
Huh? squid was pretty darn "evolved" last I checked. It's been around a long time.
... but I don't think the comparison was intended the way you took it.
... fact is as a caching proxy squid hauls ass. period. If you take advantage of some of the redirect features you can do some pretty amazing things with it.
I agree comparing to two is a bad idea
performance is king
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
Now, why oh why would that be a bad idea?
The folks at Microsoft thought it would be cool to move the GDI into the kernel for faster graphics under NT. Now that NT crashes, the blame falls on "unstable video drivers" instead of the system architecture.
No thanks. Our Pentium 166 can saturate the T1s already.
The wheel is turning but the hamster is dead.
The wheel is turning, but the hamster is dead.
Um did you look at the hardware and cost of that product? silly troll or just moronic? you decide.
"Think of it as evolution in action."
I'm sure I heard that Microsoft Proxy Server, along with other proprietary web-cache software, is based on Squid. Is this true?
-- Ed Avis ed@membled.com
Read the PCI spec. 64bit pci cards are suppossed to work at 64/66 64/33, 32/33... yes 32bit by 33mhz... Most 64bit pci cards will fit in any PCI 2.2 slot.
"... That probably would have sounded more commanding if I wasn't wearing my yummy sushi pajamas..."
-Buffy Summers
Goodbye Iowa
Go quote the mindcraft study to someone else - you've posted the same excerbs from that report on three seperate posts of mine. The mindcraft report was technically valid but was used in an unrealistic environment. So both sides are right. Can you stop this now?
Squid, on the other hand, is a good compliment if your yearly IT budget is smaller than marketing's christmas party funding... but for serious stuff?
Sorry, but Squid didn't cut it here - I know, we all want the open source crew to win, but hey.. it just didn't happen here.
For latency, yeah.. but I don't think hits-per-second wants to be as low as possible....
He wasn't bored. He was bearded. There's a difference. =)
Now, I'll say it again alittle more succinctly: Squid got squished.
Windows delivers the scalability and reliability to run real businesses-now.
Opinion.
Feature for feature, Windows 2000 is the most cost-effective business platform.
Opinion.
Microsoft wants to work with you to make your business successful on the Internet.
Fact.
Some of the biggest e-businesses and dot coms run on Windows.
Fact.
Dell, the largest e-business on the Internet, runs on Windows.
Fact.
Sun claims to be a leader in system reliability and more reliable than Windows.
Fair enough, they do claim to...
Electrolux Group, Accounting.com, Pro2Net and thousands of other companies have switched their Web sites from Sun platforms to Windows. (Source: Netcraft)
Fact.
The vast majority of Sun?s Solaris shipments are on Sun?s own expensive, proprietary hardware and Sun has always buried the cost of Solaris in their hardware pricing.
Opinion.
Conclusion: Windows is useful in some environments. So is everything else. I care about numbers, data, real, tangible, and reproducable things. If an NT server in X configuration crashes 35 times in and has an average downtime of 5%, while a linux box in X configuration with similar performance has a downtime of 1%.. linux wins. Conversely, if the NT box can pump out 8000 hits/s, while the linux box can manage 2100 hits/s and I need raw performance, NT wins. Stop reading the marketing hype and start reading the technical specifications.
I can't tell whether you meant this as alittle FUD thrown over linux, or because you believed all the other vendors there were inferior to FreeBSD. On one count you'd be wrong, unfortunately.
Yes, you can rely on FreeBSD. You can rely on NT too for certain things. That doesn't say much. I'd also like to point out that there are very serious holy wars out there over whether linux is superior to FreeBSD along with the general consensus in the linux camp that they will catch up (if they haven't already) with the BSDs in short order. The evidence is inconclusive..
Lastly.. about that "killer caching proxy"... umm, with all that bandwidth, why would you need proxying anyway? by that time you're probably a backbone provider and don't need to worry about stuff like that. Caches are used by ISPs with a T1 or two or corporations to limit bandwidth.. not by super-sized ISPs (not generally - AOL comes to mind as an exception). And why the 2940UW (I'm assuming you're thinking adaptec)? They have Ultra160 fibre now in the AIC-78xx chipsets which is register-compatible with the aic78xx module for linux... or for the *BSDs.
I have a 32 bit version sitting in my system.. the very same one I'm typing this on. Hit up adaptec's site and search for the 29160N Ultra 160 SCSI adapter.
No offense, but you call that winning? It lost to it's competitors categorically and across the board - hits, latency, cost/performance.. what's the good news? Anyone?
Unfortunately, several web servers still don't support Expires: headers (e.g. thttpd, which works very well for static data). Then again, browsers think they're smarter than the servers and proxies, since in the absence of Expires: headers they cache stuff depending on the type of data and the URL, AFAIK, so it's not absolutely necessary to set these headers.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Given.. there is a ton of really good info in there, especially the network configurations (each company brought their own network) and disk configurations, etc.
Cache the world!
--
blue
i browse at -1 because they're funnier than you are.
> Tangenital
ick
{chuckle}
To answer your question, there are two main reasons why this shouldn't be done.
1: Copyright could be infringed on the pages being cached
Okay, that makes a certain amount of sense and I can understand being cautious, but caching makes the web go around. It's already pervasive, or so I was given to understand. As another poster mentioned, what about Google?
I guess the size of the financial club is often more relevant than the technical legality of a something. {sigh}
2: Many sites get their revenue from click throughs and banner ads. If
Wouldn't bother me personally, I never seem 'em anyway, I use Junkbuster or turn autoloading images off. It's amazing how much more responsive surfing is then.
-matt
thanks!
For onlookers: The link is here.
And it doesn't say anything about copyright, just time and money (isn't it always?).
-matt
Will somebody please define what "reverse caching" is?
thanks
-matt
thanks
Tangenital topic: /. effect.
At least once per story, somebody suggests that slashdot cache or mirror sites they link to in order to avoid the dreaded
I have yet to hear an explanation of why this might not be a good idea. Anybody out there have one?
(honest question)
I can't see how copyright would not be the issue, it's pretty a pretty blatant violation when you start copying other websites content and stick it on yours.
/.ttd. You are veiwing a cached page, it may not be up to date. Click here to try and fetch the original."
I can see that argument if you surrounded their page in a frame, or replaced their banners with yours, or something which somehow makes it unclear who the real owner/producer of the page is.
How about a script or program which:
-caches the linked page when the story is first posted
-periodically checks the page for response time
-if $lag > $unbearable then serve cached page with an inserted headline which says "the host server http://blahblah appears to be
This way the big companies would host their own material (the assumption being they have enough money to have bigass servers and don't need to be cached) and only the little guy with the cool make-your-own-transmeta-chip page who actually _needs_ to get cached, will get cached.
Is there some reason this wouldn't work?
-matt
I've been introduced to Unix through Linux. I must say that the Unix environment just simply kicks ass!
:-)
Out of sheer curiousity I tried out freeBSD. Their kernel is incredible. I know that the bench marks aren't there to show it but their "claims" are true.
Their TCP/IP stack is better, loads can be handled with ease even on a extremely low-end systems and their memory management is out of this world. I was impressed at how fast my shitty unix boxes went.
Now I know that linux heads like myself would become defensive but linux has made big improvements and a lot of issues are being addressed with the next 2.4 kernel. Their "claims" will be seriously tested soon.
I have decided to go back to linux because I prefer it. There's more software and it makes a better desktop for me. Plus it is stable enough, user friendly enough, fast enough and damn good!
However, freeBSD is a great unix OS and the only way to find out is to try any BSD yourself. Even a linux head like me can defend freeBSD.
Keep up the good work to all BSD contributers
"If a show of teeth is not enough, bite
It's useful in scenarios where you have a large web server farm. By implementing reverse caching and lightening the load on your web server farm, you don't have to have quite so many web servers. It also has the net effect of making your web site appear to be "faster" since users will see the images more quickly from the cache than the web server.
Eagles may soar, but weasels don't get sucked into jet engines.
I just want to take this oppertunity to say Squid totally rocks. I put a squid server on a rescued 486/66 with 24MB of RAM. By rescued I mean that when the processor was removed from an old donated Compaq Prolinea server, it flew out of my hand and landed on concrete - then got stepped on while I was trying to find it and every pin got flattened (oops! found it!), and I had to straighten each pin with a butterknife to shove it in the Squid box! Honest! And that's only the processor story! Anyhow, you get the point - we're talking about really crappy and abused hardware I'm working with here.
:)
We have roughly 100 machines on our network, and Internet access was coming to a standstill - especially when everyone in the computer lab was on the Internet. Imagine a 128Kb/s fractional T1 with 25 *active* users all trying to look at mega-image-rich content, plus some other users on campus accessing the Internet at the same time (can you say sub-300 baud and ping times measured in whole-second increments?). I was having to pre-load web sites before a class came into the computer lab because just loading the first page could take roughly five minutes on a good day.
Then I configured and installed a Squid server on a rejuvinated Compaq Deskpro running Linux 2.2 that was donated with the above said specs. I was a little sketchy to implement it across the entire campus at first because I had always heard that proxy servers were a Bad Thing. So I silently pointed browsers to the Squid machine in a few classrooms to see if I would hear anything from anyone. I got calls from people that very day. They were asking me how I had finally coaxed our school district into buying us such a fast connection!
As it goes, the more classrooms I pointed to the proxy server, the faster things got (as the cache was growing and the hit rate was increasing), and the more happy teachers I had. In a school situation, many sites are visited multiple times by different students and classrooms. In the computer lab, every computer often visits the same site as a class. So having a caching-proxy server helps a great deal! I really believe that every school with less than a T1 should have one.
As for statistics, I have an average 'hit' rate of well over 80% because of the multiple viewings of sites. Initially I had 2GB set aside for caching purposes (on an IDE Samsung 2.1GB drive), and I found that as it reached its capacity the server just got way too slow. So first I brought it down to 1.5GB, and now I have it at 1GB (I may even take it to 750MB). It has been running pretty fast at 1GB - by far compared to not having a caching-proxy server at all, but I do see the performance start to degrade at about 750MB with my particular hardware.
Sure, faster server hardware would be *great* and is probably necessary to handle our unusually heavy load due to all of the graphics content on the visited sites, but right now that just isn't an option because we live on donations. My point is that even though we are running Squid on such a crappy box, it has worked wonders on our network. Internet access seems very fast now, whereas before it was almost unbareable. And most importantly people are happy and making use of the technology we have to its fullest extent, where as before they may not have been able to do this. I must admit though that I am writing grants in hopes of getting a faster/newer box because ours is getting tired and I worry about what will happen when the hardware finally kicks the bucket.
For a school in our situation, Squid is great because it even helps when you're using it on otherwise possibly worthless hardware, and the price is just right.
Anyways, I'd like to thank all who have donated their time on the Squid project, you've done great work and you're helping people more than you realize!
--SONET
http://www.hbcsd.k12.ca.us/peterson/technology
Any fool can criticize, condemn and complain and most fools do. --Benjamin Franklin
No, it's not absolutely neccessary, since they send IF_MOD_SINCE requests, and don't always retrieve the data, etc.
But still, it's a good matter of principle to do so, to guarantee behaviour of clients.
Also, this only extends to private caches, and public caches really like to see http/1.1 headers before holding on to them (again, depends on the exact cache obviously)
For those of you interested in caching and how it can help large scale sites, I've helped co-author a technical report with Network Appliance, which was our experiences at accelerating the Mars Polar Lander website. That site used NetCache boxes, simple HTTP/1.1 cache-control headers, and a bit of cunningness to allow user-level tracking without letting the track requests filter through. As traditional, the site had a couple of problems which we've also included in the appendix after we fixed them, to hopefully save other people the same hassles in the future.
:-)
The technical report can be found at http://www.netapp.com/tech_library/307 1.html
We would all save a scary amount of bandwidth if more sites were designed with public caches such as (the awesome) squid in mind, and it's a really simple use of headers that make it possible.
For those who use Apache and are interested in making your own sites more cache-friendly, I recommend you look at mod_expires, which is part of the default distribution of Apache, although not compiled in by default. If you have large, static images that rarely change, then go ahead and put week-month-year long expiry headers on them, and watch the hits for those redundant images drop right down on your web server. And if you suddenly need to change them, then it's no real problem, as all you have to do is change the images URL and it will become a "new" entity for purposes of caching.
Yeah, granted, bandwidth is getting cheaper now, but for us poor Europeans, it's still a scarce commodity and we need to worry about these things
-anil-
What difference will khttpd make to caching software and the need to use caches?
> Tangenital
/. mirrors the info, are they going to mirror the banner ads as well?
ick
To answer your question, there are two main reasons why this shouldn't be done.
1: Copyright could be infringed on the pages being cached
2: Many sites get their revenue from click throughs and banner ads. If
dave
bout that "killer caching proxy"... umm, with all that bandwidth, why would you need proxying anyway?
by that time you're probably a backbone provider and don't need to worry about stuff like that. Caches are used by
ISPs with a T1 or two or corporations to limit bandwidth.. not by super-sized ISPs
Uhm... you're kidding, right?
Did you ever think about how much of that bandwith your high speed clients (DSL, cable modem) can eat up? And how much of it is redundant? (i.e. cacheable)
--- Where's my X.400 protocol decoder?
Squid captured top honors in cache hit ratios, but nothing else (AFAICT), showing that those "expensive, proprietary systems" also can be very
well-tuned operating systems that eliminate traditional OS overhead for these numbers.
True, but the operating system that Squid was running on (and that's what you were talking about, the operating systems) was FreeBSD, which also runs the iMimic, which captured the highest hits/sec and reqs/sec per $1000. By a large margin. Interestingly enough, the only linux-based entry, the Swell-1000, didn't do very well. Which goes to show you that just because you have a good starting point, doesn't guarantee success.
And, of course, the amazingly expensive Cisco products probably (I don't know, just assuming) do a lot more than just cache -- and are probably a lot more reliable (MTBF) and redundant, which is important if your cache is a vital business component. (And if cache == internet access, then, well, it probably is).
--- Where's my X.400 protocol decoder?
Expanding a vast wasteland since 1996.
Rob has a response to this in the FAQ.
Spencer Ogden
A connection is destined for "www.excitestores.com", and ends up at the external DS/3 (T3, T1, insert your fast link here) port on our router. The router runs a rule against the packet and says "Hey, this is www traffic bound for the servers that are to be accelerated. Therefore my next hop is (insert IP address of cache here)!". It route-maps it to the cache server as it's next hop. The caching server is set up to "hijack" any incoming connections as if they are destined for itself, and makes the request to the origin web server on behalf of the requesting client. At this point, this does not differ too much from standard forward transparent proxying, except that you normally have an access control list that only permits transparent proxying of a limited set of URL's or IP addresses. You don't want to run an "open proxy" for the world to use to cache whatever they want.
Of course, note here that there are alternate methods of accelerating sites depending on the cache you choose and your infrastructure. The basic idea is to get the packets to your cache instead of the web server, however you choose to do it. Common methods include placing the cache in the natural route of the packets, making the webserver address point to the cache and have a non-public DNS that the cache looks to to resolve a web site on a non-routeable private network, or specifying on the cache that incoming connections on a certain IP are to accelerate a particular origin server.
Anyway, the benefits of this are enormous in our case. We have a (*&$load of modules compiled into our Apache server, tons of virtual hosts and modules to handle them all, and each daemon runs about 12 MB. Each web server has a gigabyte of RAM, therefore you do the math:
1024/12=85 and 1/3 connections run us out of physical RAM on each web server. Realize this is a rough estimate; our web servers can handle much more, but performance degrades quickly with more connections being served from virtual memory. I've also not taken into account OS overhead, other services running on the servers, and any other thing you may think of. However, modem users, particularly, saturate web server connections because it is so slow to deliver objects to them.
CNN.com, for instance, uses ICS caching boxes purely for connection management to handle these slower connections that could bog their servers down. Novell's ICS is rated at over 100,000 simultaneous connections on each box in reverse proxy mode. A big difference from 85 connections for one machine, no?
I'd love to discuss this in more depth, if you require a better answer. Better yet, check the FAQ at Squid's site regarding transparent reverse proxying.
Seriously, this is what takes web sites to the next level, regardless of whether you use Squid, ICS, NetCache, or another type of reverse cache. Keep smiling!
Matthew P. Barnson
I learn what I think when I read what I write
I've been overseeing a caching (really, website acceleration project) for my company, Excite@Home E-Business Services, over the last three months now. I can personally say that the three I've had experience with, Novell's ICS caches (which comprised ten of the twenty entrants), Network Appliance's NetCache, and Squid (on Solaris, in our case) all rock. Squid 2.3-stable1 was a dream to compile, install, and configure. ICS has a few user interface quirks with their Java administration tool that I don't like, but except for Cisco's cache (Oh My Gosh do you really want to spend $150,000 on a CACHE???) ICS-based systems captured the many top honors in this roundup. Network Appliance's NetCache is also a nice choice, and as the only vendor with streaming media caching/splitting support, they are receiving a lot of attention recently.
It's really important to note that IRCache has no desire to point to any "winner" in this bakeoff, but instead to have real non-partisan numbers to point to when evaluating cache performance. Squid captured top honors in cache hit ratios, but nothing else (AFAICT), showing that those "expensive, proprietary systems" also can be very well-tuned operating systems that eliminate traditional OS overhead for these numbers.
One of the frequently overlooked uses of cache is as a web site accelerator, instead of the standard forward proxy. Using a few simple access control lists and a policy on a router, reverse-proxy caches managed to reduce the instantaneous load on our web servers by up to 94%. We serve about 3.5 million hits a day. A "reverse proxy" is an EXCELLENT use of a proxy cache, and after these technology evaluations I've been involved with in past weeks I'd recommend it to anybody considering running a high-traffic website. This allows your Apache servers to function more as the "cgi engine" of your site, and lets the static images, text, banners, etc. be delivered from a box that can handle 100,000 simultaneous connections. Very cool.
While I'm not allowed to post a "review" of any one of these units, because of various agreements for the evaluation boxes we tested, I can clearly state that Squid, NetCache, and ICS-based systems can and will vastly reduce infrastructure scalability costs for businesses when deployed in a reverse-proxy configuration. Our earlier estimates guessed we'd need to expand our web farm three times to handle our estimated load by the end of the year. Now we can reliably predict that our farm can serve 10 times the amount of hits we're running now by using a cache as an accelerator. VERY cool stuff.
Be sure and check out the system configurations in the bakeoff review. It's very illustrative that the boxes tested have VERY specific audiences. Don't be fooled by the "fastest hit response time" or "most throughput" -- you can spend $6,000 or $150,000 for any setup, depending on your needs.
Noticeably absent from the review was Inktomi, for the second year in a row. I'm hearing FUD from vendors that their performance isn't up to snuff-- any truth to these rumors?
Matthew P. Barnson
I learn what I think when I read what I write
Actually, ICS's cache engine has little to do with BorderManager's, and BM's is still available as part of BorderManager.
ICS is designed for people who don't know NetWare--it's a NetWare kernel with the ICS stuff on top of it. Say what you want about the NetWare file system, it's pretty fast when tuned for stuff like this.
-- Of course I'm paranoid. I'm a sysadmin.
Actually, google has been switching over many of its boxen from Linux to FreeBSD._ id=562)
On a side note, Google is going the whole nine yards embracing BSD- they are considering setting up a BSD-specific search engine, not unlike their current linux engine. (I've talked to a guy from google about this, more at http://daily.daemonnews.org/view_story.php3?story
So, they aren't really a linux or a FreeBSD camp. Currently, they are both.
-bugg
Hence, making khttpd a non static web server would be a very foolish thing to do, and would mangle system stability.
Static web serving is not problem (once you debug the code).
Fixing copyright
Have a look at the man page for the FreeBSD mount command and say that (search for async while there). For those occasions when you don't mind flying by the seat of your pants, you can of course have async writes. It isn't a new option either. And there's always softupdates too.
I suppose it wouldn't be so easy to win arguments if people actually checked their assumptions...
Novell's ICS did pretty damn well! I still remember when ICS was part of BorderManager. It showed very good potential, and incredibly flexible. You can't find such a configurable caching solution anywhere!
Now, I believe ICS has stripped down conffigurability, but upped the performane.
Good job, Novell!
Sigged!
If I remember correctly, shortly after Andover's IPO Malda noted a few reasons why they don't do it. Granted I don't remember all of them but one was over copyright concerns. Copying content off of other sites can get ugly I figure, especially when they find out you have a big company with come cash behind you like VA I would think.
Malda used it as one of his reasons for not doing it back when he was answering such questions. I can't see how copyright would not be the issue, it's pretty a pretty blatant violation when you start copying other websites content and stick it on yours.
:-)
Just because Google hasn't been sued doesn't mean copyright is not the issue, although it would be interesting to see someone try that one in court
"Well how can I be at fault? Nobody has sued Google yet!?"
Why is it moderated Downward?
If someone posted:
Microsoft rules over Linux.
or perhaps
FreeBSD rules over Linux.
Would you consider that a 'dissenting opinion and the truth'.
If you care about shipping and buyable voice to text systems, then yes M$ rules over Linux.
If you think the GPL licence is a bad licence, and the BSD licence is better, then yes, FreeBSD is the OpenSource ruler over Linux.
In the case of these 2 examples, Linux is the loser.
Rather than spending your time whining about moderation, why don't you spend your time writing some code, or at least work on extracting you head from your ass.
If it was said on slashdot, it MUST be true!
I wonder if NetBSD with its LFS instead of FFS for cache directories can boost up the results (LFS does faster writes).
I always wanted to give LFS a try on our production webcache (squid as well) since I've read some documents about it---too bad that LFS isn't matured enough yet in -current and hence probably won't be in 1.5 either:-(
> I do not use BSD. Ever.
...
Too bad that you are already using BSD without
knowing it:
1. Parts of BSD are built into nearly every other OS witch supports the internet protocols: Windows, Linux, Solaris, BeOS...
The "Sockets" interface to network protocols that all those OSes offer is a BSD-developement
2. Many, many Routers run on BSD derived systems
3. Many Nameservers run on BSD systems, the Berkeley Internet Name Daemon aka BIND has spun of BSD.
4. Some of the pr0n-server you've visited yesterday run on BSD
5.
It's absolutely impossible to use the internet without using BSD.
It's absolutely no problem to use the internet without touching Microsoft or Linux.
The same comment posted twice gets
a) +1 Insightfull
b) -1 Troll
ROFLMAOPIMPTIME
Hey, trollking, a little tip for you how to
get a "+5, Informative:"
Next time try:
"I would just like to voice my support for Linux. It is the best OS ever, in my humle opinion."
I've downloaded the page (www.freebsd.org) wich google gave me as 4th and:
:-)
% grep -i "who\|rules\|world" index.html|wc -l
0
Then I've downloaded the cached page from google as well:
% grep -i "who\|rules\|world" cache.html |wc
0
OK, "who" is ignored, says google. But that page doesn't contain *any* of the search keys except "the".
I don't understand it, why does google give such bogus results?
(AFAIK Google is linux powerd so this can't be a FreeBSD conspiracy
Actually, I chose OpenBSD over FreeBSD (or any other OS), for the same reason I chose the 2940UW over another SCSI chipset-
It may not be the latest and greatest cool technology, it may not be the fastest, but I know, from personal experience, that I can rely on it.
The drives and controllers are relatively inexpensive, so I can afford to keep spares on hand, and when the current solution becomes overloaded I can easily scale it up.
More detail on this in the message 'Distributed proxies' elsewhere in the thread.
I do not deploy Linux. Ever.
When I spec'd it out, all the techies I talked to asked me three questions, this article validates my answers to all three-
My answer to each was two parts:
Semi-Off-Topic
What do I mean by a 'Killer caching proxy'?
A pair of identical (load balancing and transparent failover via BigIP) rackmount servers, each with a PIII 600 CPU, 256MB, 2940UW and 20Gb of disk. And let's not forget the triply-redundant T3's to threee distinct Tier-1 internet providers.
All this just so I can read slashdot.
I do not deploy Linux. Ever.
I've done a lot of work with 'proxy.pac' files in the last year- it's amazing how much decision-making power you can put into the autoproxy script, letting the client machine take on some of the responsibilities of smart proxying.
For example, right now I have two distinct sites with their own Squid proxies, users at both sites use identical 'proxy.pac' files. The browser decides whether to go direct or via a proxy based on the host/domain of the destination, then chooses a proxy based on it's own source IP address.
This means that every Netscape and IE browser in the enterpise has the same configuration, and even roaming users will always get their closest proxy server each time they connect.
If a business unit later gets their own internet firewall and proxy, it takes a line or two in the global script, and clients automagically use the new proxy.
You can also specify multiple proxies in the file- if the first one times out, all future requests (until the browser is restarted) will go to the next server in the list.
Now if only Lynx would parse the (javascript) proxy.pac file...
I do not deploy Linux. Ever.
Thank you
Installed the Bubblemon yet?
To find the below average vendors you'll need to look to the folks who didn't show up this time.
While I have an obvious interest in promoting the Swell entry (which did quite well...but not as well as we expected due to some unresolved bugs), I spent a lot of time talking to the other vendors techs. There were some very smart people pushing very good products at this bake-off. I wouldn't hesitate to recommend (for customers that need more than our boxes provide and can spend the extra dough, of course) many of the products tested.
I know it sounds rather flowery to say that "All the girls in the pageant were very pretty", but in this case, I think the bake-offs are really separating the chafe from the wheat. Look at previous bakeoff numbers and prices and compare to this time around. Keeping in mind that this bake-offs workload was MUCH harder than previous workloads (the Polymix-1 or Datacomm-1 workloads found in previous comparisons), even so the price performance has improved markedly from all vendors. And the price/performance also-rans from previous events just didn't show up this time.
That's why the polygraph guys deserve such praise. They allow cache users to really know what they are buying. And the companies that don't show up or don't provide a good value just won't sell as many boxes. (And I strongly recommend against buying an untested cache product...there are some real stinkers out there and you don't always get what you pay for.)
You should further look a little deeper into the results. Microbits box was only caching about 44% of web traffic and getting rather slow response times. So while they got 120 reqs/sec, no sysadmin in their right mind would push that box that hard. To compare apples to apples with the Squid entry or the Swell entry (both had nearly ideal cacheability and excellent response times) you should think of the Microbits box as being more along the lines of 95 or 100 reqs/sec.
To see Squid results in more favorable light, check out the more recent results on the Swell web page:
http://www.swelltech.com
Our test box at the bake off was having fits using async io...so we disabled it in order to get a clean run. However, performance suffers markedly without it. Those async issues have been resolved...Our boxes are running in our labs at 110 reqs/sec right now (we have a 100 reqs/sec run benchmark online...you can note that response of squid is still excellent at that load).
Anyway, given the proper tweaks, Squid can really scream on a low priced box. (Our $2139 unit is the one included in the bakeoff and our more recent benchmarks.)
Squid showed perfect cacheability (why buy a cache except to cache?), whereas some others in it's price range (except the Swell box also running squid) displayed much lower cacheability. Response times from a lot of boxes were not so good either, while squid's was excellent (the other reason to cache...browsing speed). When you see a box with long response times and low cache hit rate, you are looking at a box that was being pushed WAY too hard. You would not run a cache with 30 or 40% DHR and mean response times of 2 seconds...ideally, you run it such that cacheability is near perfect and response times are very very fast. Squid did that. Microbits didn't.
The Squid team have done a great job with Squid, and it gets better every time around. Even compared to the ICS products (many of which are very very fast these days...but you pay the price for them...ICS on low end boxes suffers a bit), Squid didn't do so bad at all.
Anyway, if you'd like to see some more Squid numbers, we've got a $2139 squid box in the lab doing 110 reqs/sec from dual IDE drives, whereas the Squid team got 160 from a $4k box with 6 SCSI 10k drives. We will be posting pretty specific specs for it sometime in the future so that others who want to roll their own can do so (it takes a lot of work). Some of our recent benchmarks (using Bake-off rules and benches) are posted on the Swell Technology web page. Currently, the posted benches are for a run at 100 reqs/sec. The 110 run will be posted sometime soon.
Those interested in caching should check out the squid devel list lately. Discussion has centered on a couple of new filesystem ideas that should improve squid performance markedly. Fascinating stuff. I suspect the ICS guys will be a little more worried come next bake-off.
...that should not be aloud out much less be aloud access to a computer. Some pure flame bait here so far -1. I've been using the Penguin since Pre 1.0 and also use freeBSD as well. It's good and solid. Like any other, the big sites that use it would'nt if it were any way other.
Give me a break I am still working the bugs out of my voice command port. Though it will not be released to "Anonymous Cowards"
We found that squid did remarqably well on a HP LPR with dual 550's and half a gig of ram. It was our number 2 preformer. Number one was a Vendor know as Cacheflow.
Now why was this on-topic reply moderated down?
* Use a preprocessor like PHP instead of basing everything on CGI
* Don't use Apache unless you really need to. Smaller servers like thttpd or BOA will often supply everything you need, are much more lightweight and much faster
* Use a web accelerator like Squid
* If you *must* use CGI, see if you can't implement it with something like fast-cgi. Especially with Perl!
And of course, I'm sitting here posting on a web site that hasn't implemented any of the four. Slash's code is absolutely frightening -- all the scripts use the same humongous module (Slash.pm) which use DBI and *gulp* Date::Manip. And you wonder why the site gets slow!
I/O Error G-17: Aborting Installation
yummy... squid is really good fried, as long as you don't dry it out. Marinating them works OK sometimes, but here's a tip- don't use soy sauce. It's mostly salt, and remember what happened when you salted slugs as a child? As for deamons, I think they would be too stringy to really serve as a good entre, but they might make a good shishkabob, you could use it's little pitchfork thingy.
Make Seven
Username taken, please choose another one.
What is your opinion on caching vs. Akamai? It would appear that it properly implemented, Akamai-style services can make all of this caching infrastructure obsolete.
There is no such operating system called 'FREE Bsd', unless I am very much pisstaken.
Jeff
stty erase ^H
I do a lot of consulting work in the area and put in such a "solution" (god that word is overrated/overused) for a small local ISP. They insisted on BSD/OS (all of their other machines were BSD/OS except one SCO OpenServer box; familiarity I guess) so I decided to give Squid a shot. I must say it worked and is still working quite nicely for them. I generally find BSD/OS to be roughly equivalent of FreeBSD give and take on certain things. I even configured it to work with MRTG to deliver stats. Look for a package called "mrtg-for-squid." It's pretty damn cool.
Because of copyright issues I'd assume. A lot of companies (quite understandably) like to have control over whatever has their logo.
I would just like to voice my support for FreeBSD. It is the best OS ever, in my humle opinion.
Thank You,
Troll King
Thank You,
Troll King
Subscribe
result 4
Thank You,
Troll King
Thank You,
Troll King
Subscribe
If copyright and banners were the issue, why hasn't anyone griped about Google's wholesale caching of the entire web practically?
No sig is worth reading.
Way too many times the open source software is dismissed as sort of a dull knife -- it gets the job done, but doesn't do it in an elegant or efficient way. Take apache for example, how many people rag on apache because of it's focus on compatibility vs its speed?
For Squid, I can't honestly think of a better overall proxy software. If www.proxymate.com can handle the massive amount of traffic it does running Squid on Linux, all but the most stump headed ignoramuses would realize that business needn't drop a couple thousand $$ on a specialized platform.
No sig is worth reading.
The WebStone benchmark tests were originally developed by Silicon Graphics to measure the performance of Web server software and hardware products. WebStone 2.0.1 is a more portable version of the original WebStone benchmark which added support to use Windows NT systems as client test systems.