is there any problem with sitemesh

[nani2ratna]

HI I was reading about sitemesh,

I just saw this link http://www.learntechnology.net/content/sitemesh/sitemesh.jsp.

He gave the note like this


NOTE (Added 1/5/2005): Actually, there is one
thing I found using SiteMesh that you might want to consider before you use it. It actually had to be taken out of an application I was using because of this issue: Sitemesh has to store the entire content of your html body into memory before it decorates it. If you have some very large pages, such as might happen in a reporting app where you don't have paging and end up with one large page of rows, you could end up with severe memory problems since all of that content is stored in a StringBuffer before being decorated. On my local machine with not a lot of RAM given to Tomcat, it actually would bring Tomcat down. Just something to consider before you adopt SiteMesh. Tiles does not have this problem.

Is it right

Thanks and regards
Ratna

[Joe Walnes]

Yes, that's correct - the page is stored in memory.

However, for the majority of cases this is not a problem - it is only very extreme cases.

If this is a concern, you have to ask yourself:
* How big are the biggest pages you deal with?
* How much RAM do you have on your server?
* How many requests per second do you process?
* How long does it take to process a request?

Here's an example of some estimates:
* I am processing 100 requests per second.
* Each request takes 0.5 seconds to process.
* The larger pages are 1MB.

For that case, I'll need about 50MB of RAM. Actually, SiteMesh takes up about twice as much memory as it should, so really about 100MB. That too should be fine.

If however, I was processing the same throughput, but my pages were 20MB each (which seems very extreme for websites), you would need more than 2GB of RAM. That's the point where you should start worrying.

thanks
-Joe

On Fri, Feb 27, 2009 at 11:18 PM, nani2ratna <nani2ratna@...> wrote:

HI I was reading about sitemesh,

I just saw this link
http://www.learntechnology.net/content/sitemesh/sitemesh.jsp.

He gave the note like this


NOTE (Added 1/5/2005): Actually, there is one
thing I found using SiteMesh that you might want to consider before you use
it. It actually had to be taken out of an application I was using because of
this issue: Sitemesh has to store the entire content of your html body into
memory before it decorates it. If you have some very large pages, such as
might happen in a reporting app where you don't have paging and end up with
one large page of rows, you could end up with severe memory problems since
all of that content is stored in a StringBuffer before being decorated. On
my local machine with not a lot of RAM given to Tomcat, it actually would
bring Tomcat down. Just something to consider before you adopt SiteMesh.
Tiles does not have this problem.

Is it right

Thanks and regards
Ratna
--
View this message in context: http://www.nabble.com/is-there-any-problem-with-sitemesh-tp22256364p22256364.html
Sent from the OpenSymphony - SiteMesh mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Scott Farquhar]

Of course - not every page needs to be decorated.  In JIRA, we don't
decorate large report pages, so this reduces our RAM requirements
significantly.

Cheers,
Scott

On Sat, Feb 28, 2009 at 04:13:23PM +0000, Joe Walnes wrote:

> Yes, that's correct - the page is stored in memory.
>
> However, for the majority of cases this is not a problem - it is only very
> extreme cases.
>
> If this is a concern, you have to ask yourself:
> * How big are the biggest pages you deal with?
> * How much RAM do you have on your server?
> * How many requests per second do you process?
> * How long does it take to process a request?
>
> Here's an example of some estimates:
> * I am processing 100 requests per second.
> * Each request takes 0.5 seconds to process.
> * The larger pages are 1MB.
>
> For that case, I'll need about 50MB of RAM. Actually, SiteMesh takes up
> about twice as much memory as it should, so really about 100MB. That too
> should be fine.
>
> If however, I was processing the same throughput, but my pages were 20MB
> each (which seems very extreme for websites), you would need more than 2GB
> of RAM. That's the point where you should start worrying.
>
> thanks
> -Joe
>
> On Fri, Feb 27, 2009 at 11:18 PM, nani2ratna <nani2ratna@...> wrote:
>
> >
> > HI I was reading about sitemesh,
> >
> > I just saw this link
> > http://www.learntechnology.net/content/sitemesh/sitemesh.jsp.
> >
> > He gave the note like this
> >
> >
> > NOTE (Added 1/5/2005): Actually, there is one
> > thing I found using SiteMesh that you might want to consider before you use
> > it. It actually had to be taken out of an application I was using because
> > of
> > this issue: Sitemesh has to store the entire content of your html body into
> > memory before it decorates it. If you have some very large pages, such as
> > might happen in a reporting app where you don't have paging and end up with
> > one large page of rows, you could end up with severe memory problems since
> > all of that content is stored in a StringBuffer before being decorated. On
> > my local machine with not a lot of RAM given to Tomcat, it actually would
> > bring Tomcat down. Just something to consider before you adopt SiteMesh.
> > Tiles does not have this problem.
> >
> > Is it right
> >
> > Thanks and regards
> > Ratna
> > --
> > View this message in context:
> > http://www.nabble.com/is-there-any-problem-with-sitemesh-tp22256364p22256364.html
> > Sent from the OpenSymphony - SiteMesh mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >

--
Scott Farquhar
[phone] office
scott@...
http://www.atlassian.com

ATLASSIAN
Our products help over 14,000 organisations in more than 100 countries
collaborate.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...