tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: Caching rendered page - reducing hits to the backend?
Date Mon, 01 Jun 2009 11:12:43 GMT
Worrying is good. Making sure you have metrics is better. You can cache 
lots of different items such as
- stuff from the database
- parts of a rendered page
- the entire page
- 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.

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)  Otherwise you are 
flying blind.


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:
> 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:
For additional commands, e-mail:

View raw message