Forum OpenACS Development: Re: cache statistics
our AOLserver grabs around 3GB
Prozessor is a Xeon 2.8GhZ
Hmm, this does not fit to my picture. All nsd threads are sharing 2GB on 32bit linuxes, therefore i have certain doubts, that the 3GB are true. How did you measure this?
The site has minthread of 30 and maxthreads of 40, as the
company has only 35 employees..
This looks to much. we have on our production site (up to about 1300 concurrent users) min threads not set and maxthread to 40. under easy load (300 concurrent users), we have between 20 and 30 threads maximum active.
We have the threadtimeout set to 300.
If minthreads is < maxthreads you are killing and
restarting threads while the server is running, and that
will increase your RAM consumption steadily. Make them equal.
This is not our experience. This might have been true with older versions of the aolserver, but seems fixed in newer generations. We see as well a growing memory consumption over time, but my interpretation is that this is due to fragmentation.
Per CPU you would not be able to handle more than about 4 active jobs (cpu intensive). Unless you have many deliveries of
large files over slow lines (which i doubt from your description), i would say that 20 connection threads are plenty already. For handling the file-deliveries, i would recommend the background file delivery based on libthread, which does not block connection threads.
You don't need per user a thread (how could we be able to handle 1300 users?). A thread can and will be used by many users, as every request occupies a thread for only a short time. This amount of time certainly depends on what the thread is doing (e.g. handling a .css file or doing a series of database queries).
In the xotcl-request monitor, you can see the under request-monitor/running the concurrently running jobs. I would assume with your 35 users, you will seldomly see more than 2 or three of these.
If you assume, that a page view takes 0.5 seconds on overage, an the user takes 1 second on viewing the page, an active user can generate about 40 views per minute. So, 30 users can generate 1200 views per minute, getting the value of Patrick mentioned above.
As a comparison, we have currently (semester not started) 325 users, an average page view response time of 0.11 seconds and we had in the last hours between 500 and 800 page views per minute (not counting static files like .css and images). Our peaks are around 3000 views per minute.
So, 1200 page views per minute looks like a challenge for 30 users. I would recommend to check out your usage by installing the xotcl request monitor and to monitor the actual views per minute on that site.
> For handling the file-deliveries, i would recommend the
>background file delivery based on libthread, which does not
>block connection threads.
do you have something working for this?
The asynchrounous background delivery requires a small patch (2 changes, one is a backport from naviserver) and the tcl thread library (by zoran). The application code is in XOTcl is only a few lines of code and is included in xotcl-core (bgdelivery-procs.tcl).
One needs the following patch to aolserver 4.0.10
with this patch and xotcl-core, you can replace
ns_returnfile 200 $mime_type $filename
ad_returnfile_background 200 $mime_type $filename
e.g. in cr_write_content in acs-content-repository/tcl/revision-procs.tcl
to activate it and to deliver files from the content-repository (file-store) in the background.
The connection thread is only used for permission management, localization of the file and writing the the reply header, the actual delivery of the file is performed via asychronous io without using up many resources. This can handle probably a couple of thousand concurrent file deliveries without running out of resources.
Btw, the streaming variety of the xowiki chat uses the same infrastructure to implement synchronous chats without polling.
That's cool stuff. Neophytos uses this on phigita.net since at least half a year and is as well very happy with it.
What about this patch on Aolserver 4.5?