Igor Khasilev wrote: > 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.
Not the /only/ way, but certainly a good one. TUX (the in-kernel webserver from Red Hat) utilizes one thread per processor. Works beautifully, without the overhead of thread-per-connection. But state machines can be more difficult to code in some cases. >>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. Interesting. I will give the new version a go, in this case. > 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. Solaris would be merely an academic exercise for me, which is something I don't have the luxury of pursuing these days. My options are Linux or FreeBSD (and FreeBSD has serious drawbacks for most of my needs). This is because we are a hardware vendor--shipping Sun boxes is not an option (and x86 Solaris will soon be end-of-lifed). However, I do have the luxury of using my own Linux kernel variant, and the knowledge needed to make just about any stable or beta patch in existence work well enough for my needs. So I can experiment with various threading implementations, and anything else needed to make things go. >>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. Cool. I'll look into it. If it has crasher bugs as you mentioned in a previous message, I'll have to keep it on the back burner as an interesting but not-usable project. As you may know, my caching servers go out to clients at ISPs and other high-load, always-on, environments. Crashing software just won't do--I'd never get any sleep! ;-) >>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? For a total switch for all of my users (which isn't likely at all), I would need all of the following: Performance and stability to match Squid. I'll test to see if the new version matches up more closely. auth helpers (LDAP is necessary). Accelerator features as found in Henrik's rproxy patches. This allows multiple backend origin servers to be configured, much like cache_peers, which allows for high availability and load balancing and other fun stuff. Site compatibility to match Squid. I don't have enough data about Oops to know if it has any serious compatibility issues, but I know Squid is one of the most compatible proxies available. And probably a couple of other things I can't think of right now. I would also have to write all new maintenence tools--we have an entire suite of GUI components to make managing a Squid server easy and fun. Those would have to be rewritten mostly from scratch, because Oops is a very different animal. To convert our ISP clients (not accelerator and enterprise clients) we would only need solid transparent operation, WCCP (you've already got it--better than Squid probably), and performance to match or beat Squid on equal hardware (some of which is extremely large hardware--so Oops will have to scale pretty effectively to larger hardware are more disks). >>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. You say you 'started' to rewrite Oops. So does that mean you're maintaining two source trees? One rewrite and one old codebase...or have you converted the whole release version to a rewritten codebase? I have followed Oops development for about two years, but not very closely--just keeping an eye on how it is progressing. -- 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/
