tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Löffelhardt <jul...@austria.fm>
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" <willh@msoft.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
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)
is
> 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
references
> to prevent them from being GC'd at all (I don't think this is the case,
but
> 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
elegant
> I don't think.
>
> First, of course, "Buy more RAM", also pronounced "Let's make our Full
GC's
> take even LONGER!".
>
> Another is to simply reboot Tomcat during a "quiet" time. At least this
way,
> the down time is predictable rather than having it "Crash" at an
unscheduled
> 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
solution
> one. Oh boy, more hardware to configure.
>

In fact we are using loadbalancing using apache 1.3.26, mod_jk, and 3 tomcat
instances.
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
session-data.
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
http://www.filip.net/tomcat/ 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
fairly
> simple filters to extract the actual content without resorting to crafting
a
> JSP parser, then that is a good first step.
>
> So, going on the crass assumption that getting the article text out of
your
> 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
you
> will not have to actually update and rewrite all of the zillion URLs
> scattered throughout the site.
>
> So, www.yoursite.com/area/document.jsp in the "old" site is the same in
the
> "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
requiest
> and go its merry way.
>
> Ideally, this can be done with very little change to the site, and
certainly
> 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
> <!-- ARTICLE START TEXT-->
> This is my article
> <!-- ARTICLE END TEXT -->) that makes it easy to find articles. Perhaps
you
> can then REGENERATE all of your older content to use the new template.
You'd
> 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),
and
> 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
run
> 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,
that
> 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
> (willh@msoft.com)
>
> ----- Original Message -----
> From: "Luc Foisy" <Luc.Foisy@technical-magic.com>
> To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
> 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:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message