tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: Caching rendered page - reducing hits to the backend?
Date Mon, 01 Jun 2009 12:20:11 GMT

MG>hopefully brief comments

> From: rob@koberg.com
> To: users@tomcat.apache.org
> Subject: Re: Caching rendered page - reducing hits to the backend?
> Date: Mon, 1 Jun 2009 07:37:56 -0400
> 
> 
> On Jun 1, 2009, at 7:12 AM, Tim Funk wrote:
> 
> > Worrying is good. Making sure you have metrics is better. You can  
> > cache lots of different items such as
> > - stuff from the database
MG>connection pools can handle multiple connections with little or no startup load

> > - parts of a rendered page
MG>tiles/div tags/frames whats your preference?

> > - the entire page
MG>i assume you're referring to caching jsp's at the server?

> > - any combination of above
> >
> > But it really depends on where the bottlenecks are as you scale.  
> > Even if the DB has a few million entries, if there queries are  
> > "simple" and the database has enough memory - the database might  
> > never really be touching disk to return the results of your query  
> > not be your bottleneck.
MG>correct the less I/O the better
MG>this is a good design for static reporting
MG>but may cause bottlenecks for highly interactive websites

> >
> > The key is making sure you have the ability to log how long differnt  
> > things take. (And the ability to turn them on or off)
MG>define 'them'

>> Otherwise you  
> > are flying blind.
> 
> I think you can generally say that the less you have to do on the  
> server, the better.
MG>optimising server code and algorithms is always a good idea
MG>dumping proprietary algorithms, validation and or lookup code to client not good

 If you can generate out a page *as much as  
> possible*
MG>XSLT?
 so that only the really necessary dynamic components are  
> created at runtime, then it is better.
MG>you want to characterise startup load vs resolve runtime classes,entities
MG>carefully

> We use XSL/XML to pregenerate a JSP bringing all known page content/ 
> components.
MG>as do most templating engines e.g. Velocity and freemarker 
> 
> I don't see why you would be flying blind. Seems like a no-brainer.
MG>depends on who is piloting the craft?

> best,
> -Rob
MG>best, MG
> 
> 
> >
> >
> > -Tim
> >
> >
> > Andre-John Mas wrote:
> >> Hi,
> >> Much of the content on the site which I am in the process will be  
> >> semi-static, and I want to be able to cache the rendered pages to  
> >> reduce database hits. To explain:
> >> A given page will depend on dynamic data that is stored in the  
> >> database, but that data is updated about once a month. The only  
> >> true dynamic information will be the header where the user login  
> >> state is shown. There will likely be a few million entries in this  
> >> database and we are planning to support high traffic. The pages can  
> >> be localised. The page is going to be queried as such:
> >>  http://myhost.com/myapp.action?id=12345678
> >> Although I am using a direct JPA access, we might change to use web  
> >> services in the future.
> >> Am I worrying unecessarily? At the same time are there recommended  
> >> approaches. I am currently using struts2 and JPA for the web site,  
> >> if it makes a difference.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

_________________________________________________________________
Windows Liveā„¢: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message