I don't want to appear ungrateful. Your comments have been very helpful. What it comes down to here is that I will be required to use SQS to make this work.
On Jul 9, 8:50 am, Frédéric Sidler <[email protected]> wrote: > Ken, I have to roles that do asynchronous jobs. They have no relation with > the www role(s). They are based on the Base role and the main process they > are doing is twisted. They check messages that the application sent to SQS > to send notifications. These notification are eiter SMS, Jabber or email > notifications based on user preferences. > > I think that with the ability to manage the load based on the size of the > SQS queue it would be possible to manage it dynamically, but this has not > been tested yet. > > Hope this helps. > > > > On Thu, Jul 9, 2009 at 5:08 PM, kenvogt <[email protected]> wrote: > > > I agree, doing it just because that's how we used to do it is not a > > good idea. But that is not what I am talking about here. This scenario > > here is not just two servers that do the same thing. They are doing > > very different things and they are doing more than one server can do > > alone. Why even have a Base role if not for purposes other than www, > > app, or mysql? Notice I said "purposes", not "purpose" as if there > > could only be one possibility other than www, app, or mysql. > > > On Jul 9, 7:58 am, Donovan Bray <[email protected]> wrote: > > > Just remember that every role you customize and change during a code > > > push you will then have to synchronize. Synchronizing is painful in my > > > experience particularly for your production environment. We find that > > > syncronizing the www role leaves no load balancer at times, and for a > > > period of up to two minutes both load balancers are in place causing > > > undefined havoc. We find that app roles stick around after the new > > > ones have started and the load balancers send traffic to both causing > > > more havoc for a few minutes. So we've been working hard at writing > > > scripts that run on init such that if we lose an instance and one is > > > restarted it configures itself with the latest code, and obviates the > > > need to synchronize each role when we do a code push. > > > > Our standard code pushes have been reduced from two hours to 30 > > > minutes, and are much less error prone and less stressful. > > > > Our app role takes about 15 minutes to start and now have increased > > > risk since a failure of the complex script could render that instance > > > unuseable, but waiting for synchronizes to finish and their > > > destabilizing effect was an untennable situation. > > > > On Jul 8, 2009, at 11:42 PM, Frédéric Sidler > > > > <[email protected]> wrote: > > > > > There is a 4th role you should consider for this purpose. This is not > > > > www, app or mysql role. > > > > > On Thursday, July 9, 2009, kenvogt <[email protected]> wrote: > > > > >> I need a farm with a database server, a web server, and two distinct > > > >> application servers for backend processing. When I login to Scalr and > > > >> go to build a new farm, select Shared Roles, then Application > > > >> servers, > > > >> it only allows me to check a box for a server type. I need two of the > > > >> app64 however. This is not a scaling issue, the servers need to do > > > >> different things. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
