roller-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave <snoopd...@gmail.com>
Subject Re: Roller's implementation on conditional Get
Date Wed, 26 May 2010 11:59:53 GMT
On Wed, May 26, 2010 at 12:11 AM, (David) Ming Xia
<david.ming.xia@ibol.biz> wrote:
>    I took a look into it and I found another place that has very intensive database
queries.
>
>    RequestMappingFilter.doFilter() --> WeblogRequestMapper.handleRequest().
>
>   RequestMapingFilter's URL mapping is /*, so it check every http request.
>
>   WeblogRequestMapper.handleRequest() verifies ALL requests, I mean, including those
css, js and image files with named JPA queries.
>
>
>   Actually,  both PageServlet and RequestMappingFilter query weblog with handle. 
It looks like database is used as hashtable in these two functions.   While database is usually
used for account data transaction, relational data management.
>
>   Now for each web page request there are at least 'eleven' database queries, one for
the text/html content in PageServelt and ten requests in mapping filter for everything including
the text/html.
>
>   I feel that there could be even more database wires.  Since many people work on Roller
and everyone tends to add some more wires.
>
>    It seems that there should be a top-down design solution for this issue.
>
>     Like to hear something from you.

Hi David,

You are correct, WeblogRequestMapper is invoked on every request, but
does nothing when it encounters URLs that begin with these patterns:

   rendering.weblogMapper.rollerProtectedUrls=\
   roller-ui,images,theme,themes,CommentAuthenticatorServlet,\
   index.jsp,favicon.ico,robots.txt,\
   page,flavor,rss,atom,language,search,comments,rsd,resource,xmlrpc,planetrss

It ignores static theme resources (images, CSS, JS, etc.) and
everything else that is not dynamically generated by a weblog page
template. Perhaps the problem is not quite as bad as you think.

There have not been that many people working on Roller and the ones
that have worked on the code have been pretty disciplined about when
database calls are made. But of course, even disciplined developers
make mistakes. I'm sure there is much room for improvement and I
encourage you to continue your research into performance bottlenecks.

If you have a proposal for a top-down solution, or some patches to
improve things -- I'd be happy to review them or even commit them for
you if they look good.

- Dave

Mime
View raw message