Forum OpenACS Q&A: Is OpenACS extremely slow?

Posted by Maxim Burgerhout on
A while ago I started experimenting with OpenACS. And while it is
impressive in sofar as the possibilities are concerned, it is
somewhat disappointing in the speed with which everthing is served.

As a webserver I am using an old P200 with a mere 36MB's of EDO RAM.
I know this is very humble as a server, but for it's former purpose
(serving dynamic PHP pages out of a mySQL database off an Apache
webserver) it was perfect and functioned fast and flawless.

However the aolserver / postgresql combination seems to be either
very, very processor intensive or wrongly installed (by me obviously).

Where the mysql and httpd daemons never used more than a few percents
of proc power, aolserver doesn't wake up for less than 20. Postgres
is a little less hungry, but will eat 10 percent off my CPU as well.

This results in extremely slow operation of my OpenACS website, to
the extent that I think of removing it again because it is simply
impossible to work with.

Even when I am NOT using the website (and no-one else is either)
aolserver will eat anywhere between 10 and 20 percent CPU power. When
in use it will fly above 30% (even much higher than this) and
postgres usually does the same when it is used. My whole system
(sshd, proftpd, courier-imap and postfix) seem to suffer from this.

Sorry for the long story, but my questions (after searching the
boards here) are these: a. is this normal behaviour and if not, how
can I tweak my server to operate faster? and b. are there more people
suffering from this?

Posted by defunct defunct on
I have managed to get fantastic performance from OpenACS even on very modest hardware.

Comparing with Apache MySQL is not really much of an indicator, as OpenACS/AOLServer is a far more comprehesive arrangement, therefore its not unrealstic to be a bit more resource hungry.

I think its most likely the memory thats causing you trouble... 36M really isn't very much... it wasn't very much for about 5-10 years ago. I think your simplest solution might be forking out th $15 or whatever it is for a bit more memory...

Posted by Maxim Burgerhout on
Sadly, adding a lot more memory is not an option. Besides: I checked another openacs machine here just the other day, and it had a memory footprint of over 250Megs (!). Either the guy who installed that one did something wrong too, or there is some other problem.
I don't get the big difference between aolserver/postgres/openacs and apache/php/mysql by the way. Bot are webservers, combined with a scripting module and a database. Of course, the programs are different, but why should I regard the first as something so much less substantial and resource consuming? What is the big resources hogger in openacs?

I'm pretty new at this, I'm sorry if this is a dumb question, but I'm trying to get this to work and it won't budge!

Posted by Lars Pind on
An OpenACS installation can easily eat 50 Mb of RAM or more. A lot of it is due to extensive caching. All queries on your system (the text, not the results) are chaced, and all the library code files are bytecode compiled and cached, just to mention a couple examples.

I've never actually looked into this, as it's never been a problem on any projects I've been on: It's always been cheaper and easier to get more RAM. So long as it's not leaking, it's cheap and easy to add more RAM.


Posted by defunct defunct on
Sorry about that, I didn't mean to imply there was no configuration problem, you may well need to configure somehting correctly, I merely observered that that is a pretty low mem. level... and it would definately help..

Ok, you asked what the big difference is, so I'll try and explain in general terms.

MySQL is not (arguably) an ACID compliant database. If you're not worried about things like transactional integrity, rollback and so forth, then its fine.... however for the kinds of systems that OpenACS is deployed for these are necessary.

OpenACS is many good things, but perhaps the most significant element is its well conceived datamodel. This extensive arrangement is what offers you the OpenACS facilities such a permissioning, subsite management and so on...

So on that score alone, OpenACS is far more comprehensive (and therefore sizeable) than you existing setup.

Apache Vs AOLServer. This is a more difficult one. It often depend on exactly what you define as Apache (i.e. the numerous extensions). But at the core level Apache offers about 20% of what AOLServer can do. Apache is excellent at serving static pages, simple content and so forth, but AOLServer excels when you need a good, well managed interface to a database and your creating highly interactive web services.

My company has delivered projects on a number of alternative in the past two years (i.e. JBoss/J2EE based, Apache/Tomcat/MySQL, IIS/SQLServer and so forth) and I can tell you, without hesitation or shadow of a doubt, OpenACS is a far superior platform.

And thats not personal evangelism, that comes from the bitter realities of commercial development. I formed our company around OpenACS because it allows us to be highly profitable, deliver with quality whilst at the same time being able to offer our customers fantastic pricing due to reduced development and OS principles.

In fact if anything this is where OpenACS wins over all.. The speed and reliability with which one can create new application is breathtaking....

A recent implementation done with Tomcat/JBoss ended up taking nearly 4-5 times longer than our estimates for an OpenACS based solution.

Looking at your original mail I'm a bit surprised by one thing. You say AOLServer is constantly consuming about 20% of your processing power, even when idle... I can certainly say that in all our installations AOLServer remains quiet and very low in terms of resource usage......

This does seem unusual....

So you have further info on your setup? i.e. what versions of Linux are you using?... Also are you using OpenACS 3 or 4.... if 3 I can't really help you. My comments above all relate to 4.5

It might be worth posting to the AOLServer mailing list, as there's some pretty switched on AOLServer folks there.

Also, and I can't promise I'll know, can you post up your config file for AOLServer (remove passwords ;)....

