Re: slow app when having a lot of D2W rules ?
Re: slow app when having a lot of D2W rules ?
- Subject: Re: slow app when having a lot of D2W rules ?
- From: Jesse Tayler <email@hidden>
- Date: Thu, 21 Feb 2008 12:29:50 -0800
Based on what you describe, it's hard to tell
I don't know about the code there in the ERX..., but unless you've
defined a significant key, the results should not re-calculate unless
you change a significant key and that key is used in the rule in
question.
do you know what rule is causing this to fire? do you change the value
of any significant key in any loop at this time? if so, check the
propertyKey and rules associated with them to see what methods fire.
just seems like the rule you are after should not be firing more than
once, but still, it does seem to be firing -
so, seems like either a bug in the ERX code which you should be able
to see, or, more likely, a significant key is being changed and
therefore the system thinks that rule must be recalculated.
I did some time at the Netstruxr project and indeed, the team was
brilliant but over time, they somehow found ways to add more D2W rules
than could possibly be imagined. Literally thousands and thousands!
This Netstruxr code was released as these ERX utilities in WOnder.
While that company died a horrible dot-bomb death, the programmers
moved much of the architecture into opensource so that the code might
live on.
Anyway, I'd doubt that code would contain flaws which cause serious
performance issues because of the number of rules you are using --
therefore it seems logical that a significant key is firing a method
that requires time to return, and some loop is causing your
performance troubles by firing more often than required.
I guess some of this rule stuff is hard to trace, but it is likely not
as complicated as all this seems to suggest.
Good luck!
jess
On Feb 21, 2008, at 11:57 AM, Dominique Schoenenberger wrote:
Good to know, thank you. Here what we have found:
If we comment out the following ERD2WModel methods:
protected ObjectfireSystemRuleForKeyPathInContext(String keyPath,
D2WContext context)
protected Object fireRuleForKeyPathInContext(String keyPath,
D2WContext context)
and call super instead, we have found evidence to suggest the
performance problem is no longer there.
When we profiled the application we found that the application
spend more and more time in ERXMultiKey.equals and the number of
ERXMultiKey instances increases (while accessing the same list page)
Does this make any sense ?
Dominique
On 21 févr. 08, at 00:48, Anjo Krank wrote:
I got two apps with around 100-200 page configs and 1000-1500 rules
(~150 entities) and two others with ~50 entities, 70 pages and ~500
rules.
Netstruxr had (if memory serves) 2k rules, 1.2k pages, 600 entities.
Cheers, Anjo
Am 20.02.2008 um 19:31 schrieb Dominique Schoenenberger:
They are hand-written rules and may be between 400-500 page configs.
How many rules, page configs do you have in your application ?
Dominique
On 18 févr. 08, at 21:20, Anjo Krank wrote:
Just out of curiosity: are these hand-written rules? If yes, how
many page configs do you have?
Cheers, Anjo
Am 18.02.2008 um 20:51 schrieb Dominique Schoenenberger:
Our application has 6500 D2W rules (including rules from
JavaDirectToWeb and Wonder frameworks).
We noticed that the application become slower with time when we
have more than 4500 D2W rules. We don't know yet exactly what it
is but we would like to know if anybody has noticed something
when having a lot of D2W rules ?
Dominique
_______________________________________________
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@mac.com
This email sent to email@hidden
_______________________________________________
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