Igor Khasilev wrote: > On Mon, 11 Mar 2002, Joe Cooper wrote: > > >>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?)? >> > > You can't talk to external redirector from oops. But it have internal > reirector with regex or fast substring matching.
My reason for the redirector thing, is that I'd like to be able to use our SquidGuard-based blocking system with Oops. Would it be simpler to integrate the SquidGuard DB (a BerkeleyDB) directly into an Oops redirector module? I.e. would it be feasible to have an Oops redirector that can act on a BerkeleyDB blacklist or set of blacklists? Again, I'm not suggesting you should code it, at the expense of your other work...just wanting to know if it is a reasonably simple task. >>>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. >> > > I never test oops in real life under such load... I will in the next couple of weeks. Not real world tests, but pretty accurate Polygraph benchmarks. >>Oh, ok. How far out is the new codebase from being 'stable'? >> > > As far as possible. It can accept request, parse it, connect to origin > server. That is all. But it contain set of objects and libraries which > moves to needed functionality. Cool. Sounds very interesting, I'll look forward to seeing the new version. >>Would you mind explaining briefly some of the design changes you've made >>since the current Oops codebase was implemented?-- >> > > 1. thread pool instead of thread-per-connect (threaded reactor pattern) > this is main goal of rewrite. It will allow use less threads, and > probably increase performance. Very nice idea. Have you had a look at the SEDA project? It is an interesting concept for handling high loads which uses both threads and an event driven model. http://www.cs.berkeley.edu/~mdw/proj/seda/ It's all Java stuff, but the design ideas would apply to any Object Oriented language. I found it to be a really interesting read, anyway. > 2. more memory control. This is second main goal. > > 3. safe string operations. Necessary. > 4. probably some special db. Interesting. You're thinking of moving away from Berkeley/Giga DB? Probably wise, but a lot of work. I like the idea of COSS (cyclical object store) for raw write speed, or a hashed directory structure with pre-grouped writes for locality (i.e. you have memory buckets into which you dump the requests with a locality aware hash--then write them out to disk in a group so that related objects will remain very close on disk). COSS probably provides the highest throughput, while a locality aware hash with bundled writes would provide the best seek time (and thus fast response time). I think overall COSS is the most efficient, but the most complex to implement. The locality aware hash idea requires a lot of memory to function effectively, and in the real world probably isn't much faster than a DB style interface. > 5. C++ instead of C if it will worth. I would say that nothing should be started from scratch in C today. The benefits of C++ are quite well-known at this point, and the negatives of C are as well. Performance shouldn't be a major concern, and the GCC compiler is quite capable of compiling C++ into reliable binaries. The STL and other existing libraries also eases some of the burden... > 6. Configurator which will allow change single config option at run time. Very nice idea. Certainly worth a little extra effort. I'll look forward to trying out the new code (eventually). -- 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/
