On Mon, 11 Mar 2002, Joe Cooper wrote: > 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.
Yes, possible, but difficult, restricted and non-portable way. > > 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. This was under solaris, I never tried this with Linux. > 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. The main problem with Linux is that there is no such thing as Linux: we have lot of distributions which have several major and minor versions of kernel plus several major and minor versions of glibc/linuxthreads. Thread behaviour differ from one setup to another, it is very difficult each time to find where is the problem. > 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! ;-) Absolutely right! > 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). I see.. > > 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. Did you check the options for the accel module for oops? it have these things already and some other useful features. > on equal hardware (some of which is extremely large hardware--so Oops > will have to scale pretty effectively to larger hardware are more disks). It is interesting, what is average hardware setup (and load) for your clients? > You say you 'started' to rewrite Oops. So does that mean you're > maintaining two source trees? One rewrite and one old codebase...or yes, exactly. What I wrote several letters ago was related to new code, not old. I'm supporting old code and write new one. 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/
