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