Forum OpenACS Development: Re: Ideas for easier installation of OpenACS: A digression...
First, this has nothing to do with commercial mass virtual hosting, as in an Apache style web farm.
As far as informing me on the subject as related to AOLserver, you might look back over my postings and software related to virtual hosting for the past eight or so years.
Since I wasn't in on your conversations with Dossy, it is hard to comment on it. Personally, I would ask your questions in a public forum so that any misconceptions can be caught. Just a few months ago I was stupidly claiming that AOLserver's static file performance wasn't that hot. Boy, was I wrong! Other than being beat on large file performance by lighttpd, AOLserver beat every other server.
One thing I agree with in your statement, and I have said it many times: AOLserver is not designed for _mass_ virtual hosting. But why? Because virtual hosts in AOLserver take up resources even if nobody is visiting the site! They are all up and running all the time. So if you do the math, just add up the memory footprint for each of your AOLserver instances if they were to run all alone, and that is pretty close to the combined total. You will save a little bit in overhead, but not enough to think about.
Another thing you would learn (about my opinion) from reading my previous posts on the virtual host/Apache envy front is that I strongly advocate against any attempt to emulate Apache. If Apache works for you, go for it. There are some on the AOLserver list which think that is where the software should go, but it only shows up when there is the periodic call for some direction for that community. Somehow there is a severe shortage of IP addresses, and folks can't figure out how to run AOLserver and Apache on the same machine. Basically it is not a software issue. AOLserver is an integrated application server for massive applications, not for serving masses of tiny toy websites.
The thread-safety thing needs to be addressed, because someone might think there is some issue. This is insane: AOLserver (actually the original commercial product NaviServer) made Tcl thread safe, at least in AOLserver. Apparently the channel code was not quite safe, but AOLserver used C based programming in this area, so it didn't matter. Now, Tcl channels are threadsafe and they are being used more in the AOLserver core.
But it is hard to tell exactly what the comment about thread safety between virtual hosts actually means. It probably means much less than what you think it means. Obviously, AOLserver can load shared libraries which are not fully thread safe, as can any C application, and what happens is a matter of chance.
Zoran has contributed much to AOLserver and Tcl, but I have no idea what the patch is since I don't know of any problem with virtual servers and multiple servers running in one AOLserver instance.
First we need some definitions on this subject. AOLserver can do several related things:
- One instance of AOLserver can listen on multiple IP/port combinations. Each of these listeners is a separate instance of nssock.so. But I believe you can also listen on all interfaces (0.0.0.0) with one nssock. This is typical of any server. But each instance of nssock uses a separate driver thread to handle incoming connections.
- One instance of AOLserver can load multiple servers (like an OpenACS instance). These servers are isolated, code-wise from each other. Two different instances of OpenACS will not interfere with each other, they can run side-by-side in the same process. However, due to the ability of any of these server instances to spy on other instances, or restart the process, I have never recommended combining multiple clients in one instance of AOLserver.
- Each loaded server can be a virtual host for incoming connections. That means that the driver threads look at the Host: header and figure out which server to use. In addition, the url is looked at to select a connection threadpool. It may seem weird at first, but drivers belong to the entire process. Each driver thread divides up the work based upon Host and url into threadpools. In addition, regardless of what threadpool is used, a server interp is placed in the thread based upon which server is used.
Naviserver is a fork of AOLserver 4.0.10 which as also ported some of 4.5 code. As others have pointed out, and I have confirmed with my testing, naviserver uses less resources. I only did static file serving, so it was a limited test. But AOLserver4.5 also outperformed naviserver by a good margin, at least 20%. AOLserver4.5 has improved driver code, and a few more threads, so that may account for the extra overhead and better performance.
If performance is critical for you, remember that it is easier and cheaper to add more ram than it is to add and maintain another machine. A product which delivers better performance with more ram is eventually going to be the better product, so the 'less resources' claim for naviserver has limited value.
On a shared machine (real virtual hosting!) you can run more naviserver instances and let those instances fight over the CPU and I/O. But as soon as you have a single application which might spill over to multiple machines, application performance becomes important, not the memory footprint.
So can AOLserver do virtual servers/multiple servers/etc.:
I decided to run an apache-bench on two servers in one instance of AOLserver. One server is running OpenACS-5-3-2 and I grabbed the home page. The other server is just a simple server. I grabbed a page which passes the request off to a worker thread, same as Gustaf uses for background delivery. It returns a 28k image file.
I hammered OACS with just 10 concurrent requests for 5000 total requests and hit the other server with 10000 request
with concurrencies of 20, 20 and 40. I've posted the logs at
http://junom.com/document/aolserver/apache-bench/
There is also the top of the startup log showing multiple servers being loaded and mapped to various Host headers.
In all cases, the concurrencies are above the number of threads in the pool.
I'll do another post today to hopefully better explain the config install proposal. In short it doesn't have too much to do with virtual servers or multiple servers in one nsd, it just has to do with distributing the configuration setup to multiple files so that the configuration can be added automatically during software installation.