Sling, rendering and multicore architectures

[Olaf Otto <ol...@x100.de>]

Hi all,

I would like to gather a few ideas concerning a granular, perhaps even 
generic approach to better using multicore architectures in Sling.

First, some context:
Basically, I am facing a scenario where we are running a rather 
sophisticated web application (lot's of dynamic stuff, closed user 
groups, content inheritance, personalized navigation and the like). The 
complexity is well under control using a decent bundle-based 
modularization in conjunction with Spring, Adaptable etc. Currently, we 
have page rendering times* of about 300 - 500ms (with 0 caching 
whatsoever) on a multicore architecture with few but high powered cores 
(Intel xeon 3.5 Ghz+). However, some of our target platforms are SPARCs 
featuring many, but not very powerful cores (e.g. 1.2 Ghz per Thread, 
32+ Threads). On such an architecture, the rendering time reaches around 
1.5 - 3 Seconds, while, given the known average loads, most of the 
available CPUs are completely idle. We are working on reducing the 
rendering times further, but profiling clearly shows that there is not 
enough room for optimization left to bring this down to our goal of 500ms.

* This means the time to render the complete HTML on the server side.

Now, I'd of course like to make better use of the multicore architecture 
for rendering. However, it appears that parallel rendering of JSPs is a 
violation of specs (see for example this discussion: 
http://osdir.com/ml/java.jasig.uportal.devel/2006-09/msg00094.html). 
What I am wondering is if there is something in Sling that could be used 
to achieve parallel rendering, even if just for some dedicated 
components. I am thinking in the area of includes or maybe by extending 
the sling scripting support for JSPs.

Some constraints for the sake of a greater challenge:
- Changing the target architecture is not an option in the near future
- Likewise is shifting some stuff to the client (i.e. more AJAX)
- Caching is *not* the solution (we can only do this for part of the 
content, but the load times have to be acceptable when the cache is 
cleared...).
- There is a 2 GB memory limit, thus thread contention means quick death :-)

Any ideas, hints or opinions are highly appreciated.

Regards,
Olaf

Re: Sling, rendering and multicore architectures

[Ian Boston <ie...@tfd.co.uk>]

Hi,
If you intend to service more users than you have cores, then I am not
certain that making rendering of a single page operate concurrently is
going to help, since as soon as you have a few users using the system,
Sling will be using all available cores to concurrently serve
requests. A typical Sling installation under load may have many free
running request threads using all cores and saturating all available
I/O channels. Its normally I/O thats the bottleneck.

Having said that, if you have JSP pages that renders slowly because of
I/O and you need to interleave that, you might consider encapsulating
parts of the page rendering operations inside java Future objects and
dispatching them to a concurrent queue to be processed by an army of
worker threads. (The SPI in Apache Shindig did this to enable
deployment into muti box environments (thrift & protobuf etc))

Personally I would look carefully at the architecture and question
every operation thats making the JSP page take such a long time to
build (1-3s is an age when many take 10-20ms), rather than trying to
scatter the processing of a single JSP onto all cores. Under real user
load, all those cores are not going to be idle.

Could you share with us what the JSP page does and how it gets its
data for rendering ?

Ian




On 14 November 2012 09:32, Olaf Otto <ol...@x100.de> wrote:
> Hi all,
>
> I would like to gather a few ideas concerning a granular, perhaps even
> generic approach to better using multicore architectures in Sling.
>
> First, some context:
> Basically, I am facing a scenario where we are running a rather
> sophisticated web application (lot's of dynamic stuff, closed user groups,
> content inheritance, personalized navigation and the like). The complexity
> is well under control using a decent bundle-based modularization in
> conjunction with Spring, Adaptable etc. Currently, we have page rendering
> times* of about 300 - 500ms (with 0 caching whatsoever) on a multicore
> architecture with few but high powered cores (Intel xeon 3.5 Ghz+). However,
> some of our target platforms are SPARCs featuring many, but not very
> powerful cores (e.g. 1.2 Ghz per Thread, 32+ Threads). On such an
> architecture, the rendering time reaches around 1.5 - 3 Seconds, while,
> given the known average loads, most of the available CPUs are completely
> idle. We are working on reducing the rendering times further, but profiling
> clearly shows that there is not enough room for optimization left to bring
> this down to our goal of 500ms.
>
> * This means the time to render the complete HTML on the server side.
>
> Now, I'd of course like to make better use of the multicore architecture for
> rendering. However, it appears that parallel rendering of JSPs is a
> violation of specs (see for example this discussion:
> http://osdir.com/ml/java.jasig.uportal.devel/2006-09/msg00094.html). What I
> am wondering is if there is something in Sling that could be used to achieve
> parallel rendering, even if just for some dedicated components. I am
> thinking in the area of includes or maybe by extending the sling scripting
> support for JSPs.
>
> Some constraints for the sake of a greater challenge:
> - Changing the target architecture is not an option in the near future
> - Likewise is shifting some stuff to the client (i.e. more AJAX)
> - Caching is *not* the solution (we can only do this for part of the
> content, but the load times have to be acceptable when the cache is
> cleared...).
> - There is a 2 GB memory limit, thus thread contention means quick death :-)
>
> Any ideas, hints or opinions are highly appreciated.
>
> Regards,
> Olaf
>
>
>
>

