tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Löffelhardt <>
Subject Re: reducing tomcat & jasper memory footprint
Date Fri, 03 Jan 2003 01:38:37 GMT
Thanks for your Feedback!

I will look into your suggested approch using filters.

answers inline

----- Original Message -----
From: "Will Hartung" <>
To: "Tomcat Users List" <>
Sent: Thursday, January 02, 2003 11:27 PM
Subject: Re: reducing tomcat & jasper memory footprint

> There are a lot of issues that show up here.
> 1) Using the JSP means that the entire article text (among other things)
> being cached into RAM.
> 2) Some of the pages are "popular" enough that they are getting moved into
> the permanent area of memory, and thus avoiding the routine, "cheap" GCs.
> 3) The question whether Tomcat is somehow "holding on" to the JSP
> to prevent them from being GC'd at all (I don't think this is the case,
> you never know).

As of 4.0.4 tomcat keeps a reference to every generated servlet, so
increasing the memory size only delays the OutOfMemoryError.

> As for solutions, there are several, none of which are particularly
> I don't think.
> First, of course, "Buy more RAM", also pronounced "Let's make our Full
> take even LONGER!".
> Another is to simply reboot Tomcat during a "quiet" time. At least this
> the down time is predictable rather than having it "Crash" at an
> time. If the restart time is fast enough, and the site quiet enough, this
> may effectively solve the issue. You mentioned that the system is running
> several days reliably now, so, perhaps a nightly restart is not a horrible
> concession.
> Another is to mirror the site behind some kind of load balancer so that
> restarting the site does not actually affect users, and then go to
> one. Oh boy, more hardware to configure.

In fact we are using loadbalancing using apache 1.3.26, mod_jk, and 3 tomcat
Every night one tomcat get's restarted. Basically we use the lb-options
local_worker  & local_worker_only to disable a tomcat instance at midnight
and restart it at 4:00.

Otherwise the big problem with restarting tomcat is loss of our
Saving and restoring the data in the SESSIONS.ser file doesn't help, since
the loadbalancer routes the web clients to another tomcat instance where
they get another sessionId.

I once experimented with tomcat clustering using the source from but this was some months ago and didn't work
very well at this early stage .

> You can "rengineer" the site.
> If your JSPs are reasonably regular to the point where you can write
> simple filters to extract the actual content without resorting to crafting
> JSP parser, then that is a good first step.
> So, going on the crass assumption that getting the article text out of
> generated JSPs is not an onerous task, then the next step, to me, would be
> to stick a servlet Filter in front of every request.
> This Magic Filter (a notable anti-pattern, but...) is configured so that
> will not have to actually update and rewrite all of the zillion URLs
> scattered throughout the site.
> So, in the "old" site is the same in
> "new" site.
> The Magic Filter determines if the JSP file is a "real" jsp (no doubt you
> have some JSPs that do something other than dump static articles), versus
> one of your generated documents.
> If it is one of your generated documents, then the Magic Filter rips it
> apart, caches it perhaps (the ripped text), and then serves it up in a new
> shiny generic way as should have been done originally. If not, you let the
> Filter drop through and pass on so the container can handle the JSP
> and go its merry way.
> Ideally, this can be done with very little change to the site, and
> no change to the production CMS, it's ignorant of the change. Your web.xml
> "simply" has a new Filter element, and voila!
> I am not suggesting that this is easy or painless, but if your generated
> JSPs are able to be easily torn apart, then I think it's viable and
> practical.
> Perhaps your CMS JSP template can be recoded to add some comments (like
> This is my article
> <!-- ARTICLE END TEXT -->) that makes it easy to find articles. Perhaps
> can then REGENERATE all of your older content to use the new template.
> like to think that your CMS will allow this (kind of the whole point of a
> CMS at some level, isn't it?).
> Or, if you can not regenerate your older content, have the Magic Filter
> "detect" old vs. new and simply "execute" the old ones (as noted above),
> filter the new ones. If your site is mostly newer content, then the old
> stuff will drift away and be less of a problem over time.
> Once up and running, your Magic Filter can cache and keep track of the
> status of various JSPs it encounters so as not to have to rework them each
> time.
> I would vote for the "restart nightly" technique and look into ways of
> tweaking the CMS system to spit out something you can use, but that's me.
> The other problem with this technique is that it is doing processing at
> time which could best be done statically.
> For example, the fact that your CMS is generating JSPs, perhaps you can
> place a step in the production step that performs the parsing for you,
> way it is done at production time versus request time. It depends on how
> easily you can modify your work flow from the CMS into the site proper.

I thought about converting the documents into velocity templates or
something like that using a postprocessor but decided against it:

1) Would be quite comlicated, due to the complex structure of the pages.
2) First I would need to "proove" that my suggested different design would
work better.
We get about 400.000 PageImpressions/day and under high load many
concepts/designs/applications just dont't "deliver"
For example, we performed extensive stress-tests on our application but the
tests didn't reveal the problems with too many different jsp-Files since our
tests where mainly focused on performance issues and we only used about 100
pages for testing.

Anyways thanks for your feedback.

> Regards,
> Will Hartung
> (
> ----- Original Message -----
> From: "Luc Foisy" <>
> To: "Tomcat Users List" <>
> Sent: Tuesday, December 31, 2002 7:44 AM
> Subject: RE: reducing tomcat & jasper memory footprint
> Since your jsp's are generated, they should all have the same formatting.
> Write some code to rewrite your own non jsp pages that you can then later
> insert into a single jsp. Sure its some work, but in the long run it will
> save you some aggravation.
> If tomcat can rewrite your jsp on the fly, so can you.
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message