I have given some thought to creating a Cache component that could cache its
contents for a specified period of time. I.e.
public void renderComponent(...)
{
if (cacheIsEmpty || cacheIsExpired)
{
renderWrapped(); // magically caching results as well
}
else
{
writer.printRaw(previouslyCachedResults);
}
However, I'm loath to do this ... primarily because I'm nervous about giving
the developer the rope needed to easily hang themself.
There's a lot of interaction during a Tapestry render; component are
communicating with each other, the IRequestCycle and often the Body.
Imagine if you cached a block that included a Script component. On the
first render, the Script would execute and ask the Body to include some
additional JavaScript. On a subsequent render, the cached information would
include JavaScript calls ... but since the Script doesn't actually render,
the JavaScript isn't generated.
There are similar cases involving the unique id's served up by the Body and
IRequestCycle.
More caching problems: do you cache for a single user, for a single locale,
etc.
Finally, theres' the issue of URLs which may have to be encoded with the
caller's HttpSession id.
Some of these problems could be addressed by various clever approaches; for
example, instead of recording the cached block as a StringBuffer, you could
try and cache the interactions between objects. However, that starts to
make my brain buzz ... Tapestry is just too open ended to allow this to work
properly.
I think a better choice would be to come up with an application-specific
query caching strategy. If you could cache the results of database queries
efficiently than Tapestry can quickly generate the appropriate HTML. If I
*ever* get a chance to work on Sabertooth again ... it'll have a lot of
smart caching built in.
----- Original Message -----
From: "Luis Neves" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 09, 2002 9:18 AM
Subject: [Tapestry-developer] Tapestry and Caching
>
> Hello all,
>
> I was reading the Documentation of the Resin servlet Engine today
> specifically the part about caching:
> http://www.caucho.com/products/resin/ref/caching.xtp
>
> I thought to myself ... let's try that.
> In my Application servlet I overloaded the "doservice" method like this:
>
> protected void doService(
> HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException
> {
> long now = System.currentTimeMillis();
> response.setDateHeader("Expires", now + 43200);
> super.doService(request, response);
> }
>
> And then I run some tests.
> The application I tested makes frequent calls to
> database(straight JDBC calls) and some of the queries use 5
> joins on very large tables.
> Although the performance of Tapestry is great the CPU load of
> the machine is very high (the web server and the DB server
> are on the same machine)
> I was blown away....
>
> Page with database Calls
> 100 users - 1.0 second think time
> **********************************************************
> Results before cache
> 35 pages/sec | ResponseTime 600 ms | CPU Load 90%
>
> Results after cache
> 105 pages/sec | ResponseTime 10 ms | CPU Load 10%
> **********************************************************
>
>
> Simple Tapestry Page with no database Calls
> 100 users - 1.0 second think time
> **********************************************************
> Results before cache
> 95 pages/sec | ResponseTime 65 ms | CPU Load 40%
>
> Results after cache
> 116 pages/sec | ResponseTime 3 ms | CPU Load 10%
> **********************************************************
>
>
> My lack of knowledge about servlet engines, Tapestry and in
> general all things Java leaves me with some questions:
>
> 1 - Does this work only on Resin?
> 2 - Would it be possible to implement some sort of
> fine-grained caching in Tapestry, something like putting a
> xml tag in the JWC file similar to this:
> <use-cache duration="15min" cache-by-property="foobar">.
> 3 - If possible, how hard it is?
> I would like to contribute do this project with something
> that was useful and within my skills
>
>
> Best regards,
>
>
> Luis Neves
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> Tapestry-developer mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