Re: Sling, rendering and multicore architectures

[Sarwar Bhuiyan <sa...@gmail.com>]

Hi Olaf,

Maybe not necessarily for the rendering part itself but I was wondering if
there's some sort of pre-processing/loading of data that could be done
using the quartz jobs and storing that somewhere.  Then during rendering
you don't have to do so much processing before rendering.  Just grab the
data and render it.  Also, there's some background servlet now which might
be a way to submit certain tasks to be performed in the background.
 Coupled with polling, that could perhaps do what you want using threads.

The other option maybe is to break up the rendering in your components into
some parts which can be called using AJAX calls to html or JSON so those
things can happen in the background and are cacheable.  This of course
doesn't use multiple cores but at there might be at least the impression
that the page is loading faster.

Caching in application gets tricky when dependencies come into the picture
and you have to flush/load data based on lots of variables.  I would
however, look at how to call certain resources so that they can be
cacheable in the dispatcher and/or browser.  Sort of like how the top nav
is done on geometrixx.

Hope to see others' ideas on this problem.


Sarwar

On Tue, Nov 13, 2012 at 10:32 PM, Olaf Otto <ol...@x100.de> wrote:

> Hi all,
>
> I would like to gather a few ideas concerning a granular, perhaps even
> generic approach to better using multicore architectures in Sling.
>
> First, some context:
> Basically, I am facing a scenario where we are running a rather
> sophisticated web application (lot's of dynamic stuff, closed user groups,
> content inheritance, personalized navigation and the like). The complexity
> is well under control using a decent bundle-based modularization in
> conjunction with Spring, Adaptable etc. Currently, we have page rendering
> times* of about 300 - 500ms (with 0 caching whatsoever) on a multicore
> architecture with few but high powered cores (Intel xeon 3.5 Ghz+).
> However, some of our target platforms are SPARCs featuring many, but not
> very powerful cores (e.g. 1.2 Ghz per Thread, 32+ Threads). On such an
> architecture, the rendering time reaches around 1.5 - 3 Seconds, while,
> given the known average loads, most of the available CPUs are completely
> idle. We are working on reducing the rendering times further, but profiling
> clearly shows that there is not enough room for optimization left to bring
> this down to our goal of 500ms.
>
> * This means the time to render the complete HTML on the server side.
>
> Now, I'd of course like to make better use of the multicore architecture
> for rendering. However, it appears that parallel rendering of JSPs is a
> violation of specs (see for example this discussion:
> http://osdir.com/ml/java.**jasig.uportal.devel/2006-09/**msg00094.html<http://osdir.com/ml/java.jasig.uportal.devel/2006-09/msg00094.html>).
> What I am wondering is if there is something in Sling that could be used to
> achieve parallel rendering, even if just for some dedicated components. I
> am thinking in the area of includes or maybe by extending the sling
> scripting support for JSPs.
>
> Some constraints for the sake of a greater challenge:
> - Changing the target architecture is not an option in the near future
> - Likewise is shifting some stuff to the client (i.e. more AJAX)
> - Caching is *not* the solution (we can only do this for part of the
> content, but the load times have to be acceptable when the cache is
> cleared...).
> - There is a 2 GB memory limit, thus thread contention means quick death
> :-)
>
> Any ideas, hints or opinions are highly appreciated.
>
> Regards,
> Olaf
>
>
>
>
>