Using "futures" to parallelize rendering of components

[cfineman <cf...@gmail.com>]

We have an app that's an aggregation of several 'components' (not yet written
in Tapestry... using an older in-house framework). Although each component
is not very expensive to create, the aggregate cost can get kinda high
sometimes.

I've been poking around Tapestry for the past couple of days trying to see
if I can figure out an elegant way to launch of bunch of "futures" at the
start of rendering and then join with them in the "@BeginRendering" handler.

The simplest way I could think to do it is by creating a "@PageAttached"
handler in the components that are to be rendered in a farm and creating the
"future" in that method.

I was hoping to find a way to do it in a "container" component that all the
"futured" components were in and then crawl the component tree invoking the
future on each component with an appropriate tag (perhaps using mixins).
However, there does not seem to be a public way to gain access to the
component tree (the public interfaces don't seem to support this). 

Keep in mind, I would like to be able to render most of the page server-side
if possible (otherwise I would have just created a bunch of
javascript-populated divs).

Was hoping to find some slick extension point in Tapestry but it feels like
I've not identified the most elegant solution. Does the PageAttached (or
perhaps, activate??) feel like the right way to go? Any other suggestions?
-- 
View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23353811.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: Using "futures" to parallelize rendering of components

[Ben Gidley <be...@gidley.co.uk>]

It is perfectly possible to implement a HTML caching component - we have one
for our site. I am working on getting permission to open-source it.
It is a really simple bit of code and seems to work robustly without too
many gotchas.


Ben Gidley

www.gidley.co.uk
ben@gidley.co.uk


On Sun, May 3, 2009 at 11:10 PM, cfineman <cf...@gmail.com> wrote:

>
>
>
> Thiago H. de Paula Figueiredo wrote:
> >
> > Have you done any profiling to know exactly how much time your
> application
> > is spending rendering? Most of the time bottlenecks are in other places
> > (specially in the database).
> >
>
> It's not really the rendering that I'm concerned about but rather the
> ability to treat each of the components as a separate, independent "widget"
> (possibly dynamically chosen) that could also be re-used by the outside
> world... each one is it's own little MVC. The "pipeline" will also enforce
> an SLA on each of the widgets. I want to do it server-side because there
> are
> SEO implications if it's done with AJAX.
>
> I'm not sold on the approach but I'm exploring options. Anyway, I'll just
> have to ask you to give me the benefit of the doubt on this one; I've been
> around the block a few times and I've got a good sense of the trade-offs
> (including db optimization, caching etc). I'm not dismissive of the points
> you and the other poster raised (far from it)... just saying they are
> already in the mix of considerations.
>
>
>
> So now back to what I *want* to talk about ;-)
>
> I understand that it's a queue but the queue still implements an in-order
> walk of the component tree (e.g. sibling A's setupRender....cleanupRender
> happens entirely prior to sibling B's setupRender...cleanupRender).
>
> The more I think about it, the more it seems like the "Attached" or
> "Activate" handler is the way to go since this is more of a "model
> construction time" notion than a "render time" notion.
>
> --
> View this message in context:
> http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23360451.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Using "futures" to parallelize rendering of components

[cfineman <cf...@gmail.com>]

Thiago H. de Paula Figueiredo wrote:
> 
> Have you done any profiling to know exactly how much time your application  
> is spending rendering? Most of the time bottlenecks are in other places  
> (specially in the database).
> 

It's not really the rendering that I'm concerned about but rather the
ability to treat each of the components as a separate, independent "widget"
(possibly dynamically chosen) that could also be re-used by the outside
world... each one is it's own little MVC. The "pipeline" will also enforce
an SLA on each of the widgets. I want to do it server-side because there are
SEO implications if it's done with AJAX.

I'm not sold on the approach but I'm exploring options. Anyway, I'll just
have to ask you to give me the benefit of the doubt on this one; I've been
around the block a few times and I've got a good sense of the trade-offs
(including db optimization, caching etc). I'm not dismissive of the points
you and the other poster raised (far from it)... just saying they are
already in the mix of considerations.



So now back to what I *want* to talk about ;-)

