My biggest hurdle is implementing something I can manage. I'm fairly good with vmWare. I can easily clone a webserver, swap IP's, and add this new server to a load balanced pool. I plan to keep resource usage 'per machine' low enough that each virtual machine shouldn't be overwhelmed.
So the only time people would lose their session would be if there was a failure of some sort. I expect this to be an infrequent situation. Yes, users would lose their session BUT I my hope would be that it would seem to be a 'once in a blue moon' event. Question. Can I store users session data in a mySQL DB? All that's mentioned is MongoDB/Memcache, but I wonder if I could just integrate it into my existing database setup. On Mon, May 18, 2015 at 5:50 PM, 'Alan Holden' via Open BlueDragon < [email protected]> wrote: > Put another way, consider the basic reason(s) WHY you're going to apply > more than one machine to an application: > * You want the next one available when the present one is full of > sessions, or > * You want another one to take over in the event the present one fails, or > * Some combination of both reasons, that you're still thinking over. > > When you use sticky sessions, you can easily handle the first reason. Each > server stays with the person, start to finish. More persons, more servers. > The balancing device assumes a perfect world scenario. > > But that solution doesn't help as much for the second reason. Some > quantity of your users are going to be disrupted when the server (they are > "stuck to") stops responding. If the device does swap them to a fresh > machine, they'll get fresh sessions there, and probably flummoxed as well. > > That inconvenience is probably worse than the extra second it might take > to get session data via the mongo/MemCache option, in which they continue > without interruption from one machine to the next. > > There's no correct solution for everybody. It all depends on WHY: the > priorities of your business methods I mentioned above. > > The nice part is that your business is doing well - if you actually have > problems like this on the horizon. > > Al > > > > On 5/18/2015 11:04 AM, Jason King wrote: > > I figure with sticky sessions, scaling the front end is as simple as > deploying another instance of the front end server, and adding the server's > IP to the load balancing pool. > > > > On Mon, May 18, 2015 at 1:02 PM, nitish pandey <[email protected]> > wrote: > >> 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. >> > > -- > -- > 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.
