End User Response Time

Inspired by Robin's [blog|twitter] Measuring real user response times for OBIEE, I remembered a wonderful APEX nugget: DEBUG

Robin's post was the continuation of a discussion between himself and Alex Gorbachev [blog|twitter] about...something. I'm pretty sure I glossed over much of it.

The reason I glossed over it is because I immediately thought about APEX and how easy it was to measure end user response time. OK, a little fib there, the data is there, some enterprising young APEX developer would just need to figure out how to get it.

OBIEE has cruddy instrumentation...wait, no instrumentation, from an end-user perspective.

But APEX does. (BTW, we should lobby to get some from the APEX team to show the OBIEE team how they do it).

 0.00:
0.00: S H O W: application="104" page="1" workspace="" request="" 
session="2529775339668942"
0.01: Language derived from: FLOW_PRIMARY_LANGUAGE, current browser language: en-us
0.01: alter session set nls_language="AMERICAN"
0.01: alter session set nls_territory="AMERICA"
0.01: NLS: CSV charset=WE8MSWIN1252
0.01: ...NLS: Set Decimal separator="."
0.01: ...NLS: Set NLS Group separator=","
0.01: ...NLS: Set date format="DD-MON-RR"
0.01: ...Setting session time_zone to -04:00
0.01: Setting NLS_DATE_FORMAT to application date format: MM/DD/YYYY
0.01: ...NLS: Set date format="MM/DD/YYYY"
0.02: NLS: Language=en-us
0.02: Application 104, Authentication: CUSTOM2, Page Template: 1260921800703249
0.02: ...Determine if user "CJUSTICE" workspace "1122708729156622" can develop 
application "104" in workspace "1122708729156622"
0.02: ...ok to reuse builder session for user:APEX_PUBLIC_USER
0.02: ...Application session: 2529775339668942, user=APEX_PUBLIC_USER
0.02: ...Determine if user "CJUSTICE" workspace "1122708729156622" can develop 
application "104" in workspace "1122708729156622"
0.02: ...Check for session expiration:
0.02: Session: Fetch session header information
0.02: ...Metadata: Fetch page attributes for application 104, page 1
0.02: Fetch session state from database
0.03: Branch point: BEFORE_HEADER
0.03: Fetch application meta data
0.04: Setting NLS_DATE_FORMAT to application date format: MM/DD/YYYY
0.04: ...NLS: Set date format="MM/DD/YYYY"
0.04: Computation point: BEFORE_HEADER
0.04: Processing point: BEFORE_HEADER
0.04: Show page template header
0.05: Computation point: AFTER_HEADER
0.05: Processing point: AFTER_HEADER

That's just the header section.

Now OBIEE can fire off multiple queries for a single report and for that you would probably use the built-in Usage Tracking data...but you still wouldn't have a end-user experience there.

I created a simple APEX page with two reports. One is querying a 10 record table and the other is querying a copy of DBA_OBJECTS.

Check out the instrumentation surrounding the region:



That's the small table and it's pretty quick.

Now let's look at the big table:



You might be able to see up at the top of that last image, the 0.13 IR:Binding...then the 0.17: Printing rows

That'll give you an idea of how long each region takes to run (0.04) which would help you to identify slow parts of your web page. I've used this in the past and it's very nice.

Finally, you have the footer section:

 0.17: Computation point: AFTER_FOOTER
0.17: Processing point: AFTER_FOOTER
0.17: Log Activity:
0.18: Execute Count=0
0.18: End Show:

Basically, the page took 0.18 seconds to load. Start capturing that data (i.e. snapshot), make your changes and then re-evaluate. Alex put it very nicely in the comments:

In this case, it’s a project of migrating from one platform to another. While load simulation provides results (and that’s been done), end users experience (response time) is the only thing that counts.

Without measuring it, users have full control on how they relay their experience to you and there is nothing you can prove or disprove.

Measuring it gives all the answer (and lots of power!).