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.
