Forum OpenACS Development: Re: TCL Parse Optimization

Collapse
7: Re: TCL Parse Optimization (response to 6)
Posted by Marcos Serrano on 11/12/08 10:02 AM
The times we took came from the developer-support request info (/ds/request-info?request=XXX). The ones below are an example.

"Parser time" is the time showed in the request processor part:

--
Served file /web/dev/packages/dotlrn/www/index.adp with adp_parse_ad_conn_file - 1319.0 ms
--

Total time, in the parameter section:

--
Request Duration: 1519 ms
--

And the "Database time" is the total duration of the database operations, at the end of the page:

--
725 Total Duration (ms)
--

If those are not the parameters we look for, there is another tool we can use to find out where the bottleneck could be?.

We are worried mainly because of the difference between the "total time" and the "parser time" is too big.

Collapse
8: Re: TCL Parse Optimization (response to 7)
Posted by Gustaf Neumann on 11/12/08 10:53 AM
The name of the proc is misleading, since it really executes the tcl/adp pair. Especially for /dotlrn the time depends on many factors, e.g. on what's portlets are on the start page, and how many memberships a user has. Another important spot are the master-templates (if you concerned about speed, try to avoid db-requests in the master templates).

On our production system, we have currently 763 users active, and i get for my dotlrn start page the following output

+0.1 ms: Served file /var/www/production/packages/dotlrn/www/index.adp with adp_parse_ad_conn_file - 1.7 ms
from the line you are looking at. We have essentially a 5.3.0 kernel with many local changes and optimizations (last time i counted, there were 15000 differences). This line is certainly no good starting point for optimizations.

My recommendation is to look at the most frequently used pages on your system (request-monitor/stat-details) and optimize the top 10%. For these pages, try to reduce the SQL queries (get rid of unneeded features, use caching) and optimize these.