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.
