|
Ah ok. I'm keeping roughly 3 objects in the session. One is a vector of street names, possibly 1300 in size, containing street name, and civics attached. Then there's the customer object and garbage detail object. The last two are only per record basis. Ron Power Programmer Information Services City Of St. John's, NL P.O. Box 908 St. John's, NL A1C 5M2 Tel: 709-576-8132 Email: rpower@xxxxxxxxxx Website: http://www.stjohns.ca/ ___________________________________________________________________________ Success is going from failure to failure without a loss of enthusiasm. - Sir Winston Churchill "Dan Feather" <DFeather@xxxxxxxxxxxxx> Sent by: java400-l-bounces@xxxxxxxxxxxx 22/04/2005 04:15 PM Please respond to Java Programming on and around the iSeries / AS400 <java400-l@xxxxxxxxxxxx> To "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx> cc Subject RE: Session attributes The most accurate answer I can think of off the top of my head is: "It depends." How many objects are in the vectors on average? How big are those objects? How much memory does your system have? How is your application server configured to utilize the memory? How many users do you expect to be using your application at the same time? There are profiling tools out there for this sort of thing, but I have never had the opportunity to use one. I just always tried to minimize what I was keeping in the session, even if it meant re-writing something so that it would go back to the DB for a quick query every time a specific piece of data was needed instead of keeping it in memory (as long as the performance trade-off was acceptable). You can do things like adjusting the time out value for sessions, so dormant session data doesn't hang around longer than makes sense, use lazy object creation/instantiation so you don't populate a session with a whole bunch of data related to a request, when they may only be after the first little bit. I know that isn't a terribly helpful answer, and maybe someone has a better one (I hope so)... but if you are keeping just a couple KB of data per user in memory, you are probably ok... as long as you are careful to clean up the session at the appropriate time, and you have the JVM setup so that GC happens at the optimal time... again, a profiling tool would help a lot. There are a lot of things that can affect this situation. A vague answer, yes... but it does depend :) Dan Feather Silhouette/PinPoint R&D Programmer Jack Henry & Associates, Inc. dfeather@xxxxxxxxxxxxx -----Original Message----- From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of RPower@xxxxxxxxxx Sent: Friday, April 22, 2005 1:32 PM To: Java Programming on and around the iSeries / AS400 Subject: Session attributes Just curious here, but how can I tell how much memory my application is using because of the session attributes I have setup? How much is too much? Any industry standards as to what should and shouldn't be loaded into memory? Right now I'm loading a couple vectors into memory, nothing I consider to me too much, but I don't want to create an app that will crawl to a halt. Thanks, Ron Power Programmer Information Services City Of St. John's, NL P.O. Box 908 St. John's, NL A1C 5M2 Tel: 709-576-8132 Email: rpower@xxxxxxxxxx Website: http://www.stjohns.ca/ ________________________________________________________________________ ___ Success is going from failure to failure without a loss of enthusiasm. - Sir Winston Churchill -- This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/java400-l or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. -- This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/java400-l or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
