OpenACS Monitoring

When running an OpenACS site, a couple of packages come in handy to monitor your site and see why and where bottlenecks are located. To use them,  you need to install NaviServer with libthread support. If you are lazy as I am, just download the installation script from naviserver-openacs and get started. This will make sure that you have all the necessary ingredients installed.

Then go to your systems' administration at /acs-admin and install two packages:

• xotcl-request-processor
• monitoring

The first one gives you an overview over the system performance, while the latter allows you to scan the error.log for errors and have them send to you via e-mail.  A little bit more detail:

Monitoring

The monitoring package has a couple of nice things which help you monitor your website. First and foremost, you can use it to get the error logs. This is HIGHLY recommended, as your users will not report errors to you. They will just complain internally and not use your site anymore. We learned this the hard way.

Once you have monitoring installed (and mounted at e.g. /monitoring) go there and edit the parameters. There you can define who should get the error reports send and how often they are sent out. NOTE: They will be sent out with every restart of the server, so this gives you a pretty good idea if your server has restarted.

You can also get the TOP reports (if you have a high load on the system), which is something I usually don't use, but maybe it is of importance for you.

Last but not least (for me at least) you can view which scheduled procs are running on your server and when they are executed next time. This is really helpful to understand what is happening on your site of the things you cannot see.

XOTcl Request Monitor

The request monitor (automatically mounted under /request-monitor) will give you a performance overview of your site, how many users are online, what are the average page load times ....

If you look at the overview page, you will first be delighted to see that the average times are so low. This is misleading, as the quick fetches to ".css" files and so on are counted into the equation as well.

More accurate is the aggregated stats view, which allows you to see which URLs are called most often on your site and how expensive they are to load. It is a good idea to have the most often called pages be *fast*.

One thing we do as well is to run the "last 100 request" page on a continuous basis in a browser window. It refreshes every 60 seconds and if you get the sorting right you can actually get a good overview of the activity on your site (e.g. we order by execution time, so we always see how long users are waiting for their pages and if this number goes up considerably, well, then we know we have to act!).