Forum OpenACS Q&A: How many OpenACS instances?

Collapse
Posted by Jacques Williams on
For planning purposes, I am trying to figure out how many (moderate
traffic) OpenACS instances a given hardware configuration can support.
Can anyone suggest any guidelines on how to go about calculating this?
Collapse
Posted by Ben Adida on
You might be able to get some info from Furfly given that they are doing OpenACS hosting with multiple instances per box, but in general, pushing hardware limits with OpenACS is still a new field :) I have about 5 instances running on a dual Pentium II-400 with 256 megs of RAM, and I'm pushing things a bit on that.

In general, if your sites are low traffic, you want to worry mostly about how much RAM you have. Each OpenACS instance requires one AOLserver, plus usually 10 DB connections. Each DB connection is a PG backend process. I would suggest having at least 30-40M of RAM per OpenACS installation, and preferably 50M or more if you can spare it. The second important aspect is the speed of your drives. Having Ultra SCSI drives will do *wonders* for you, simply because of all the disk writing that any interesting OpenACS site will do. The third aspect is processing power. Count up the # of hits you're getting on all sites combined. My estimation is that a single Pentium 800 box with Ultra SCSI drives can take about 1 million OpenACS-like hits per day before it maxes out. This figure should be confirmed in a more scientific way, but that's the trend I'm seeing.

Thus, again, the big determining factor is RAM, and to some extent disk speed.

Collapse
Posted by Janine Ohmer on
Our experience mirrors Ben's;  we've got 10 instances on a
system with 512 Mb of RAM, and that looks to be the limit.

However, for sites which aren't too busy you can turn off things
like fastpath and adp caching, which will reduce the amount of
memory each nsd instance requires, and probably squeeze in a
few more. (thanks to Don for this suggestion, which I'm just now
starting to experiment with)

BTW, the load average on this system is 0.0, proving once again
that OpenACS, postgres and nsd are incredibly lightweight.  I'm
pretty confident that if we maxed out the memory in the system (2
Gb, I think) and ran 40 small sites, we'd still see very little load.
The system has a single 733 Mb PIII, outdated by today's
standards.

Collapse
Posted by Scott Mc Williams on
RAM is definitely the key. We're in the process of upgrading to 512MB as well. I'll let you know the results. We have 10 instances running right now and things have been crashing with 256MB.

I was wondering if it would help at all to remove unneeded files in the /tcl directory. For instance, if we have no classifieds on a site, would it help at all to kill gc-defs.tcl? I know one file wouldn't do a lot, but we have a few sites that don't use many ACS functionality at all and I think those would add up.

Thanks,

Scott

Collapse
Posted by Don Baccus on
If you're crashing you're probably running out of swap space, so
you'll want to look closely at the memory consumption of each site's
nsd process.  Also take a look at your postmaster -B switch value.  On
my 256MB dual P450 (faster than Ben's, nah-nah-nah!) I've got -B set
to 8000 16KB blocks, i.e. 128MB or half the machine.  I'm only running
two sites, though, which hover around 90 MB in consumption combined.
The two sites aren't very busy, but one's very database intensive,
thus the large buffer cache for PG.

I'll be interested in seeing Janine's report on memory consumption
after turning off fastpath on one of the sites that has a lot of
static pages and a fair amount of traffic.  The idea is that turning
off fastpath will be slower, but not too bad because most of the
resulting filesystem reads will come from the linux file buffer cache.
Fastpath takes a lot of RAM because each thread has its own cache,
while the linux file buffer cache is shared systemwide.

For a relatively unbusy site with lots of static pages you should be
able to decrease RAM consumption this way.  For a busy site, of course
you'd want to pack the machine with as much RAM as possible and turn
fastpath loose with a fairly high per-thread cache limit.  Of course,
you probably wouldn't be running 10 sites on the same machine as the
monster site, either!  Different approaches for different scenarios.

Of course, Janine may come back in a day or two and report that this
approach didn't help at all.  We'll see!