Re: data in session affecting performance ?
Hello, I think i read (probably on tomcat mailing list), that clustering should ensure (in specs) that a session is not spread across cluster (once session is started, user always speak with same jvm which started the session). Size of objects contained inside a session might however be a performance issue when there is lots of traffic on server (100k+100k+100k+... can make a lot after 30 minutes if you assume idle session lifetime of 30 minutes). But with performances issues, a simulation is a good idea to know if you might get affected or not! Le Vendredi 27 Janvier 2006 10:00, starki78 a écrit : Ciao, I was it who received the answer, well I didn't find this performance gap then the session object contained for a short time 1MB but I didn't test it in a distributed environment. A session-scoped Acion Form shouldn't harm the performance. I cannot immagine. Nice greetings -- Initial Header --- From : Lixin Chu [EMAIL PROTECTED] To : Struts Users Mailing List user@struts.apache.org Cc : Date : Fri, 27 Jan 2006 08:11:05 +0800 Subject : data in session affecting performance ? Hi, I saw a thread discussing this but can not find it anymore now. I remember someone mentioned that the amount of data put into the session context should not exceed 32KB in general otherwise performance might be affected. I may interpreted it wrongly. so i would like to clarify if it is indeed the case and does this also means that a session scoped ActionForm is really bad in terms of performance ? thanks lixin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver méchant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: data in session affecting performance ?
On Fri, January 27, 2006 4:30 am, David Delbecq said: Hello, I think i read (probably on tomcat mailing list), that clustering should ensure (in specs) that a session is not spread across cluster (once session is started, user always speak with same jvm which started the session). That's interesting... anyone know for sure if that is ensured by the spec? I could see a vendor saying they will ensure it, but I'm not certain if the spec ensures it. However, consider failover scenarios... in that case, you would absolutely want the session to have been replicated, otherwise it wouldn't work. For this reason, I'm not sure if the spec would want to say something that was contrary to that. Also, simple load balancing (in the absence of hardware load balancing) would run contrary to the spec. But the bottom-line is I don't know if the spec ensures it or not... anyone else? But with performances issues, a simulation is a good idea to know if you might get affected or not! That's an excellent point. I've never honestly done such a simulation, I always took IBM's advice and followed it... even if it turned out to not be valid any more, I don't see where it'd be a bad thing anyway... I remember years ago when using session *at all* was frowned upon (I was in the MS world at the time). This got me into the habit of writing my apps to use very little session all the time, and it's never felt like a huge constraint, and maybe it has saved me some headaches that I otherwise might have had. But I never actually verified through tests that the advice was valid. Frank Le Vendredi 27 Janvier 2006 10:00, starki78 a écrit : Ciao, I was it who received the answer, well I didn't find this performance gap then the session object contained for a short time 1MB but I didn't test it in a distributed environment. A session-scoped Acion Form shouldn't harm the performance. I cannot immagine. Nice greetings -- Initial Header --- From : Lixin Chu [EMAIL PROTECTED] To : Struts Users Mailing List user@struts.apache.org Cc : Date : Fri, 27 Jan 2006 08:11:05 +0800 Subject : data in session affecting performance ? Hi, I saw a thread discussing this but can not find it anymore now. I remember someone mentioned that the amount of data put into the session context should not exceed 32KB in general otherwise performance might be affected. I may interpreted it wrongly. so i would like to clarify if it is indeed the case and does this also means that a session scoped ActionForm is really bad in terms of performance ? thanks lixin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver méchant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: data in session affecting performance ?
Yes, that would be my advice. Further, I would try and architect your solutions in such a way as to not even require session as much as that is possible. Clearly it won't always be, but every little bit helps :) Frank Lixin Chu wrote: thank you very much - my memory is not too rusty then - at least I remember the 32kb threshhold :-( ok, so my takeaway is that, in general it is ok to use a session scoped ActionForm with some minimum data but for large list/set we better look it carefully. Putting them into request scope might be a better choice, if we have sort of cache supported I guess. No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date: 1/27/2006 -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: data in session affecting performance ?
Hi Lixin, That was in all probability a comment I made in a thread... the 32k limit used to be a recommendation from IBM. The reason was that in a clustered environment, the session replication time across nodes was a big concern. Even on a single server the container managing persistence of a larger session object could be shown to be a performance and scalability hindrance. 32k was what they found to be the largest value before a significant degradation was seen to occur. It is possible this threshold would be different in other containers, this was with regard to Websphere, but they always said it was a general recommendation, so I always stuck to it. I'd say if you aren't in a clustered environment, the concern is decreased a bit, but then again, you wouldn't want to design your apps in such a way that moving to a clustered environment all of a sudden caused problems with your app. All that being said, it is true that many frameworks these days are using session more and more. It is also true that many people are starting to use session more and more in general. My own personal opinion is that you should minimize session use whenever possible, but many smart people feel that it is OK to use session as much as you want. In terms of ActionForms, I'd say it depends what is in the forms... if it's just user-entered parameters, it probably won't be too big anyway, and that's fine. If your storing big lists of stuff, I would tend to look for another approach, but that's just my opinion. Frank Lixin Chu wrote: Hi, I saw a thread discussing this but can not find it anymore now. I remember someone mentioned that the amount of data put into the session context should not exceed 32KB in general otherwise performance might be affected. I may interpreted it wrongly. so i would like to clarify if it is indeed the case and does this also means that a session scoped ActionForm is really bad in terms of performance ? thanks lixin No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.23/240 - Release Date: 1/25/2006 -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
