Geez, not again... On Mon, Aug 6, 2012 at 2:41 AM, Drake <drak...@digerat.com> wrote: > If your Instance cost is too high it means you aren't using API's enough. A > well designed app is going to be close to 50% API, a superbly designed App > will be 85% API when you look at the logs and see ms=42 cpu_ms=2 > api_cpu_ms=14 you know you are doing it right.
Once more you are generalizing from an extremely limited problem domain. There are myriad applications that consume CPU resources - and if you're on Python, the raw cost of serialization is a significant CPU hog. It's utter nonsense that all requests can be shrunk to ms=42 cpu_ms=2. For your app sure, I can buy that. Not most apps, not by a longshot. > Again this means not using heavy frame works, but instead creating proper > datastore queries the right way, and optimizing your code for the platform. I'm not going to waste my time with this again. > Doing lots of optimizations does create lockin, but that is the trade off of > optimizing for "Instance cost" the same is true of AWS or OpenCloud > technologies. The more you Optimize the more you have lockin. Sure... I think the bigger issue is that the more you build abstraction layers, the more work you have to do. And then migrating to another service means re-implementing those abstractions, which may be prohibitively expensive. Personally I think "lock-in" is a poor argument against GAE. The #1 most important thing building a startup is getting features to market as fast as possible. Engineering for portability is contrary to this goal. But it's true that once you build an app on GAE, it probably isn't going anywhere. > Reliability is not spotty unless you are building apps that take more than > 35s per request. If you are doing that, your users already hate you and > won't be surprised when you are down. Even a casual perusal of the history of this mailing list will show this is not true. > Backend can save you a ton of money use them. Use them often. I'm not so foolish to generalize to every single problem domain, but all the "obvious" uses of backends have not panned out. Maybe, *maybe* you have come up with a great use case for backends. But for every other one I've come across, they are horrible: * They're terrible for in-memory indexing because they're 10X too expensive for RAM. * They're terrible for realtime gamestate because they can't support enough throughput. The one real-world use case that backends seem to be good for is to work around the 60s/10m deadline of frontends. That isn't very compelling. > One trans per entity per second is only an issue if you don't know how to > use shards and build a write buffer, (which you should have anyway for > managing contention). We are now handling 1 billion writes a day in an app. > In some cases logical entities are being updated 15 times per second. We are > having no trouble. We did end up building our own memcache-like server to > help with that, so to get to those numbers you need a backend. 15 updates per second is a trickle. There are lot of transactional problems that are very hard to solve on GAE, and "sharding" alone is not an answer. As a real-world example from my application, there's "the burning man problem": You have 50k items to sell, they go on sale at a specific time and sell out in 15 minutes. You must sell exactly 50,000 - not 50,001. Granted, this is a challenging problem to scale with an RDBMS (which is why the burning man ticket system crashes every year), but at least the code is simple. I have a pretty good solution to the problem but it's definitely complicated. Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
