Forum OpenACS Development: Re: Tcl Profiling
Handling the load you are describing (300 * 5 -> 1,500 views per minute) is not too much (we are experiencing on our production site sometimes more than 10,000 views per minute, practically all of these are dynamic), but hits/views are very hard to compare, since the computational effort per request can be dramatically different.
First of all, CPU-bounded-ness is typically no big problem for aolserver/naviserver, when you have multiple cores. I would recommend to configure 2-4 connection threads per core for good scaling. If you cannot use multiple cores due to your virtual server, consider moving to the real machines - quad core (or even 8 core) machines are a commodity today.
Additionally, using a reverse proxy (such as nginx) for static content and baground delivery  will help you additionally to scale up.
Going towards high performance without serious monitoring is hardly possible, since every server is a fast as is weakest component. I am sure, you are aware of the options and tools, such as
- aolserver/naviserver specific tools xotcl-request monitor (statistics from actual to daily values) and nsstats.tcl (cache and lock statistics).
- db-tools monitoring (e.g. postgres statistics, both in-server statistics and log analyzing tools) and
- system monitoring tools (like e.g. hotsanic, symon, ...)
Coming now to your question - Tcl profiling:
There are at least 2 approaches:
- dtrace: newer Tcl versions have support for dtrace
provider. This allows you to turn on/off various
"probes" from an external program .... provided you
have a platform supporting dtrace (or access to such
a platform to run your tests)
- the next scripting framework (child of xotcl) has
among many features support for running tcl-procs
with non-positional argument support
(like ad-procs). We have a small extension to openacs
that allows to map all ad-procs with non-pos args
to that nsf-procs. We use since in production since
may. By this move,
- (1) the performance overhead per ad-proc invocation is greatly reduced (argument processing is done in C),
- (2) the memory footprint shrinks (non of the automatically generated argument parsers are needed)
- (3) one can use the built-in profiling support (when using xowiki, one can obtain even class diagrams with profiling information)