Forum OpenACS Q&A: I'll bite - apache openACS?

Request notifications

Posted by ron shigeta on
I notice the apache driver is working fairly well at ArsDigita -
are there serious issues expected in making it work with openACS?


Posted by Roberto Mello on
It should work with OpenACS right off the bat I think. I am not into it very much. I don't know how database driver issues are handled and I haven't heard of anyone that has put OpenACS to work with mod_aolserver yet.

Actually, I haven't heard of anyone using mod_aolserver with ACS Classic either... only ArsDigita and strictly for testing and demoing. All their production servers run AOLserver as far as I know.

The purpose of mod_aolserver is to replicate the AOLserver API within Apache, so that AOLserver programs can work without any modifications inside Apache.

You're more than welcome to try it out and let us know how it went though.

Posted by Don Baccus on
I doubt you'll find much interest with those of us doing most of the OpenACS port work. just posted a link to an article benchmarking Apache and AOLserver for (apparently) returning static pages, which showed AOLserver serving up pages at about three times the rate that Apache does (and 10 times the rate that Zope does).  Thanks for the pointer to that, Dan!

While I'm always skeptical of benchmarks, the reality is we know that AOLserver is an extremely efficient webserver.  I have no reason to switch to Apache, or to put energy into making OpenACS work with Apache.  ArsDigita has business reasons for wanting ACS Classic to work with Apache, but we OpenACS folks aren't a business.

So, feel free to make it work with mod_aolserver if you want (I think you'll need to rewrite the Postgres database driver, but I'm not 100% certain of that).  But if you're only doing so because you know Apache 's popular, and don't have a better reason than that, you're wasting your time.

Now, one thing Apache does is handle virtual servers.  Progress on repairing this breakage in AOLserver 3.0 has been happening, though, and AOLsever 2.* handled virtual servers just fine and copies of the binaries can be found if you look hard enough.

...the guy who did the benchmark figured out why Apache was running slowly and then did another, more realistic benchmark. Apache comes out ahead of AOLserver this time. He also says the keepalive option in AOLserver (-k option) is not working right--AOLserver failed a whole bunch of requests. Read it all for yourself:$587

Posted by Blah Blah on
Wow, what a lame benchmark. What about AOLServer maxconnections, max and min threads, if stats were on, if verbose logging and debugging was on, what type and size of caching was done, if ab was run on localhost, if it was run over the network, what speed in mbps the network was if applicable, compile time options, etc.

Now, since I'm a whiner, I might as well do my own benchmarks. I'll have to move over to linux first though. I'm on FreeBSD now, and from what I read it isn't 1-1 like linuxthreads. A few weeks or so ago, I wanted to test performance using linux binary emulation, and downloaded the linux binary off the aolserver site. What's weird is upon execution, aolserver opened a number of processes, unlike my setup on FreeBSD. Quick benchmark results revealed 50% of the performance I was getting in the default FreeBSD port. I'm not willing to venture why, but instead will wait until I convert the box over to Linux to test.

Posted by Don Baccus on
Maybe the linux emulation on FreeBSD emulates linux threads via processes?

What you were seeing was AOLserver opening a few threads to get started.  On a real linux system, these show up in the process table because threads are implemented as "lightweight" processes, aka (one form of) kernel threads vs. user threads.

If you see no extra processes spawned when running AOLserver directly under FreeBSD, I presume this is a hint that either 1) FreeBSD implements user threads (i.e. threading is done within the user process, so only one shows up) or 2) "ps" by default hides "lightweight" processes/kernel threads (which linux "ps" doesn not).

As you can see, I don't know jack about FreeBSD threads...

Anyway, it sounds like threads with the linux binary emulation stuff is a lot less efficient than native threading under FreeBSD.  Now, if you get a lot less performance under native Linux we'll find that interesting!  A lot of folks use FreeBSD because the TCP/IP stack is more efficient than the Linux implementation (supposedly being fixed in 2.4 kernels, which won't be out in standard releases for many months).