On Tue, Apr 18, 2006 at 08:46:39AM +0100, John Buckman wrote: > Is it possible to build AOLServer in a single-threaded, lock-free > manner?
I would be really, truly astonished if any such change was even vaguely possible without lots of very serious, hard-core hacking. My guess is the only remotely plausible way, short of redesigning and reimplementing everything from scratch, would be to convert AOLserver from multi-threaded to multi-process with System V shared memory, and perhaps write an emulation layer for the POSIX Threads APIs on top of that. But perhaps those folks who actually know will chime in, as I'm just speculating after all. But I'm *Pretty Sure* that this is not something you want to even contemplate when your real goal is just to get BerkelyDB working inside AOLserver. :) > Because BerkeleyDB's tcl interface isn't thread safe, I'm running > aolserver in single-thread mode, with In what way is it not thread safe? Depending on just what the problem is, you may able to make it thread safe (at least for your use cases) with only a modest amount of work. (Or if you're unlucky, it could be a LOT of work, it all depends.) Incidentally, I know next nothing about BerkelyDB, but why are you using it in the first place? Are you forced to because some 3rd party library you need to use uses it? Or are you free to use something else instead which is already thread-safe, like SQLite? > ns_param maxthreads 1 > > ApacheBench shows me getting 440 page requests per second, on an ADP > page that does a database find and read operation, which is really > fast still, even when I set concurrency at 10 with ApacheBench. 440 hits/s to this one single ADP page isn't fast enough for you? Just what is this page doing, such that you need it to go faster? > But, since I'm running in single-threaded mode, is it possible to > disable thread-safety locking in AOLServer, to further speed things up? > > If it isn't today, I could simple #define > Ns_MutexLock > Ns_MutexUnlock > > as no-ops and that should do it. What makes you think that would make any appreciable speed difference? Have you profiled your AOLserver process to see where the time is actually being spent? Since you are certain you have no contention for the lock anyway, Ns_MutexLock should be vastly faster than any database operation that has to go to disk. Probably still lots faster even if the db file is cached in memory (although I'd want to actually measure it before claiming that for sure). > Is it the case that Mutexes are the only lock type that's used in > AOLServer's thread safety? Seems like it... When you start up AOLserver, it is ALWAYS using multiple threads, two or three or so at the very minimum. I would be quite surprised if it continued to run reliably after you removed every single mutex lock... "ns_param maxthreads" sets the maximum number of connection threads, not the number of ALL threads of any type in the AOLserver process. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
