Igor Khasilev wrote: > 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.
True (though poll can be quite portable at least across Unices). But nonetheless, I wasn't really arguing strongly against using threads. It is a valid choice for a proxy cache, and if it allows you to work more efficiently and produce more reliable code, then it is worth the tradeoffs. >>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. This is certainly true. But the kernel and glibc are /generally/ pretty slowly moving targets. Not quite as bad as it might seem on the surface. One can know how a given 2.4.x kernel will behave under some circumstances, with regard to threads, and how glibc 2.2 will behave (which might, admittedly be different than 2.0). The good news is that thread support only gets better in Linux. So if something is a problem today, it might not be two weeks from now. >>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.. A Squid-style auth interface module would also solve this, I think--we could just use all of the Squid auth modules. ;-) Would it be possible to add a module to talk to Squid-style redirectors as well (or is this already possible?)? I'm not asking you to code it, just asking if it would be reasonably possible? >>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. No, I've never used the accel features of Oops. But I'm happy to hear you have cool features like that. Will check them out when I get some free time. >>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? Depends on the client. Most are Internet Service Provides. The biggest hardware we have in service is a dual PIII with 2GB of RAM and 3 15k RPM disks serving 230 requests per second at peak loads and 180 during average load periods. It has about 40GB of cache object storage. Some are much smaller, but the average is a single PIII with two or three 10k RPM disks pushing 100-150 requests per second at peak. >>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. Oh, ok. How far out is the new codebase from being 'stable'? Would you mind explaining briefly some of the design changes you've made since the current Oops codebase was implemented?-- 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/
