On Thu, Sep 30, 2010 at 10:07 AM, Felix Meschberger <[email protected]> wrote: > Hi, > > On 30.09.2010 15:43, Ian Boston wrote: >> >> 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 looks like an elegant solution to me (ok, I am biased because it > just reuses my own stuff ;-) ). > > +1 > > Regards > Felix
Made one nit-picky comment on the code, but otherwise +1. Would also like to see an integration test :) That said, I'm still confused as to why Pax Web filter registration isn't working for you, but I agree it would be appropriate to have support for "container"-level filters like this. Justin > >> >> 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 >>>> >>>> >> >> >
