On Mar 15, 2010, at 1:44 PM, Baiss Eric Magnusson wrote:
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.
That does not surprise me.
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.
You won't, that setting only affect display. You need to use
ERXBatchingDisplayGroup.
Chuck
| | | | | +-[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
--
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 (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
