|
|
|
|
Back to newsletter 133 contents
Tuning for the cloud brings a new aspect to your tuning skills, that of factoring in the processing costs on a fine scale. Most other tuning work is done within the confines of existing hardware, or occasionally factoring the cost of upgrading hardware, where you can determine the cost-benefit of tuning alone versus tuning less together with hardware upgrades. Some applications have metered external access, and tuning here is usually about minimizing the cost of the external access, normally by caching or batching whatever possible to reduce the frequency of the external calls.
But tuning in the cloud has much more cost input than these other types of tuning. This probably isn't news to you, we've previously listed a few articles that have mentioned the cost aspect of tuning in the cloud. But Google App Engine's change in pricing announced earlier in the year brought this cloud tuning aspect to the fore - suddenly many applications tuned for one cloud resource pricing model were shifted into a different cloud resource pricing model and consequently needed to retune their application s or pay significantly higher costs. The situation as I understand it is that Google App Engine's pricing model previously charged mainly for CPU and not RAM, which meant that applications were obviously tuned by swapping CPU for RAM - which is actually one of the most traditional tuning techniques around (e.g. caching). The consequence was that RAM was heavily overutilised in Google App Engine applications.
The new pricing model switches focus to mainly pricing RAM with additional costs if you use CPU inefficiently, which certainly seems a rational pricing model. But the gotcha for developers is that an application sitting idle and doing nothing still uses RAM (there is a base cost-free allocation for this, but you still need to tune your app to use this effectively). So where previously you got free use of RAM when your application was idle, it can now cost. That's an interesting shift for tuners - you need to minimize or eliminate RAM usage when your application is idle, but you don't want to impact perceived speed of response. Additionally, with Google App Engine's new pricing model, datastore reads also cost money - so dumping your memory to storage, and retrieving it as needed, which is what you would do with a traditional application to save RAM usage, doesn't help in reducing cost.
Certainly an interesting new set of considerations for the performance tuner - see this month's news items below for links related to cloud tuning and the effect of Google App Engine's new pricing model. And also see below for our usual Java performance tools, news, and article links and, as usual, we give you all the extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 133 contents
