Originally named the NaviServer Daemon, AOLserver began as a proprietary webserver back before most people knew much about the web. This name still crops up in AOLserver as almost all AOLserver API's start with "ns_".

Most web professionals have never heard of AOLserver and swear by Apache or IIS. For anyone who questions the usage of AOLserver, just think of what ISP put the first three letters in AOLserver, and no it wasn't Juno.

Since I have no familiarity with IIS, but tend to dismiss is as I have found Windows to be a totally insufficient server OS, I can only compare AOLserver with Apache. It should be noted that when the decision to go with AOLserver was first made, Netscape numbered version 0.9, and Apache was not the 500-lb gorilla of webservers that it is today. It should also be noted that some of the concerns have been resolved in the Apache 2.x system.

AOLServer	Apache
Answered requests by creating new threads thus enabling it to easily scale up to higher numbers of requests (since threads are easy to spawn and tear down). Multiple threads also allowed for better sharing of data between requests.	Until recently Apache used processes to answer requests (this has changed with the 2.x series). These were expensive to spawn and did not allow for easy sharing of data.
An embedded TCL interpreter allowed rapid development of dynamic content for webpages. This included a well-defined TCL API for working with requests.	The use of CGI to create dynamic webpages was slow (as each request required the creation of a new process), but allowed the use of many different languages. The eventual development of FastCGI and the mod_*'s allowed increased efficiency, but the integration was not particularly tight and there was not a lot of uniformity between the modules.
A single DB API specification guaranteed uniformity in communicating with databases. The pooling provided by the system allowed rapid and efficient access to the databases since you didn't have to spawn new threads or processes every time you wanted to make a connection. This also guaranteed a maximum number of connections to the database which prevented flooding it.	No concept of database interactivity. This was provided by each of the individual modules. Many of the standard APIs (excepting JDBC and possibly PERL DBI) are poorly designed.

In an act of good faith I should mention that some of the things I mentioned as disadvantages, "loose integration with languages and databases" may be considered a good thing by some people. It makes it easier for developers to choose their own solutions. The choice is largely a matter of taste, and if I had started developing on Apache 2.x I might be more partial to Apache. Perhaps as I use Apache more I will grow to love it as so many people do.