This would be the absolute worst of all worlds. In this model, a single-threaded java application would be charged the same as a multithreaded java application, even though the single-threaded system requires 20X more RAM to serve the same # of requests.
Wall-clock time is only an accurate measure of cost in an inefficient single-threaded system; I'm guessing you are on Python. Google needs to rationalize GAE pricing because they've been charging for CPU but building an architecture where the primary scarce resource is RAM. The ironic thing is that they're changing the pricing model just as they roll out a new architecture that should (hopefully) rebalance resource consumption towards CPU. Jeff On Tue, May 31, 2011 at 6:00 PM, Albert <[email protected]> wrote: > Hi AppEngine Team! > > I know you've spent significant time and energy in coming up with your > new pricing model. But I hope that even though you've already > announced your new proposed pricing changes, you would still be open > to a suggestion. > > You see, I'm really wondering why we can't be charged for exactly what > we use. How about letting us pay for the total time our requests take? > Like if I had 1,000,000 requests in a day, and each one averaged at > around 100ms each, then I'd end up paying for 27.778 hours (you can > make a new price per hour for this unit), irregardless of how many > instances were used to process those requests. > > IMHO, the current pricing changes doesn't seem to put a real burden on > you (Google) to provide a highly efficient scheduler. I think it even > "tempts" you to make it not so efficient so that we end up paying for > more. You could be placed in a spot where your "Don't be Evil" motto > could be questioned. I think we're all not comfortable with that. > > However, if we pay for what we actually use (not in CPU time, but in > latency/real ms consumed for each request), developers like me won't > have to worry whether or not your scheduler is actually working > optimally for me or not, because the burden is on you to save on cost > by provisioning and taking down instances efficiently. You can even > abstract this whole instances factor from us, which gives us one less > factor to consider, and we can focus more on optimizing our apps > towards lower latencies. > > IMHO, this seems to be a more WIN-WIN scenario. > > What do you think? > > -- > 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. > > -- 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.
