Forum OpenACS Development: Re: OpenACS Performance Tests

Collapse
Posted by Eduardo Santos on
Hi Gustaf,

Thank you very much for your answers. They are being very helpfull, as allways.

We really have a problem in measurement here. I guess JMeter results will be more accurate in response time, because it can track all the time that the request is stucked. Do you think this diference between JMeter and XoTcl Request Monitor could be an I/O problem? I'm sorry if this looks like a silly question, but I'm still learning this thing.

Concerning AOLServer, I've been following the discussions in the mail list and I've realized that it has some performance problems that people are fixing. So I've checked it out from CVS using Cognovis script, like this:


cvs -z3 -d:pserver:mailto:anonymous@aolserver.cvs.sourceforge.net:/cvsroot/aolserver co aolserver

I can say I have the latest version. Do you know how I can check the source code to make sure your patches are there?

About the threads, I can see some kind of problem, maybe even a bug in thread pools definition for AOLServer 4.5.0: no matter how much I increase the number of connections in pool1, I can only see something between 20 and 23 DB connections. This makes me thing the parameter change is not working. Do you know how can I confirm that?

Your last consideration is maybe the most important: I don't know if AOLServer is compiled for 64 bits. I used Cognovis script, so I can assume it's not compiled for 64 bits. Is that right? Do you know where I can find some documentation about how to do it?

PostgreSQL is compiled for 64 bits, I'm sure, because it was installed from backports.org postgresql-8.2 package. I forgot to mention that my OS is Debian Etch.

Last question: what are these parameters maxidle e maxopen for?

Thank you again for your help.

Collapse
Posted by Gustaf Neumann on
The fixes were not only about performance, but as well for stuck servers. By the mentioned cvs command, you should get the head version. The head version does not need the fixes for bgdelivery, since they are already included.

just by guessing i would not be surprised if your are not get more than 10 to 15 connections threads, since most likely, maxthreads is not used. If this is true, you don't need more db-connections.

Add the following script (from Tom Jacksons pool.tcl) to the end of your config file, which takes the old style configuration and uses the 4.5 ns_pools command.

 set cfgsection "ns/server/[ns_info server]"
 set minthreads [ns_config $cfgsection minthreads 0]
 set maxthreads [ns_config $cfgsection maxthreads 10]
 set maxconns [ns_config $cfgsection maxconnections 0]
 set timeout [ns_config $cfgsection threadtimeout 0]
 ns_pools set default -minthreads $minthreads -maxthreads $maxthreads -maxconns $maxconns -timeout $timeout

If you use e.g. 100 connection threads, and you load dotlrn, then you won't be able to run this in 32bit mode (2 GB). In this case, you have to go to 64 bit (necessary for everything, except the postgres server). For compiling e.g. Tcl, you have to configure with "--enable-64bit". I have no idea, what's available in debian etch in 64 bit.

In order to figure out, if a binary (e.g. nsd) or a library (.so, .o) was compiled with 64bit, try the "file" command.

maxidle and maxopen are timeout values, necessary as bugfix for ancient versions of aolserver, obsolete since a few years, but passed from config file to config file.