my first move is going to be to utilize your two-machine suggestion, just for a short-term memory relief. then i can focus on analyzing both sides for their resource usage. will update this thread when i know more.
thanks all.
Will Hartung wrote:
From: "ilasno" <[EMAIL PROTECTED]>
Sent: Thursday, December 19, 2002 11:29 AM
Subject: in search of more efficient design
SHORT VERSION - I am a beginner-intermediate webapp designer, and myOthers have mentioned that Java doesn't return memory to the OS after it is
first large-scale development is using around 500 mb of memory, with low
client load. I am seeking ways to both measure where this extreme
resource-usage is stemming from and design tips to bring it down.
GC'd, and this is true. So the question is how is the application using its
memory?
You can certainly do some simple analysis by running through some use case
scenarios of you app, and monitoring GC activity from Java. This will give
you some idea where your memory may be going.
For example, run your application with the -verbose:gc option and you'll see
some information every time the jvm runs garbage collection. What it prints
out will be some basic heap information. Start with a small heap
(java -Xms32M say), and everytime it needs to expand the heap, it will GC
and print out a line.
You can also use the java -Xrunhprof options to monitor the heap.
But, basically, start the app, and run through some simple, common scenarios
(user viewing the site, updating the site, whatever), and see if the memory
use surges.
If you notice that when a user updates the site your memory jumps from 64MB
to 500MB, then that should give you an idea on where to look. Perhaps you
could change your code to reuse some object versus recreating them. But, for
all I know one of the things that your site does is upload large digital
images and you're simply stuck with the memory cost of manipulating them.
If you application is reasonably factored without a lot of redundant code,
then your servlets per se are probably not the direct culprit in using up
your memory. Obviously their actions affect memory, but a servlet is simply
an object and doesn't have dramatic overhead in the container.
You mention how all of your work is done in the doGet methods, but perhaps
there can be some efficiencies gained by using some global Singleton caches.
If your application is constantly loading reasonably static data from the DB
and then throwing it away, that's just a waster of CPU and memory if it
could effectively be loaded once and then used several times.
Struts (as was elsewhere suggested) is a fine tool, but if you simply
converted your application over to the struts framerwork, and kept your core
code the same, then you'd still be using a lot of memory I would bet.
I wouldn't throw the baby out with the bathwater and completely reengineer
the site right off. You first need to understand where the resources are
going so you can decided whether an in place fix is appropriate or the
problem is so fundamental that you'd need to restart from scratch.
Finally, if it's practical or necessary, you could run the admin features on
one machine, and have the production users run on another machine. Since the
production users only need access to the database, there's no real
requirement that one machine support both the consumers and content
producers.
Regards,
Will Hartung
([EMAIL PROTECTED])
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- i am deprogrammed
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
