Caching rendered page - reducing hits to the backend?

[Andre-John Mas-4]

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.

André-John
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Caldarale, Charles R]

> From: Andre-John Mas [mailto:[hidden email]]
> Subject: Caching rendered page - reducing hits to the backend?
>
> I want to be able to cache the rendered pages to reduce
> database hits.

Wouldn't that be the function of a Java bean?

> Am I worrying unecessarily?

Hard to tell without taking measurements of your environment with your expected load.  The only generality is that there are no generalities (well, very few).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tim Funk]

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.

-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: [hidden email]
For additional commands, e-mail: [hidden email]

[Rob Koberg]

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Leon Rosenberg-3]

On Mon, Jun 1, 2009 at 1:37 PM, Robert Koberg <[hidden email]> wrote:

>
> On Jun 1, 2009, at 7:12 AM, Tim Funk wrote:
>> 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.

Funny :-)
I remember removing xml/xsl generation from the chain and replacing it
with jsps a while ago. Brought about factor 10 performance (from 50 ms
rendering time to 5). So I second TIm's statement: measure first and
measure after. And compare :-)

Leon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Rob Koberg]

On Jun 1, 2009, at 8:08 AM, Leon Rosenberg wrote:

> On Mon, Jun 1, 2009 at 1:37 PM, Robert Koberg <[hidden email]> wrote:
>>
>> On Jun 1, 2009, at 7:12 AM, Tim Funk wrote:
>>> 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.
>
> Funny :-)
> I remember removing xml/xsl generation from the chain and replacing it
> with jsps a while ago. Brought about factor 10 performance (from 50 ms
> rendering time to 5). So I second TIm's statement: measure first and
> measure after. And compare :-)

No. It is not in the chain, well, not in the runtime chain/pipeline.  
It is generated before you even put it on the live server.

-Rob


>
>
> Leon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Martin Gainty]

MG>hopefully brief comments

> From: [hidden email]
> To: [hidden email]
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009

[Leon Rosenberg-3]

On Mon, Jun 1, 2009 at 2:12 PM, Robert Koberg <[hidden email]> wrote:
> No. It is not in the chain, well, not in the runtime chain/pipeline. It is
> generated before you even put it on the live server.
>
> -Rob

I am not judging your solution, just saying that there are not general
rules except for one:
measure what you do, measure what you've done :-)
:-)
regards
Leon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Markus Stauffer]

like this: http://www.opensymphony.com/oscache/  ?


Am 30.05.2009 um 21:51 schrieb Andre-John Mas:

> 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.
>
> André-John
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Pid-2]

Have you already measured the performance of your application and
determined that caching the rendered pages is the appropriate thing to
do - ie how have you determined that database access is the bottleneck?

If not, caching page content may just hide a multitude of performance
related sins.

JPA's built-in caching may already provide enough in the way of
performance improvements to make an additional caching layer pointless.

Is the database on a different machine or the same one and are you
clustering Tomcat?

You're probably worrying unnecessarily.

p



Markus Stauffer wrote:

> like this: http://www.opensymphony.com/oscache/  ?
>
>
> Am 30.05.2009 um 21:51 schrieb Andre-John Mas:
>
>> 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.
>>
>> André-John
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Andre-John Mas-4]

On 2-Jun-2009, at 04:37, Pid wrote:

> Have you already measured the performance of your application and
> determined that caching the rendered pages is the appropriate thing to
> do - ie how have you determined that database access is the  
> bottleneck?
>
> If not, caching page content may just hide a multitude of performance
> related sins.
>
> JPA's built-in caching may already provide enough in the way of
> performance improvements to make an additional caching layer  
> pointless.
>
> Is the database on a different machine or the same one and are you
> clustering Tomcat?
>
> You're probably worrying unnecessarily.
>

I think I may end up simply ensuring that the database has enough memory
and slowly evaluate where the bottle necks are. What I will do at the  
same
time is have a number of points to watch out for, with possible  
solutions.
I will also make sure that the last results for the search are cached
in the user session.

André-John
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Peter Crowther]

> From: Andre-John Mas [mailto:[hidden email]]
> I think I may end up simply ensuring that the database has
> enough memory and slowly evaluate where the bottle necks are.

It's often the best approach.  You can spend a lot of time optimising places that turn out not to be the bottleneck.  You can also spend a lot of time testing a new app, only to find out that the real usage patterns aren't like that at all and you suddenly need to optimise one operation that you never thought would be used heavily!

                - Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]