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/
