TPAC needs to be instrumented so we can determine where performance bottlenecks lie

[Dan Scott]

* Evergreen master

The TPAC consists primarily of two layers: the template code that mostly handles formatting and display, and the Perl modules that handle most of the logic - including calls to the database.

To determine areas where we could focus on optimization, we should instrument the TPAC. A simple approach would be to create and populate a context variable if a debug flag (say, DEBUG_TIMING) is true. The structure of the variable will be a list of key-value pairs. The key will be composed of the interval since the start of the template generation, and the value will be a description of the event. These key-value pairs, in the forms of hashes, will be pushed onto the context variable throughout the Perl code. Oh, and we'll have to use Time::HiRes as Perl's default timestamps don't go beyond a granularity of one second.

For example:

[
    {0.000209 => "Allocated variables"},
    {0.005009 => "Issued search query"},
    {1.510110 => "Search results obtained"}
]

... or something like that.

Then we can also, based on the DEBUG_TIMING flag, expose the results at the bottom of each page, or something along those lines, so that we can easily debug problems on remote servers as well. Win win win!

[Lebbeous Fogle-Weekley (lebbeous)]

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/tpac-instrument-new

Boom!

Here's a branch that has Dan's instrumentation and a first use case thereof, in the record detail page

[Dan Scott (denials)]

Nice. I turned DEBUG_TIMING off by default and committed the resulting two commits to master. Onward to more insight into the speed of the TPAC!

[Lebbeous Fogle-Weekley (lebbeous)]

Backported to rel_2_2 by popular demand!