I've benchmarked it on both Linux and FreeBSD. I have very little knowledge of FreeBSD, however, so it may not have been properly tuned (I followed Squid and Polygraph tuning instructions, which I think should be suitable for Oops as well).
I found them to perform very similarly. Not enough performance difference to consider significant. And as I've said before, Oops is great at low loads client numbers, but when scaling up to much higher request rates (anything over about 70 on my test hardware) it falls over. Same hardware sustains 90-110 running Squid depending on Squid version (2.2STABLE5 being the fastest, with 2.4 and 2.5 being somewhat close...2.3 is the slowest). The hardware is an old 850 model of our Tsunami line...450MHz K6-2, 256 or 512 MB of RAM (have tested with both along the way) and two 7200 RPM IDE disks. Edward Millington wrote: > All of this do sound good. > > Joe! When you ran oops, was it on linux? > > What was the machine config? > > did you see the thread hit 1000? > > Thank you very much. > > Best regards, > > Edward Millington. BSc, Network+ > Systems Administrator > Cariaccess Communications Ltd. > Palm Plaza > Wildey > St. Michael > Barbados > 1-246-430-7435 > Fax : 1-246-431-0170 > [EMAIL PROTECTED] > www.cariaccess.com > ----- Original Message ----- > From: "Joe Cooper" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, March 08, 2002 1:37 PM > Subject: Re: [OOPS] increasing the number of threads on linux > > > >>Igor Khasilev wrote: >> >>>On Fri, 8 Mar 2002, Joe Cooper wrote: >>> >>> >>> >>>>you need. You may still see performance problems...that many threads >>>>will have a huge overhead on any OS (Linux moreso than some, less than >>>>most). >>>> >>>> >>>This is true. Thread-per-connect was one of decisions under the question >>>from the start. But at that time I thought that OS and thread library is >>>right place to fix performance problems with large number of thread. And >>>moreover I was urgently need something to replace squid at that time (at >>>1999). So, solution was to create as simple code as possible, to be able >>>write and maintain it easily. >>> >> >>You're probably right about this. In many cases the benefits of threads >>outweigh the performance troubles--and Oops does a fine job keeping up >>with Squid up to a point and uses less resources to do it, generally. >>And achieving the absolute pinnacle of performance doesn't usually need >>to be the most important factor when designing any software. But then, >>threads also introduce a lot of their own problems that make debugging >>and maintaining the code more difficult. The fact that many Unix and >>Linux developers don't /like/ threads and so don't spend much effort >>making them work really well is also a problem. So it's a hard >>call--but you seem to have done a nice job. >> >> >>>Need to say that I start to write absolutely new code from the scratch. >>> > I > >>>hope I'll fix all architectiral bugs sometime. >>> >>>The first fixes in the list: >>> >>>1) Multithreaded reactor pattern to handle requests - it is written and >>> seems it run. >>>2) safe string operation (also seems completed) >>>3) more memory control (memory pool) - seems completed but lack some >>> ideas on how to handle memory shortage. >>>4) C++ instead of C (if this decision will not conflict with >>> > performance) > >>>5) special db code to handle specific requrements (BerkeleyDB is good >>> > but > >>> it have several problems which is out of my control, GigaBASE is >>> > fast, > >>> but can SIGSEGV sometimes). >>> >> >>I did some benchmarking of Oops 2.2.18 and some 2.2.x version after >>2.2.18 (it was one of the experimental tarballs). I found it to perform >>extremely well at low request rates and client loads, but found >>performance topped out at 70 reqs/sec from hardware that could sustain >>about 110 from Squid. Because CPU wasn't a bottleneck, and I had plenty >>of memory, I had to assume the biggest problem was disk I/O contention >>with the BerkelyDB. So GigaBASE addresses this problem, somewhat? >> >>I'm not convinced that a DB style backend can provide a satisfactory >>performance level with multiple disks...but perhaps I'm wrong. It is >>certainly easier to program than a standalone FS or FS layer that >>efficiently uses the system FS. COSS for Squid has been in development >>for years with no stable product in sight. ;-) >> >> >>>Ideas that proved to be right are: >>> >>>1) threaded code >>>2) two-level cache >>>3) single-file storage with ability to work with raw storages >>>4) modular design + several hooks where modules can change request and >>> > reply > >> >>I'm quite impressed with Oops. (That's why I'm on the list and have >>done quite a bit of testing with it! ;-) I do like the overall design >>(with the caveat that I don't really know that threaded programming is >>the Right Way). It's quite likely that as it develops into something as >>solid as Squid, and has the primary features that my clients need I will >>begin to support it alongside Squid. >> >>And for what it's worth, I think the idea of starting from scratch >>rather than patching Squid was probably a good one. Even the Squid >>developers seem to be leaning towards a near total rewrite for version 3 >>of Squid. ;-) >>-- >>Joe Cooper <[EMAIL PROTECTED]> >>http://www.swelltech.com >>Web Caching Appliances and Support >> >>===================================================================== >>If you would like to unsubscribe from this list send message to >>[EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. >>Archive is accessible on http://lists.paco.net/oops-eng/ >> >> > > > ===================================================================== > If you would like to unsubscribe from this list send message to > [EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. > Archive is accessible on http://lists.paco.net/oops-eng/ > > > -- Joe Cooper <[EMAIL PROTECTED]> http://www.swelltech.com Web Caching Appliances and Support ===================================================================== If you would like to unsubscribe from this list send message to [EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. Archive is accessible on http://lists.paco.net/oops-eng/
