On Fri, 8 Mar 2002, Joe Cooper wrote: > 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
It's pity. Multithreading is only real way to use several processors on the host. > 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? If CPU is not a bottleneck then most probably disk I/O with storages (and next with DB) is the problem. Since 1.5.18 there were significant improvements in storage I/O area. In test environment (under polygraph) due to aligned read/write to raw partition, speed of document swapout increased near 5 times. There was also some changes in swapout/dropout algorythms which allow keep memory usage under more constant control. Again, to avois OS-specific performance problem you should try it under solaris. > > 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 I never seen that gigabase become bottleneck, storage io become first. > 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 Thanks for your words :) > 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 Which features? > 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. ;-) I can understend them :). I also started to rewrite oops half year ago, when I clear see what was wrong from the start. Igor Khasilev | PACO Links, igor at paco dot net | ===================================================================== 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/
