On 30 Sep 2010, at 13:52, Felix Meschberger wrote: > 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.
http://codereview.appspot.com/2333042 This allows the registration of Filters right at the start of the servlet before anything happens. The filters don't have access to any of the Sling framework, but in my caching case a get several times more throughput, and concurrency by doing this. Filters are registered with scope = "Container" and should bind to HttpServletRequest and HttpServletResponse rather than the Sling variants. WDYT? Still looking at the sync issues further down the stack. Ian >> >>> >>>> >>>> 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 >> >>
