On Friday, August 9, 2002, at 04:29 PM, C. R. Oldham wrote: > Does anyone have any other clues for tuning? The tuning documentation > for AOLserver (at aolserver.com) isn't very helpful.
The big secret to tuning AOLserver is that there isn't much to tune. There's minimal gain to be made by increasing the transmission buffer sizes in nssock, and you can play with the MaxThreads, increasing it until contention begins to dominate your timing. Most people I've encountered trying to tune AOLserver are saddled with slow applications which really don't respond to tuning. And it makes sense...AOLserver is widely deployed at AOL, where they don't want to have to go through an extensive tuning regimen each time a site is put up in order go get acceptable performance. Apache is designed with correctness as the first goal, and performance second; AOLserver is designed for performance in dynamic content first. If you have static content, you can sometimes get a win by dedicating a separate server to it, but I find that's often not worth the trouble -- AOLserver isn't bad at static content (you just have to make sure you're not doing a zillion database queries to determine that your visitor is allowed to see the static images you use for nagivational aids), and, particularly if you have an SSL site, moving the graphics to another server is a big pain, usually causing mixed content warnings in browsers unless you obtain a separate certificate for the static server. There are ultra high-performance applications for which a dedicated static server makes sense, and AOL happens to have a bunch of them (so many that Jim and his team build a separate webserver just for the purpose of serving images) ; most folks don't have those problems. For the most part, if you're having unacceptable performance from your AOLserver application, there's a good change it's not AOLserver's fault, and there will be very little gain to be made from tuning. The one exception is where the initial AOLserver configuration has been too conservative with MaxThreads and number of database connections. Most environments can afford one database connection for every active thread, so set the Connections parameter of the pool to whatever you set MaxThreads to. And on any modern processor, try a MaxThreads of at least 20. Pete.
