Re: ERProfiling analysis, next step
Re: ERProfiling analysis, next step
- Subject: Re: ERProfiling analysis, next step
- From: Chuck Hill <email@hidden>
- Date: Thu, 18 Mar 2010 18:20:28 -0700
On Mar 18, 2010, at 5:45 PM, Baiss Eric Magnusson wrote:
| | | | | +-[1465.20ms / 29%] SQL (select): entity=Transaction,
qualifier=null, {rows=5611}
| | | | | | +-[72.50ms / 1%] SQL (evaluate): SELECT t0….(proprietary)
this is saying that 30% of your time is spent reading 6000 results
from this query .. .
1) that's a big result,
2) there are either tons of columns or a slow database connection.
Maybe just too many single statements that should be batched?
select * from sometable where id = z;
...if you see a lot of these, it implies that you're not batching
effectively. you can either manually batch fault those, or you can
turn on automatic batch faulting in wonder.
I changed 2 WODisplayGroups from having no specified batch count,
i.e. infinity? to 40 and 200 respectively. Actual count was 31 and
5611 as seen below, I didn't notice any change in the time.
You won't, that setting only affects display. You need to use
ERXBatchingDisplayGroup.
I do three different aggregating calculations on those 6000 records,
they only have 19 columns but have nine related tables, into which
the calculations get stored.
I am not 100% sure what you mean. To use ERXBatchingDisplayGroup,
all the qualifying and sorting has to be done on the database.
I get a null exception (below) occurring if I switch from
ERXDisplayGroup to ERXBatchingDisplayGroup.
The error occurs before the WOComponent constructor.
Without a stack trace and the rest of the information, I'd guess a
config or build issue on your machine.
Is the direction of somehow re-writing the usage of the
WODisplayGroup to use batching, a recommended direction?
Yes. And it has been done and it is called
ERXBatchingDisplayGroup. :-)
In both the main Component on the page and a Sub-Component there are
two WODisplayGroups referencing the same table; and then two more
WODisplayGroups in the Sub-Component.
****** ERXBatchingDisplayGroup exception ******
com.webobjects.foundation.NSForwardException
[java.lang.reflect.InvocationTargetException]
null:java.lang.reflect.InvocationTargetException
The below, from the same page as above, is another 15% but it is
only a simple fetch of the month of the year records, from a
EOSharedEditingContext?
| | | | | +-[686.13ms / 14%] SQL (select): entity=Months,
qualifier=null, {rows=13}
| | | | | | +-[679.17ms / 13%] SQL (select): entity=Months,
qualifier=null, {rows=13}
| | | | | | | +-[ 4.36ms / 0%] SQL (evaluate): SELECT
t0."MONTH_NUM", t0."THE_MONTH" FROM "MONTHS" t0
| | | | | | +-[ 4.37ms / 0%] SQL (evaluate): SELECT t0."MONTH_NUM",
t0."THE_MONTH" FROM "MONTHS" t0
I am running this profiling while in a WOLips debug launch. It seems
like I should run from a deployed version?
That may change the total ms but is unlikely to alter the percentages
much or change the fact that there is a problem here.
I still find nothing out of the ordinary in the 3 pages of SQL
generated by the profiler, (other than the speed).
And quantity!
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden