[Contrib: Evaluation System] sakai 2.5.3 performance

[Hedrick Charles]

I can't answer your question because I've never used a JVM that small in production. We have a 1 GB JVM on our primary test system, but we've never put more than a few users on it.

I'd like to point out that it's not just the number of concurrent connections. Data about users and sites is cached. Larger institutions will tend to have more connections, more users and more sites, so it may all go together, but there's a basic overhead that isn't dependent upon number of current connections.

Also, watch your memory usage. It will tend to grow over time. I've never been clear whether this is caches growing or a memory leak. I suspect a memory leak. We have to restart every few weeks, or the system will go into continuous garbage collection. I'm attaching something you can put in tomcat/webapps/ROOT to print out memory usage. It shows current usage, usage as of the last GC, and the maximum usage after a GC. That will let you judge whether memory use is getting dangerously large. (For anything other than current usage to work, it has to be called soon after the JVM is started. We call it from a cron job, and put the output in a file. That lets us watch memory usage over time.) You call it as SITENAME/memstats.jsp.

Also, I would strongly recommend against doing a new installation of a version that old.  Newer versions perform better and have bug fixes, including a few security-related. I don't believe 2.5 is still supported.

At this point I'd use 2.7.1.

With a 10.5 GB JVM (using the size of -mx – in fact the image is larger, because there are things not counted in -mx), we routinely get around 2500 sessions on one system. This is the count shown in Sakai. Not all of those are actually doing anything, since Sakai will keep sessions around for a couple of hours before timing them out. 

We see up to 500 threads in the JVM. Tomcat tries to control the number of threads at a time. It will hold incoming connections until there's a free thread. This made sense 10 years ago with limited memory. Today I don't think it makes sense any more. In the <Connector configuration statements we set maxThreads="2000", which is intended to be large enough not to be a limit.


On Mar 31, 2011, at 11:34:28 PM, Edu Hotmail wrote:

> I'm newby configuring tomcat and java, I'm going to install sakai 2.5.3 on linux centos 5.5 with 3gb ram . The database is on other linux with 4gb ram using oracle database 10g.
> I need to estimate how many concurrent network connections can support the tomcat sakai for working with an optimal performance using the previous configuration...
> How is the relationship between tomcat java memory used and concurrent network connection permitted?
> Thanks a lot,
> Edu
> _______________________________________________
> evaluation mailing list
> evaluation at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/evaluation
> 
> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20110402/a605d045/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memstats.jsp
Type: application/octet-stream
Size: 1487 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/evaluation/attachments/20110402/a605d045/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20110402/a605d045/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3817 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/evaluation/attachments/20110402/a605d045/attachment.bin