Forum OpenACS Q&A: ACS Apache desirability vs. OpenACS/AOLServer combo?

This post is lengthy but I believe it will be of interest to many
users

I know the generic Apache vs. AOL Server argument has probably been
beaten to death in the past but it occurs to me that recent
developments make it worth revisiting, especially as it pertains to
folks running the ACS.  Apache is continually improving and Arsdigita
has announced the completion of their port of the ACS to Apache (See
the Toolkit Fundamentals section of:
http://www.arsdigita.com/pages/toolkit/).

However, I don't see Arsdigita's port necessarily as much an
endorsement of Apache as an indication of how interested they are in
making the ACS available to as many people as possible.  I know that
I would feel much more confident running Apache simply because there
are so many folks who are familiar with it (and working to improve
it).

Therefore, I would GREATLY APPRECIATE the input of knowledgeable
users regarding the following specific issues (and any other
information relevant to this debate):

Does AOLServer still maintain significant performance advantages over
Apache (especially regarding ACS/database thread use/performance)?

Is it any more or less secure than Apache?

Do I have to use AOLServer to benefit from the OpenACS/PostgreSQL
port? (that is, if I go with Arsdigita's Apache-based ACS am I back
to being locked into Oracle?)

Finally, does anyone have any HARD DATA regarding performance
comparisons of Oracle vs. PostgreSQL on similarly equipped machines?

Thanks in advance for any comments/suggestions you can provide.

<blockquote>that recent developments make it worth revisiting, especially as it
pertains to folks running the ACS. Apache is continually improving
and Arsdigita has announced the completion of their port of the ACS
to Apache (See the Toolkit Fundamentals section of:
</blockquote>

    AOLserver is also continually improving and lots since it's now open source. If you follow the AOLserver list, you'll see that there are people writing new things for it every day. I just got a message that someone wrote a blowfish encryption module for it.

    AFAIK, ArsDigita did _nothing_ to ACS to "port it" to Apache. That is not a port. A new Apache Module was created to replicate the AOLserver Tcl API. As far as ACS goes, it will just just continue calling its Tcl procs doesn't matter where.

    Of course, the mod_aolserver has none of the performance advantages that AOLserver has, namely multithreading and connection pooling.

<blockquote>interested they are in making the ACS available to as many people as
possible. I know that I would feel much more
confident running Apache simply because there are so many folks who
are familiar with it (and working to improve it).
</blockquote>

    Let's just think about this: how long does it take for someone that has experience with any webserver to be familiar with AOLserver ? I mean, it's not a hard thing. AOLserver's simple, but efficient design is extremely nice for new users. The first time I installed AOLserver I had it up and running in less than half an hour. The first time I compiled AOLserver from scratch (with the right compiler) it was just a matter of doing a make and make install. How hard it is to get used to that ?

    The first time I installed Apache I had to read all three configuration files and remember in which one of them was the setting I was trying to tweak. The first time I tried to compiled Apache I simply quit. I had better things to do with my time than try to figure out innards of Apache's configuration.

    Another thing you have to keep in mind is that most of the Apache users simply _don't know_ about AOLserver. When Michael Cleverly told me about AOLserver and Philip's book, I was only used to Apache and thought that it was _the_ thing in webservers because of all the media hype around it. After I read Philip's book and installed AOLserver I never went back to Apache. I don't have a reason to.

<blockquote>Does AOLServer still maintain significant performance advantages over
Apache (especially regarding ACS/database thread use/performance)?
</blockquote>

    Yes ! Apache is process based and a caching webserver. When Apache 2 matures, which won't happen in at least a year, then you'll be able to enjoy in Apache what AOLserver has been offering since 1995. Now that's improvement !!

<blockquote>Is it any more or less secure than Apache?
</blockquote>

    This is up to the administrator.

<blockquote>Do I have to use AOLServer to benefit from the OpenACS/PostgreSQL
port? (that is, if I go with Arsdigita?s
Apache-based ACS am I back to being locked into Oracle?)
</blockquote>

    If you want to go ahead and test OpenACS with mod_aolserver on Apache, that would be great. At least we would know. I don't think anyone has done it yet.

Actually, aD first ran our Postgres port, not the Oracle version (OpenACS, not ACS Classic using our new vocabulary) with mod_aolserver, so we know it will work.

I would think mod_aolserver implements persistent database connections , otherwise it would be useless for any serious work.  So that shouldn't be a problem.

mod_aolserver's still not ready for prime time, though, I'd wait awhile before getting too eager to put it on a production system.  As of last week Rob Mayoff (one of the two implementors) said it was still in a preliminary state.

While you're waiting, you might as well give AOLserver a try.  Don't worry, you won't get cooties from downloading it.  You might even like  it, as Roberto points out.

It's not clear why you'd be more confident running Apache from a reliability or performance point of view.  The hard part about writing a very high-performance web server is to get the multithreading stuff right, and AOLserver's  been multithreaded from the beginning, which was several years ago.  Apache's threaded server is finally available for alpha test only.

The AOLserver folks were also the first to realize that built-in persistent database connections were important - in other words, they were the first to realize that the most useful web sites would be built on database engines and that efficient connectivity was crucial.

Apache's widely used, but has been somewhat glacial in recognition of these two important points.

As far as security goes, IMO the AOLserver development team seems obsessed with security, and have taken out some of the more user-friendly stuff (like web admin pages) that are potentially insecure.  This is due to the fact that AOL's website and Digital City both run on AOLserver, I should think.  Not everyone likes AOL (a sentiment easy to understand) and I imagine folks try to hack into their web sites far more frequently than they try to hack mine.  Or yours.

Like Roberto, I too started with Apache.  Then a friend told me about aD and so I started to surf their site.  I found this little webserver called AOLServer, and my first thought was "It's AOL how good could it be?".  Then I started reading Phil's book and talking with some other webmasters I know and I found out that AOLServer was pretty damn good!  So I decided to download it and give it a try.

Well, installing and running AOLServer was easy, but I don't think it was any easier than Apache.  Anyway, I spent a good three days trying to get ACS to run.  I'm not an Oracle expert and I didn't want to spend 10K on their database so I decided to give ACS/pg a try before I gave up on ACS.  It took me two hours to setup and configure this distribution of ACS thanks to the great documentation here at openacs.org .  So far I love it.  It seems quick.  I am testing it on a dual celeron linux box with 256M ram.  I don't have any concrete numbers, but it feels fast.

I can tell you this.  I am going to decommission my Apache server and start using AOLServer with ACS/pg!  The only downside is that the look of ACS is boring.  I wish there was some easy way to make it look nicer. =)  But its out-of-box features are great!

Gilbert

Collapse
5: FYI: Apache installation (response to 1)
Posted by Joe Slag on
Just to clarify, recent versions of Apache install via

./configure
make
make install