I wasn't referring to what gets stored in the session *object*. I know that
an object reference is only a few bytes in size. I was referring to the
size of an average bean that he would instantiate *per* session to hold his
form data, and it is absolutely not just a few bytes. In fact, I took
liberties in not adding on the additional overhead of the object references.
If he has 5000 concurrent users then the object reference bytes are not
trivial. The object reference overhead would be something like:
overhead_bytes = (num_form_field_strings + num_form_value_strings + 2) *
num_sessions * object_ref_size_in_bytes
The 2 is for the bean and session object references, and I'm sure that
there's even more overhead than what I've accounted for.
Read his question more closely.
David
> -----Original Message-----
> From: Sameer Tyagi [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 04, 1999 9:53 AM
> To: David Chisholm; [EMAIL PROTECTED]
> Subject: Re: Session values question
>
>
> The misconception is that the object IS NOT stored in the session. ITS A
> HANDLE or reference. The actual object is in memory.
> This math that you show is totally incorrect, Its like saying that the
> each charecter in ASCII is 1 byte so if your source file contains 2000
> charecters of source code the compiled class file will be 8*2000 bytes.
> HUHH ??
> The actual object storeage in a session doesnt involve more than a few
> bytes.!~
>
> The same thing happens when you store stuff in a Hashtable, a ref is
> stored NOT the object ~!!! THERE is a BIG
> difference and most C/C++ programmers have difficulty understanding that
> in Java,objects( not in RMI) are passed by reference and primitives by
> values.
>
> I have enclosed a test program for you . That puts
> >java -Xms32M -Xmx32M Mem
>
> This populates the Hashtable with 10000 MyObjects
> As you can see, each object translates into 158.4832 bytes ( not KB)
>
> The actual session memory usage depends on the servers implememntation
> of the HttpSession inteface. weblogic for example uses EJBs to
> internally handle sessions, as compared to the Suns JSWDK.
>
> Hope this helps.
> -Sameer
>
>
>
> David Chisholm wrote:
> >
> > You're right that the session values are stored in the server,
> and I think a
> > bean is a very convenient way to store these values, but I
> suggest that you
> > do the math to determine whether this is consuming two much memory:
> >
> > num_bytes = [75 * (avg_field_name_size) * 2] + [75 *
> (avg_value_size) * 2] *
> > expected_number_of_concurrent_users;
> >
> > (The *2 is because Java characters are 2 byte Unicode characters)
> >
> > The numbers can quickly add up. Then of course you can start looking for
> > ways to reduce this cost. For instance, the field names are always the
> > same, so do you have to store them in every bean or can they be
> static class
> > data? Can you number the fields rather than using a label and
> then use the
> > number for the HTML element's ID value? If the form history isn't
> > frequently used, is it more efficient to persist the form values into a
> > temporary file that's associated with the session?
> >
> > My .02,
> > David
> >
> > > -----Original Message-----
> > > From: A mailing list about Java Server Pages specification
> and reference
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Medcraft
> > > Sent: Thursday, November 04, 1999 4:53 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Session values question
> > >
> > >
> > > I need to store form field values from a fairly large form
> (75 fields) so
> > > that later forms can be prepopulated. I have written a Bean that
> > > uses a two
> > > dimensional array of Strings to hold field names and values.
> > >
> > > This works well, but I am unsure how it will affect server
> > > performance when
> > > accessed by a lot of users concurrently. Am I right in thinking
> > > that session
> > > values are stored in the Server's memory?
> > >
> > > Also, I know I could simply have written the field names &
> values directly
> > > to the Session Object rather than writing the Bean. Is there much
> > > difference
> > > apart from adding an unnecessary component? (I went for the Bean
> > > as I hadn't
> > > used one before and wante to try it out.)
> > >
> > > Thanks,
> > >
> > > Paul
> > >
> > > ==================================================================
> > > =========
> > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > > JSP-INTEREST".
> > > FAQs on JSP can be found at:
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > >
> >
> >
> ==================================================================
> =========
> > To unsubscribe: mailto [EMAIL PROTECTED] with body:
> "signoff JSP-INTEREST".
> > FAQs on JSP can be found at:
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
