Hello Chuck and others, many thanks.
Here's my current status, I would be surprised to find out that it's at least
close to "as good as it gets", but that's where I stand now.
**********************
After my 1st abortive attempt at upgrading to FB5 from 4 I succeeded thanks to
Chuck's help with the following two steps from and to FrontBase.
WRITE ALL OUTPUT(DIR = '/.../financial/', TYPE = 'FrontBase', CONTENT =
TRUE);
script /.../financial/schema.sql;
Because of crash I lost the test db which allowed me to generate a better suite
from a more active account, grin.
I re-ran the profiling and didn't notice any speed increase, sigh.
I also don't see any of the <select *> type problems in the output.
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.
| | | | | +-[1465.20ms / 29%] SQL (select): entity=Transaction, qualifier=null,
{rows=5611}
| | | | | | +-[72.50ms / 1%] SQL (evaluate): SELECT t0….(proprietary)
| | | | | +-[29.57ms / 1%] SQL (select): entity=Account, qualifier=null,
{rows=31}
| | | | | | +-[23.16ms / 0%] SQL (evaluate): SELECT t0."ACCOUNT_ID", t0….
and some more
?
I await the much faster pipe three weeks from now.
On Mar 11, 2010, at 3:51 PM, Mike Schrag wrote:
>> I am hoping to learn how to utilize the ERProfiling information I am now
>> viewing.
>>
>> After the Main/Login page the Current Situation page comes up in 5000ms.
>>
>> Profiler: 5122.11ms; SQL: 52% (84); D2W: 0% (0); T/I/A: 0% / 85% / 14%
> it says:
> * your entire request took 5 seconds to process
> * of that 5 seconds, 52% of the 5s was spent in SQL
> * that 52% of SQL time was spent executing 84 queries
> * there was no D2W on this page
> * 85% of the 5s was spent in invokeAction
> * 14% of the 5s was spent in appendToResponse
>
> If you were to click on the 85% or 14% you'd see a breakdown of which queries
> happened where, or if you click on the "SQL" link you would get a breakdown
> of all the queries, shown in a tree with where they executed. 84 queries is a
> lot (for a "normal" app). from the SQL page, you will be able to see for each
> query how long each one took (absolute and %) and how many rows were returned
> (so you can look for overly large fetches).
>
> you can also look for queries that are of the form
> select * from sometable where id = x;
> select * from sometable where id = y;
>
> 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.
>
> ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
