> 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 my > 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. Others have mentioned that Java doesn't return memory to the OS after it is 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]>
