struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Muhlestein <den...@zserve.com>
Subject RE: [OT] Session Management using EJB
Date Thu, 10 Jul 2003 19:13:59 GMT
>Thanks Eric , for your feedback . 
>I am aware of the fact that container takes care of duplicating the Session
>across the cluster . 
>But then if I have 10 servers , it would be an big overhead as the server
>has to make 10 copies of Session object.

Typically, although I could be miles from the truth, If you have more than a few servers to
cluster, you would have multiple clusters.  I've heard that for best performance, you should
have clusters of no more than 3 or 4 servers.

To have more than one cluster, you need to have a load balancer capable of handling sticky
sessions though.  ie: once you get a session from a server in a cluster (cluster A), the lb
always knows to send your http requests back to cluster A.

For 10 servers, you might have two clusters of 3 and one cluster of 4.


>If I maintain the user state on the App Server level (EJB) . I could manage
>to bring down this overhead .

Would it really be any less overhead?

>But then I need to roll out my own session implementation (which at Web Tier
>,Servlet/JSP container already implemnts).
>I am also aware of the fact that then my getAttribute() , setAttribute()
>calls would be network calls , and hence expensive

>So this I m doing just to make sure that overhead of session object
>replication is not there.

>Now my question is .. do you feel I have some point here ??? 
>or you feel that  its more coding for less gain ?? 


If you have enough traffic to actually need 10 servers in your pool, and you are generating
revenue with those servers, you could probably use some of it to by a load balance with sticky
session capability.  If not, I'd stick with http session management at the web tier and only
cluster 3 or 4 of the servers.

Just my thoughts on a complex topic :-)
-Dennis




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message