Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <9EA1296A-7D53-47D7-B2A0-1F5C1C5D0342@koberg.com>
From: Robert Koberg <rob@koberg.com>
To: "Tomcat Users List" <users@tomcat.apache.org>
In-Reply-To: <4A23B7AB.4060608@joedog.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Caching rendered page - reducing hits to the backend?
Date: Mon, 1 Jun 2009 07:37:56 -0400
References: <BLU0-SMTP23D89CB4FBF2A94DBD89E1C54E0@phx.gbl>
 <4A23B7AB.4060608@joedog.org>


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

I think you can generally say that the less you have to do on the  
server, the better. If you can generate out a page *as much as  
possible* so that only the really necessary dynamic components are  
created at runtime, then it is better.

We use XSL/XML to pregenerate a JSP bringing all known page content/ 
components.

I don't see why you would be flying blind. Seems like a no-brainer.

best,
-Rob


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