How can I configure xtprof module to profile only during test duration (not during ramp-up duration).

[Sheharyar570]

Hi HammerDB Team,

I've noticed that Xtprof profiles the procedures during the ramp-up phase as well as the test duration. However, I would like it to only profile the procedures during the actual test duration. Specifically, I want to track the count of queries (or the count of specific procedure calls) made during the test duration, such as the count of stock level queries/proc calls.

The challenge I'm facing is that I need to inform all the VUs from the monitor thread that the ramp-up time has completed, so then they start counting the procedure calls. If there is a better way to achieve this, please let me know.

Also, how can I configure or change Xtprof to accomplish this? Any guidance would be greatly appreciated!
Thanks!

[sm-shaw]

Hi,
There is already an issue for this #233 and another ramp up related one here #583.

Note that xtprof already includes the call count for all of the stored procedures - see "calls" below

hammerdb>job 66BF22C461FC03E243231393 timing
{
  "NEWORD": {
    "elapsed_ms": "418829.0",
    "calls": "62731",
 ...
}

Also if you use the XML connect pool option (designed for clusters but can use for single instance as well) each VU will individually report the number of transactions it did as well.

Vuser 2:VU2 processed neworder 275335 payment 273822 delivery 27495 stocklevel 27588 orderstatus 27568 transactions
Vuser 3:VU3 processed neworder 272901 payment 273475 delivery 27493 stocklevel 27194 orderstatus 27097 transactions

A PR for #233 is welcome. It would need to either set a tsv (thread shared variable - see existing code) that the VUs periodically check to flag when the rampup is finished before going package require on xtprof OR independently based on the rampup time, user delay value and VU position calculate their own rampup and wait until this is complete before doing package require,.

[wahajali]

@sm-shaw Above makes sense.
I was exploring another alternate and wanted your thoughts. I was considering adding a function in xtprof that resets the state:

proc xtreset {} {
    global ProfilerArray
    array unset ProfilerArray
}

This will clear the state. Once ramp up is complete, each VU calls this proc. When proc xttimeprofiler is called in the following iteration, it will reinitialise this state.

Like you said, for that we'll need the tsv b/w the monitor thread and the other VUs to signal to the VUs that ramp up is complete. Perhaps something similar to how it checks for the abort condition works:

if { [expr {$it % $abchk}] eq 0 } { if { [ time {if {  [ tsv::get application abort ]  } { break }} ] > $hi_t }  {  set  abchk [ expr {min(($abchk * 2), $abchk_mx)}]; set hi_t [ expr {$hi_t * 2} ] } }

After reading your comment though, the solution to just import the xtprof module after ramp up is complete seems simpler (given we're just discarding the ramp up data anyway).

[wahajali]

@sm-shaw I tried the approach where I require the xtprof package after rampup is complete. However, with this approach the proc overloading doesn't kick in, and therefor the xttimeprofiler function never gets called. Its seems that the package require statement needs to be before the proc definition we want to profile? If I move the require statement to the start of the block for the VU, or just before the proc I intend to profile, then it initialises the profiler code just fine.

[wahajali]

One work around I experimented with is to define a wrapper proc around the original proc. Then I define two loops:
First loops is for those queries that are intended for ramp up time. This uses the original proc, which is not profiled.
Second loop starts after ramp up time and it uses the wrapper proc for queries. This function will be added to xtprof for profiling.

proc custom_search { lda k RAISEERROR ora_compatible pg_storedprocs } {
        # code to do custom query
}

for {set it 0} {$it < $total_iterations} {incr it} {
        if { [expr {$it % $abchk}] eq 0 } { if { [ time {if {  [ tsv::get application abort ]  } { break }} ] > $hi_t }  {  set  abchk [ expr {min(($abchk * 2), $abchk_mx)}]; set hi_t [ expr {$hi_t * 2} ] } }

         # New shared variable to notify once rampup is done, this is set by monitor thread
        if { [ tsv::get application ramp_done ] } {
                puts "Ramp up time is complete, moving on..."
                break
        }
        custom_search $lda 5 $RAISEERROR $ora_compatible $pg_storedprocs
}
# Ramp up done

# Add xtprof here
if [catch {package require xtprof} ] { error "Failed to load extended time profile functions" } else { namespace import xtprof::* }

# This is JUST a wrapper for custom_search and will be profiled by xtprof, while custom_search won't be profiled.
proc custom_search2 { lda k RAISEERROR ora_compatible pg_storedprocs } {
       custom_search $lda $k $RAISEERROR $ora_compatible $pg_storedprocs
}

# Another iteration for actual test post ramp up.
for {set it 0} {$it < $total_iterations} {incr it} {
        if { [expr {$it % $abchk}] eq 0 } { if { [ time {if {  [ tsv::get application abort ]  } { break }} ] > $hi_t }  {  set  abchk [ expr {min(($abchk * 2), $abchk_mx)}]; set hi_t [ expr {$hi_t * 2} ] } }

        # This uses custom_search2, so that this is profiled.
        custom_search2 $lda 5 $RAISEERROR $ora_compatible $pg_storedprocs
}

[sm-shaw]

Yes you are right xtprof redefines proc to add the trace handlers so it will only trace procs defined after the package has been called.
Note also that any solution needs to be tested against all databases and all of the different scenarios such as use all warehouses, asynchronous connections etc as these modify the script that is loaded by doing in-line editing.