Hi, On 30.09.2010 13:16, Ian Boston wrote: > > On 30 Sep 2010, at 09:15, Felix Meschberger wrote: > >>> >>> Ok, (& btw, thanks for the other pointers). >>> The reason I want to register the filter before Sling is the caching one >>> captures certain public responses before any processing and so should be a) >>> highly concurrent with the right cache and b) lightweight. >> >> Yes, I agree, that caching should be done as early as possible .... And >> to get most performance doing it before resolving the request resource >> and the servlet/script is probably a must. >> >> This reminds me of other discussions we had around caching and the >> question, whether it would be usefull to have a hook in the >> SlingMainServlet (or its helpers) to plug cache functionality ? > > That would make sense, I will look into a patch. > >> >>> >>> I dont know if its my machine or the way of testing but at the moment I can >>> only get a max of 600 request per seconds on a json properties GET, flat >>> regardless of concurrency out of sling. If I test Tomcat 6 on a html page I >>> get 6K/s and the throughput appears to have some relationship to the >>> concurrency of the requests. >> >> I don't want to start finger-pointing, but ... > > me neither, I just want to get a fix in place before it becomes a problem for > us. (and any one else). > >> >> It looks like Jackrabbit has some issues with concurrent reads. >> >> Setting up a test with a Java profiler allowing to measure thread >> contention (synchronization stuff) would probably show a hint (IIRC >> YourKit Profiler has such functionality). > > Good pointer, they were kind enough to give me a license of OS work. > >> >> Probably we have such contentions in Sling, too (would not surprise me), >> and we should work on that. > > Ok I will look into it. > > One more point of reference data. A Servlet registered in OSGi using the Pax > Web service has almost identical performance and concurrency compared to a > Jetty instance OOTB. In order of 2K request/s single threaded rising to 5K > request/s at 5 concurrent threads, but that is almost certainly fighting for > OSX thread resources on my box.
Yes, this makes sense because the layer between the actual Jetty processor and the Servlet is very thin (just a few calls). > > So this narrows the problem down to within the SlingMain Servlet and beyond, > I will look at that next. Yes, and here resource resolution and servlet resolution, both involving repository access amongst other things, come to mind. Regards Felix > Thanks > Ian > > > >> >> Regards >> Felix > >