But in summary, no, I don't think what your seeing is 'normal' so I'm sure someone here will be able to help :)

PS/ Another good reason to use OpenACS, is that this community is one of the best around.

Posted by Jun Yamog on

You can look up this link on why openacs

Posted by Dave Bauer on
OpenACS is much more RAM intensive than CPU. I run two sites one, Aolserver/tcl and one OpenACS 4.5 on a AMD 500Mhz machine with 256MB ram.
Posted by Dan Wickstrom on
Now, if you think openacs/aolserver/postgresql is a resource hog, you should try openacs/aolserver/oracle to see some real resource usage.  IIRC, oracle at a bare minimum requires 256 MB of memory, and I wouldn't even recommend running oracle with anything less than 512 MB.  With your 36 MB of memory, you wouldn't even be able to start oracle.  Postgresql is not as resource intensive as oracle, but as far performance goes it's close if not better in some cases.  If you want industrial strength applications which support highly concurrent loads, then you have to expect to pay they price in additional resources.  This is an applications space where mysql just can't cut it.
Posted by Jonathan Ellis on
I ran my development server on a sparc 10 (dual 50 mhz!) w/128MB ram.  I'd  consider that pretty close to minimum, memory wise.  (Especially since part was taken up by emacs. :)  Caching all the tcl procs alone was close to 20 MB on a default 3.2.5 install; I imagine 4.x is more.  Move the packages you don't use somewhere else, and get more ram.
Posted by Tapiwa Sibanda on
off topic I know, but if you want to see sluggish, try running acs 5.0 aka RedHat CCM (or something)

I have played with both openACS 4.x,(o8i and pg) and java CCM, and even on a sony viao 400Mhz with 128MB ram, postgres/openacs is still quite nifty.

The server takes a wee while to get started, but after that it is quite responsive.

Posted by carl garland on
I think the main reason to point out here in concern to what is the difference in resource usage between AOLserver/OpenACS vs Apache/PHP is to understand the underlying architecture.

Apache works in a forking model which create/destroy new processes as needed. PHP stores no cache information (in memory ... it does in files) at all so each page execution requires merely the weight in memory of the apache process.

AOLserver/OpenACS on the other hand has hundreds of procs that are compiled into each interpeter and an extensive cache which expands during the course of an aolserver process life to speed up its dynamic execution. The memory allocation scheme of AOLserver is such that any time it needs more memory for potential new cache items it determines if there is any free memory left since last allocation and then if not creates a new block of memory to use until that is used up. This is a *zippy* fast memory allocator but also has a high level mark indicator for its footprint meaning that a process can only grow not shrink over time. According to Amadahl's law the bottleneck of any system determines overall throughput. Since memory is faster than disk it was determined to take advantage of this fact but heavily using the memory of a system to improve performance.

AOLserver was built to handle large load efficiently but requires memory for this. OpenACS adds the datamodel, interface to that model on top of AOLserver speeding application development. You very well could duplicate this architecture on Apache but would require a substantial amount of effort.

Anyway as a side note I did alot of development on an AOLserver/Postgres backed site on a celeron with 32 Meg of RAM couple years ago and worked pretty fast/well if tuned to minimum settings. The extra layer of OpenACS though is too much of a footprint to not use more ram.
Posted by Maxim Burgerhout on
Thanks, all of you for trying to help me out here. The reason of the (experienced) sluggishness of OpenACS/PGSQL/AOL is a lot clearer to me now! I understand a lot of you tell me to buy more memory or suffer the consequences. As I said earlier: that is not an option, I am supposed to try OpenACS out and do so on the machine I have.

Of course I understand that quality has a price. We are trying out OpenACS however not because of it's stability etc. but because of the possibilities it offers as a community system. Eventually we will have a much better machine to work with OpenACS, so if memory is the main bottleneck, I suppose that bottle will be capped soon enough.

I consider my question suffiently answered: Aolserver is eating memory  like a vampire sucks blood because of it's caching work, postgres is rather memory intensive too, and openacs does not make this any less so.

Thanks for helping us out here! Time to grab a cold one now, cheers!

Posted by Jun Yamog on
Off the topic:

I doubt anyone is screaming... memory help!!!! like me.

I develop on CCM 5.1 + resin + Oracle + eclipse + emacs

So whenever I switch back to OACS + aolserver + postgres + emacs ... I am a very happy dude.

I would like to get back on cgi + mathopd + flatfiles + vi

Posted by Don Baccus on
If you're just testing play with some of the AOLserver configuration options to limit the number of threads it creates, cache memory it will use, etc etc.

Also tell it threads live for a very long time, never to kill the database connection, etc etc.

Out of the box AOLserver isn't *quite* configured in a "we can run now" mode but the default configuration is meant to be usable under fairly heavy load.  The developers basic attitude is "any real webserver has a gig of RAM" ... they don't think small by nature.

That's a great help to us who write sites that are destined for heavy traffic.  We can concentrate on tuning our database queries and all that, knowing that AOLserver will consume memory with enthusiasm but in return will do what it does very quickly.

One thing that OpenACS 4 does that definitely requires a fair amount of memory - we cache all query strings for all installed packages that pertain to the RDBMS in use (Oracle or PG) at start-up time.