We're working to optimize our Tapestry 3.0.3 app that under load (a few
thousand concurrent users in a cluster) slows down significantly. We've
been optimizing our interaction in the middleware and db, however, the
web tier is still the bottleneck. So I have a few comments/questions I
would greatly appreciate insight on.
I think I am mostly entendido on how the component tree is built during
page construction, but am concerned about the overuse of a core
component ('X') that conditionally includes 25 or so other components
that are programmatically encapsulated in this same component.
One thing I researched but still am not fully clear on is the pool.
Component X is included in form Y, so each time form Y is loaded we need
umptine instances of component X. I seem to think that since X also
includes 25 other component definitions (all referring back to itself)
that this would incur yet umptine more instances of X each time its
parsed. Does this make sense? If so, my concern is on how effective is
the pool. It would seem like the pool is pretty much in a constant
state of exhaustion and that new instances are continuously created.
I printed out the pool.keyCount, pool.pooledCount and pool.window values
but I don't understand the values. keyCount and pooledCount ALWAYS = 3.
The window is its default of 10.
Does the value of 3 indicate that there are only 3 pages/components in
the pool?
Is there a max pool size (I haven't found it in the source)?
Can the pool grow?
Do newly created instances get put in the pool after the response, or
are we killing the garbage collector?
It doesn't seem like we have much control over the pool, so should we
override it for our engine definition and create a custom pool?
Am I even on the right track with these questions?
We plan to break out many, if not all, of the 'sub-components' in X and
add them into a library. So if the pool and overuse of component X is a
problem, will this strategy alleviate latency?
Using the library, we would still need to conditionally feed these
components to Form Y (this site is heavy on dynamic forms). I've not
found postings yet on how this can be achieved, yet avoid component
instantiation for components conditionally excluded but seem to get
parsed/instantiated simply because their in the specification.
Does anyone have a similar situation that you'd be willing to share your
strategy?
What are some of the optimization techniques y'all have done to reduce
load issues in the Tapestry tier?
Thanks in advance for your help,
Andrew
[EMAIL PROTECTED]
