Optimization Questions

["Shannon, Andrew" <Sh...@darden.virginia.edu>]

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

shannona@darden.virginia.edu

 

 

Re: Optimization Questions

[Geoff Longman <gl...@gmail.com>]

Here's a little bit of info that might help. Each instance of a page,
including all of it's component tree is 'constructed' only once. At
the end of the request the newly constructed page is put in the pool.
Tapestry "cleans" the page, actually it's called 'detach', The page
instance that goes into the pool is clean in that no data exists in it
that would tie it to one user. Thus a single page instance can service
the request of any user in the system.

When the next request comes for that page, Tapestry checks the pool.
If an instance of the page is in the pool, it's pulled out and
reattached to the user session (session is a bad word to use here,
there may be no HttpSession involved if the app is running stateless).

So on the second request, the page came out of the pool and no page
instantiation/tree building happens. You never have to pay that price
again (for that instance).

Unless, our instance is out of the pool servicing a request when a
second request arrives for the exact same page. Rather than wait
Tapestry will pay the price to instantiate a second instance of the
page. When the first and second requests are done, the page pool now
contains two instances of the page.

But even then the cost of instantiating the second page is much less
the second time as the the cost of building the specification objects
(xml or annotations or xml+annotations) has already been paid for the
page and all the component in that page's component tree.

The specification objects for components are not tied to any single
page instance and are only created once. The are the blueprint for
instantiating a page/component.

If you are the only user of the application, say on your development
machine, then the page pool will always remain small and never have
more than one instance of each page that you visit.

Components themselves are "in the pool" only by the fact that an
instance of a component must exist in the component tree of a page
instance. Since the pool only caches pages you don't see any
components included in the pool size (although there may be many in
there, all found in the tree of the page instances of the pool).

Some more comments inline..

On 2/9/06, Shannon, Andrew <Sh...@darden.virginia.edu> wrote:
> 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.
>

Invest in a good profiler. JettyLauncher used to be integrated with
the Eclipsecolorer profiler but the profiler doesn't seem to work well
in Eclipse 3.1.X (you could try an install of Eclipse 3.0
+JettyLauncher + Eclipsecolorer just for profiling).

>
>
> 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.
>

see the first chunk of text I wrote above. The penalty you pay for
page instances is well managed by Tapesty for scalibility.

>
>
> 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.
>

Again, if you are the only user hitting the application, no other
simultaneous users, the the page pool will remain quite small.

>
>
> Does the value of 3 indicate that there are only 3 pages/components in
> the pool?

3 pages only.

>
> Is there a max pool size (I haven't found it in the source)?

I don't recall the max size

>
> Can the pool grow?

Sure. It grows whenever a request comes in for a page and there isn't
already an instance of said page in the pool.

>
> Do newly created instances get put in the pool after the response, or
> are we killing the garbage collector?

page instances are put in the pool. The garbage collector deosn't come
into play unless you have turned off page caching ...
-Dorg.apache.tapestry.disable-caching=true

>
> 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?

Probably not necessary. The existing pool is well implemented and
there are high volume sites out there that (NHL.com and
TheServerSide.com) that have not replaced the pool. Somebody correct
me if I'm wrong! (I've never heard of anyone replacing the pool
implementation).

>
> Am I even on the right track with these questions?
>

Sure! what's off track anyways? Sound like you need to learn more
about how the guts of Tapestry work!

>
>
> 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?
>

Putting component into a library will have no effect on the page
instance creation or pool useage/size. Libraries (namespaces really)
are part of those specification blueprints I mentioned waaay up near
the top of this reply. Constructing pages with Library components has
the same cost as any other component.

>
> 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.

I'm not sure I understand what you are doing. If it's conditionally
rendering, the components are always instantiated, they may just not
render. If it's Block/RenderBlock for dynamic content - they are still
all instantiated regardless if they are rendered or not.

But as I said, the minimum number are instantiated and pages
containing them are shared via the page pool. Extras are only created
when new instances of a page are needed (when multiple, simulataneous,
requests for the same page arrive).

>
>
>
> 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?
>

Frankly, the Tapestry tier has never been the dog performance wise in
any of the apps I've built over  the last 4 (or is it 5?) years. It's
usually a query that is in dire need of optimization or some
overzealous fetching of object by a misconfigured ORM framework.

I would recommend a good profiler.

As always, I happily stand by, ready to be corrected!



Geoff

>
>
> Thanks in advance for your help,
>
>
>
> Andrew
>
> shannona@darden.virginia.edu
>
>
>
>
>
>
>


--
The Spindle guy.          http://spindle.sf.net
Get help with Spindle:   
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog:                     http://jroller.com/page/glongman
Feature Updates:          http://spindle.sf.net/updates

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org