> Sure... and you probably wouldn't want to either given how insanely > expensive backend RAM is on GAE. But your app is a bit of an oddity, and fits > into a quirk of GAE's pricing model. You primarily consume two resources > that Google doesn't charge for - memcache and edge caching. This is is highly > atypical. > > Jeff
I support far more than one type of app. Just because you don't like my answers, don't dismiss me just because one app I build does one thing that is optimized for caching. Even when Memcache and Datastore operations get slow, costs don't flux much. The Instance does other stuff when it is waiting for the API's to finish. Small apps (sub $30 a day) probably see this more than "medium apps" (sub $500 a day) because they are more likely to not have enough requests to keep the spare instance cycles busy. Again if you are use defer, and chron, optimizing your steady state should allow you to take advantage of these changes and your price should flux much less. If you set your QoS too high, you will have more change in price than you might like on slow days, but that is the "Cost" of having a responsive application. If you can live with 100ms more wait, then you will find that a "slow" day has to be a lot slower for you to feel the change in price. And yes, I optimize the heck out of my apps. If you don't that's your failing, not AppEngines. Oh, and just as mention, My F4 Instances doing pure computation stuff, flux less than 5% in cost on identical operations, except when there are new updates which so far have dropped my cost significantly with each update. If you really want to see performance and cost improvements, use NDB and watch your app get cheaper every update. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en.
