Results
-The measurements were taken ondev0103-001 on 5
+
+The measurements were taken on dev0103-001
+ on 5
October 2000, probably with acs-4-0-beta-R20001001. Here are the
graphs for the 14 stages, titled by the log message of their
beginning.
-Invoking preauth filter rp_filter
No difference; all take about 2.6 ms. The same is the case for +
Invoking preauth filter rp_filter
+
+No difference; all take about 2.6 ms. The same is the case for the few following stages: Short times and apparently independent of -the kind of page.
Looking for node to match -/acs-templating/admin/test/chain-frac-0.
Found /acs-templating/.
Performing developer support logging
Checking for changed libraries
Handling authentication
For some reason, this seems to take much longer on the Tcl-only +the kind of page.
+Looking for node to match +/acs-templating/admin/test/chain-frac-0.
+
+Found /acs-templating/.
+
+Performing developer support logging
+
+Checking for changed libraries
+
+Handling authentication
+
+For some reason, this seems to take much longer on the Tcl-only page. Maybe because it's the first in a triple of pages that e-Tester requests? There may be a little longer time gap between -chain-frac-2 and the next request of chain-frac-0
Handling authorization
An unexplained but clear distinction here: 0 is faster than 2, -and 1 is slowest.
Done invoking preauth filter rp_filter (returning -filter_ok)
Invoking registered procedure rp_handler
Searching for -/webroot/web/brech/acs/packages/acs-templating/www/admin/test/chain-frac-0.*
Serving
+chain-frac-2 and the next request of chain-frac-0
+Handling authorization
+
+
An unexplained but clear distinction here: 0 is faster than 2, +and 1 is slowest.
+Done invoking preauth filter rp_filter (returning +filter_ok)
+
+Invoking registered procedure rp_handler
+
+Searching for +/webroot/web/brech/acs/packages/acs-templating/www/admin/test/chain-frac-0.*
+
+Serving /webroot/web/brech/acs/packages/acs-templating/www/admin/test/chain-frac-0.tcl -with rp_handle_tcl_request
Here the actual work supposedly happens. The Tcl-only page is
+with rp_handle_tcl_request
+
+
Here the actual work supposedly happens. The Tcl-only page is clearly fastest. Always reparsing pages expectedly affects the templated page, and -2, which compiles two ADP pages, is affected more than -1. The benefit of -2, wrapping -1 in another include, isn't apparent; on the contrary, -1 is in all cases a bit faster than -2. The benefit of cacheing seems more than offset by the -extra complexity of nesting several templates.
Invoking trace filter ad_issue_deferred_dml
For some reason, the Tcl-only page takes significantly -longer.
Done invoking trace filter ad_issue_deferred_dml (returning -filter_ok)
Invoking trace filter ds_trace_filter
That last phase is ended by Done invoking trace filter +extra complexity of nesting several templates.
+Invoking trace filter ad_issue_deferred_dml
+
+For some reason, the Tcl-only page takes significantly +longer.
+Done invoking trace filter ad_issue_deferred_dml (returning +filter_ok)
+
+Invoking trace filter ds_trace_filter
+
+That last phase is ended by Done invoking trace filter ds_trace_filter (returning filter_ok) -
Total time
Overall, the templated pages are delivered faster. +
+Total time
+
+Overall, the templated pages are delivered faster. Forcing the template system to always reread all files and to recompile the ADP part slows them down, as expected, but overall -they are still faster than the Tcl-only page.
Christian -Brechbuehler -Last modified: Tue Oct 17 20:04:29 EDT 2000 - +they are still faster than the Tcl-only page. +
+Christian +Brechbuehler + +Last modified: Tue Oct 17 20:04:29 EDT 2000 \ No newline at end of file