Agree that the moment you have a shared node the scaling propensity comparatively lesser. Once the basic app is done with sticky session, maybe an appliance can be dedicated to continually backup the sessions. So when in a crash of a VM the sessions is restored. But that would be required if you are doing financial trading stuff.
np On 18-May-2015 8:15 pm, "Jason King" <[email protected]> wrote: > Hi Alan, > > My gut is saying performance would be better with sticky sessions because > with this setup, session variables remain in the application servers direct > memory. > > All I need to setup is a simple load balancing pool with sticky sessions, > and as long as the web/application server remains healthy, the user should > have a good experience. Worst case scenario the server fails and they are > pushed to a new server and they have to login again. > > With using a shared session server (mongo/MemCache), it seems that any > work the application servers do would rely on the shared session server's > performance. And then I also need to account for scaling this deployment as > well. As I add more application servers, the shared session server needs to > scale as well. > > It seems performance and scalability is easier to manage with a 'sticky > session' configuration. > > Thoughts? > > On Sat, May 16, 2015 at 11:26 AM, Alan Williamson <[email protected]> wrote: > >> It is a good question. >> >> Bottom line - if you are don't want to use sticky sessions and want any >> server to pick up the request, then you need to look at something that is >> accessible by everyone, therefore Mongo/Memcached. if you are happy with >> sticky sessions then don't create an additional server. >> >> ------ Original Message ------ >> From: "Jason King" <[email protected]> >> To: "Open BlueDragon" <[email protected]> >> Sent: 15-May-15 17:48:51 >> Subject: Re: [OpenBD] Best method for session management >> >> >> I found this: >> >> http://openbd.org/manual/?/app_application_cfc >> >> "OpenBD makes it easy to make your applications run across multiple >> servers seemlessly without you have to worry about the logistics of moving >> the session scope around. >> >> You have the choice of using the following storage engines: >> >> - Default in memory >> - J2EE Session Management >> - Memcached/CouchBase servers (this.sessionstorage = >> 'memcached://10.0.0.1:11211';) >> - MongoDB servers (this.sessionstorage = 'mongo://10.0.0.1:27017';) >> >> *Memcached/CouchBase Configuration* >> >> You can easily use a remote farm of Memcached (or CounchBase) servers by >> specifying the connection URI: *memcached://server1:27017 server1:27017* >> >> *MongoDB Configuration* >> >> More efficient than Memcached is the MongoDB storage engine. Sessions are >> loaded and saved to remote MongoDB servers (configured in a replic or >> sharded set). Sessions that have not changed, are efficiently handled as to >> not incurr the overhead of always moving data around. With the MongoDB >> connection URI, you can specify the Mongo database to use, though it >> defaults to 'openbd' with the collection 'sessions'. >> >> " >> >> >> I'm wondering.. should I just setup a MongoDB virtual machine for this >> and use it for session storage? >> >> On Fri, May 15, 2015 at 3:48 PM, Jason Allen <[email protected]> >> wrote: >> >>> It's been a while since I've thought about this basic component of >>> running a webapp, but I want to revisit it. >>> >>> I'm building an app on CentOS7 with Tomcat as my webapp server. It works >>> great. >>> >>> That said, considering the app is a straighforward app with standard >>> login mechanisms, what is the best way to manage user sessions? >>> >>> I plan on deploying multiple vServers of the app. I'll start with 3 vm's >>> running the same app. I have a load balancer that will use sticky sessions >>> to map users to one particular webserver as long as that webserver is >>> healthy. >>> >>> How should I manage cookies and sessions? Should I create a cookie in >>> the user's browser that links it to a specific webserver, or should I >>> create a database table and store cookies in there, assuming that in doing >>> so, the users aren't locked in to any one specific web server. >>> >>> I'm going to continue investigating this via google and searching, but >>> if anybody has any input it would be greatly appreciated. >>> >>> -Jason >>> >>> -- >>> -- >>> online documentation: http://openbd.org/manual/ >>> http://groups.google.com/group/openbd?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Open BlueDragon" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> -- >> online documentation: http://openbd.org/manual/ >> http://groups.google.com/group/openbd?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Open BlueDragon" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> -- >> online documentation: http://openbd.org/manual/ >> http://groups.google.com/group/openbd?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Open BlueDragon" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > online documentation: http://openbd.org/manual/ > http://groups.google.com/group/openbd?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Open BlueDragon" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
