At the time I wrote the paper I was quite disillusioned that the mind set in the industry around End to End was that a transaction was a technical transaction that could be measured by the technical staff i.e. a piece of SQL.
So when a user wants to know why "its" slow they get the description of the response time something like this….
But this form of transaction (business) is made up of a large number number of activities, forms and SQL code. As these could not be linked by the technicians this form of transaction was largely ignored.
There are two real measures of response time:
This is one of the very useful programs Oracle provide.
1: You have to run it ( every 10 minutes by default) 2: It does the same thing every time it runs (consistent activity) and exercises a good portion of the application
So the run time of this program will represent the overall performance of the database.
If the database is working hard the runtime will be longer…
So plotting the response time of this program is a very good indicator of the overall performance of the application, and the charts look good even to the most system illiterate staff.
Eg.. Creation and approval of a purchase order..
Workflow records the start time and the end time for each PO workflow.
Now you have the response time of a business transaction.
In this case the response time of a form < 1 minute becomes irrelevant in the overall transaction that could take a week.
The ability to collect technical transactional details (eg. round trips and execution of an SQL statement) are often mistakenly referred to as end-2-end, which are then usually defined as a response time which eventually make their way into an SLA.
The fact that an SQL statement took 300 milliseconds at router ABC and 3.2 seconds at the database might be useful in diagnosing a performance issue it is basically irrelevant to the business owner / user.
This presentation will present a business focus covering the following topics:
View / Download powerpoint from Irish Oracle User group dublin 2005 (.pps format)
Note: The Quest Software Spotlight on E-Business Suite product mentioned in this paper was deleted from the Quest product suite in July 2008.
Back in 2004, I wrote a piece of SQL to collect the runtimes of the FNDOAMCOL progam for the past seven (7) days into half hour segments including the average and standard deviations. The output was then pasted into an Excel spreadsheet that produced a chart. Worth a look but you will need to be able to run SQL.
Last update: May 2009