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