ok. 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 2:27 PM Subject: Re: [OOPS] increasing the number of threads on linux > 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/ > ===================================================================== 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/
