we are using a combination of S3 and cloudfront to solve the three problems Alex mentionned
- persistent (S3) - shared (S3) - fast (cloudfront) and to manage sessions we are using memcache as Donovan suggested. Memcache is shared between all app instances. 2009/6/3 Alex Kovalyov <[email protected]> > > Just thoughts: There's no out-of-the-box storage panacea on AWS that > would be fast+shared+persistent, yet, so you have to sacrifice. > EBS and S3 can crash. > SimpleDB is flat > > I would try Scalr's stuff, as Donovan suggested, but it will require > some hand work. > > On 2 июн, 20:34, Fran_K <[email protected]> wrote: > > The reason we picked Scalr was because we cannot predict how far we > > will have to scale and we wanted something that would attempt to adapt > > for us. However, this still requires a lot more thinking about the > > architecture than I anticipated. I'm now at the point where I need to > > make a decision about which way to go with my data storage and I was > > hoping that other Scalr users might have some experience that they > > would like to share. > > > > When we first started building our app we only had a few data objects > > to store for each user and we thought to use Rails to do this, but > > testing showed that this did not scale very well and there were a few > > problems with the system that I wanted to avoid. After analysis I > > determined that the app state could be expressed as a big JSON string > > and that most users would only have one or two saved states. As I > > thought about how to elimiate complexity it seemed that I could create > > some app servers to handle read and write REST calls and store the > > states for each user on disk somewhere. I can SQS if my servers start > > to bog down and I am waiting for more instances to appear to handle > > the work. Well and good, this runs a hell of lot faster than Rails, > > and the complexity of the code is not very great. But now I am faced > > with answering a question in order to decide which way to go. > > > > I can store my state strings in S3 and make the requests for state by > > a user be a redirected call to S3, or I can store the states in EBS > > and hope that the single instance can handle the load (and use a > > sharding strategy if needed). The thing I like about S3 is that I can > > just let the farm grow and shrink as needed since the storage is not > > limited to one instance, but I am worried about the access time. It > > seems that EBS would be faster, but my gut tells me that I'll have to > > be sharding soon and that I will have to intervene on that a lot. > > > > Also, the cost seems to favor S3 for my app since my state strings are > > only a couple of K, and S3 charges per G not per number of accesses. > > > > Does anyone have any experience with this kind of issue and would mind > > sharing their experience? > > > > Thanks, > > > > --fran > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
