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."
I hope this is a troll. Just in case it isn't, let's think good and hard about what khttpd does: it's an ultra-fast web server for static content served from the filesystem. It's not a caching product, and never will/can be. It's also marked EXPERIMENTAL and almost certainly will be for 2.4 as well. khttpd is a marginally cool idea (hmmm..whoa, look what I can do!!!) that very few people will be using any time soon. And it certainly won't be for caching.
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
-----
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..
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
Novell's BorderManager? Dunno.
Novell's Internet Caching System? See the Vendor Comments page on the bakeoff site, where somebody from Dell says:
There were other boxes running it as well, e.g. at least some, perhaps all, of the IBM boxes.
(The "Vendor Comments" section seems to be filled primarily with "Vendor Advertisements"; yes, my employer, NetApp, proudly participated in the marketoonery in question.)
"The marketoonery in question" being the dumping of advertisements into the "comments" section, not Polygraph itself. Marketoons - can't live with them, can't send them out the airlock without a suit....
Or, rather, for FreeBSD plus whatever caching code iMimic runs atop it.
The CTO of Akamai is Daniel Lewin; his bio page at Akamai says nothing about Squid.
You may, perhaps, be thinking of Peter Danzig, who is the VP of Technology at Akamai; his bio page at Akamai says:
I think the Squid project was originally derived from the Harvest cache; the NetApp NetCache software was also originally Harvest-derived, although much, perhaps most, of it was done at Internet Middleware (a company founded by Peter and bought by NetApp) and NetApp. (I suspect much of Squid might also be non-Harvest code.)
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
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?
You don't _have to_ use it. You can compile your kernel w/o it, and it won't change. With NT you don't have the choice...
Szo
Red Leader Standing By!
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
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-
> 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?
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
Let me clarify.
Somehow, a moderator decided that:
"Nothing is a problem once you debug the code."
A true, if somewhat tongue in cheek comment, is being a troll, but:
"Go work on your games or something."
ISN'T!
This reminds me of a chemistry class I once took.
"Nothing is a problem once you've got the balanced reaction equation."
"Go read a book or something."
Why do the moderators (or perhaps this one moderator) sanction trolling behaviour, and dump on a genuine statement?
See you all metamoderating...
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
ICS (as I said in another post) used to be integral part of BorderManager. Novell decided to strip off the admirable manageability of BorderManager, but improved the performance, and that's ICS. Of course, BorderManager had much more features, and it's still sold separately, but ICS is sold to VARs like IBM and Compaq.
Look at the performance the Comaq box is sporting! It's purely amazing!! Obviously, Compaq's many years of cooperation with Novell, and the many NetWare drivers they have developed, helped them for the ICS appliance, too. Let me remind you that ICS actually runs on NetWare (but without NDS).
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!?"
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?
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.
> Static web serving is not problem (once you debug the code).
Nothing is a problem once you debug the code.
John Carmack
* 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.
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.