I understand that it's a queue but the queue still implements an in-order
walk of the component tree (e.g. sibling A's setupRender....cleanupRender
happens entirely prior to sibling B's setupRender...cleanupRender). 

The more I think about it, the more it seems like the "Attached" or
"Activate" handler is the way to go since this is more of a "model
construction time" notion than a "render time" notion.

-- 
View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23360451.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: Using "futures" to parallelize rendering of components

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

Have you done any profiling to know exactly how much time your application  
is spending rendering? Most of the time bottlenecks are in other places  
(specially in the database).

By the way, Tapestry does not have a rendering tree, but a rendering  
queue. No recursion is used when rendering a page or component.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

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

Re: Using "futures" to parallelize rendering of components

[cfineman <cf...@gmail.com>]

Just realized I need to clarify something... the future would be making an
HTTP request to retrieve the raw HTML (aka the "guts") of the component and
that would get inserted into the final DOM verbatim.
-- 
View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23356755.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: Using "futures" to parallelize rendering of components

[Robert Zeigler <ro...@scazdl.org>]

I'm not sure I fully understand your use-case.

You want to parallelize the rendering of the page?
You could potentially do that, but it would be tricky as tapestry goes  
to great lengths to ensure that pages and components are "POJO", so  
you don't have to worry about threading.
Parallelizing means you're re-introducing threads, basically.  But,  
again, I'm not sure I fully understand what you're trying to achieve.   
You mentioned elsewhere that each (or at least the majority) of these  
futures would have to perform an http request... so it sounds like you  
want to composite a page from disparate html sources? Can you clarify  
what you're trying to accomplish?

Robert

On May 3, 2009, at 5/33:48 AM , cfineman wrote:

>
> We have an app that's an aggregation of several 'components' (not  
> yet written
> in Tapestry... using an older in-house framework). Although each  
> component
> is not very expensive to create, the aggregate cost can get kinda high
> sometimes.
>
> I've been poking around Tapestry for the past couple of days trying  
> to see
> if I can figure out an elegant way to launch of bunch of "futures"  
> at the
> start of rendering and then join with them in the "@BeginRendering"  
> handler.
>
> The simplest way I could think to do it is by creating a  
> "@PageAttached"
> handler in the components that are to be rendered in a farm and  
> creating the
> "future" in that method.
>
> I was hoping to find a way to do it in a "container" component that  
> all the
> "futured" components were in and then crawl the component tree  
> invoking the
> future on each component with an appropriate tag (perhaps using  
> mixins).
> However, there does not seem to be a public way to gain access to the
> component tree (the public interfaces don't seem to support this).
>
> Keep in mind, I would like to be able to render most of the page  
> server-side
> if possible (otherwise I would have just created a bunch of
> javascript-populated divs).
>
> Was hoping to find some slick extension point in Tapestry but it  
> feels like
> I've not identified the most elegant solution. Does the PageAttached  
> (or
> perhaps, activate??) feel like the right way to go? Any other  
> suggestions?
> -- 
> View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23353811.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org


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

Re: Using "futures" to parallelize rendering of components

[cfineman <cf...@gmail.com>]

Thanks for the response Ville,

Caching the component wont always work well since these are dynamically
rendered. Certainly we will consider caching when appropriate but, for
example, sometimes it's specialized by the user. 

Also, much of this content is provided by non-Tapestry sources (we have a
legacy content service that probably won't get ported over immediately).

Effectively I'd like to be able to send off some subset of the components to
a "render farm" and then use tapestry to do the final assembly. The
challenge (in my mind) is to be able to do this without having to explicitly
link the components to their parent (I had thought about investigating
hooking in to the class transformation code but that felt like the wrong way
to go).

It's not too hard to write this by hand (without using tapestry) but since
we are starting to use tapestry for the rest of our front-end I was hoping
we could stay within the T5 framework for this as well. 

Hope this clarifies what I'm after (or more the the point... I hope I didn't
further muddy the waters! going to get coffee now :-) )




Hi,

Don't really understand the question, but if you're having perfomance
problems then caching would be the way to go?

You can use blocks to separate what ever you wish to wrap as T5 components
and place them to one central page, from which those blocks can be used.

T5 caches all pages and components in it's own pools, and you can mark
content that can be cached with @Retain annotation.

I hope this gives some ideas,

 - Ville


-- 
View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23356900.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: Using "futures" to parallelize rendering of components

[Ville Virtanen <vi...@cerion.fi>]

Hi,

Don't really understand the question, but if you're having perfomance
problems then caching would be the way to go?

You can use blocks to separate what ever you wish to wrap as T5 components
and place them to one central page, from which those blocks can be used.

T5 caches all pages and components in it's own pools, and you can mark
content that can be cached with @Retain annotation.

I hope this gives some ideas,

 - Ville


cfineman wrote:
> 
> We have an app that's an aggregation of several 'components' (not yet
> written in Tapestry... using an older in-house framework). Although each
> component is not very expensive to create, the aggregate cost can get
> kinda high sometimes.
> 
> I've been poking around Tapestry for the past couple of days trying to see
> if I can figure out an elegant way to launch of bunch of "futures" at the
> start of rendering and then join with them in the "@BeginRendering"
> handler.
> 
> The simplest way I could think to do it is by creating a "@PageAttached"
> handler in the components that are to be rendered in a farm and creating
> the "future" in that method.
> 
> I was hoping to find a way to do it in a "container" component that all
> the "futured" components were in and then crawl the component tree
> invoking the future on each component with an appropriate tag (perhaps
> using mixins). However, there does not seem to be a public way to gain
> access to the component tree (the public interfaces don't seem to support
> this). 
> 
> Keep in mind, I would like to be able to render most of the page
> server-side if possible (otherwise I would have just created a bunch of
> javascript-populated divs).
> 
> Was hoping to find some slick extension point in Tapestry but it feels
> like I've not identified the most elegant solution. Does the PageAttached
> (or perhaps, activate??) feel like the right way to go? Any other
> suggestions?
> 

-- 
View this message in context: http://www.nabble.com/Using-%22futures%22-to-parallelize-rendering-of-components-tp23353811p23356193.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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