PREAMBLE - I apologize if this is off-topic. I have been on this search for a month, and have searched the web far and wide, but have mostly found either J2EE design recommendations (higher-level than i am prepared to explore right now) or software vendors trying to sell me load-testing programs. I would appreciate pointers to self-enlightenment sites almost as much as more specific guidance.

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.

LONG VERSION - The site I am developing is for a company that wishes to be able to change/update portions of their site through a web-based private section of their site. The result is an extensive admin implemented through a combination of jsp pages (for forms, and feedback) and corresponding servlets (for processing and database updating through db-access modules). The admin section is obviously much bigger and more resource-intensive than the public portion, which just hits the database once-an-hour for updates and displays the current data. Conversely, while the admin section is much larger (many more servlets with larger file sizes, more processing), it is obviously used much less (one or two users per day as opposed to many per day for the public portion). I have steered away from keeping variables global within servlets (including db-access module instances), so that within a doGet or doPost everything i need is created, and then i am assuming when the method ends everything is garbage-collected? is it possible to have that much memory used just to hold 60 or 70 servlets ready for requests? I am wondering if my design is flawed, or a bad idea altogether..

any help or guidance would be greatly appreciated.

jesse
--
i am deprogrammed


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to