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