On 22 May 2011 21:39, Anders <[email protected]> wrote: > Oh, you're right! Separating CPU and RAM usage would be a good idea (if it > can be done in practice). The price model already contains a large number of > different quotas for all kinds of APIs and stuff. Separating CPU and RAM > usage would not add much complexity. There is still of course the problem > with how to measure CPU time. Is idle CPU time included, or is 100% CPU load > the only measurement or is some other average combination used? >
I think the "current" (eg. live today, not after the change) method is the fairest - you're effectively billed for the CPU cycles. This way you can save money by optimising, and not charged when your app is idle. If RAM costs money, then that should be charged too. I'm a huge fan of paying for what you actually get, and no "all-you-can-eat" deals like the "newer" CPU billing. If you don't charge people for a resource, they will chomp it up. Why waste time optimising your CPU usage if the cost doesn't change? -- 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.
