Comment by riobard | Hacker News Reader

Comment by riobard | Hacker News Reader

Parent Full thread

The single most import reason that I like GAE is that it used to charge based on CPU usage, so that I could carefully optimize my web apps to reduce costs. This is also why I think cloud computing is a good thing: shared resources are generally efficiently used.

Now that GAE starts charging by instance-hours, however they are calculated, the drive to optimize is significantly reduced: I no longer have to worry about a web app's CPU usage if I have to wait for I/O anyway.

Some will say that's how we, as developers, should allocate our time to improve productivity, but the cloud platform as a whole just becomes a lot more wasteful.

And this change makes GAE much less appealing than AWS. If I'm gonna pay for instance-hours anyway, why not just launch some EC2 instances and kill them when I don't need them anymore? Sure it comes with admin costs, but at least I can migrate to another cloud provider much easier. Judging from the comments on this thread, migrating away from GAE seems very expensive, if possible at all.

Indeed. The billing estimator they provide says that, on this one day, I was using 0.02 cpu-hours, and they estimate that under the new system that same activity will be billed as 2.8 instance-hour.

0.02 cpu-hours => 2.8 instance-hours

The only way this can possibly make sense is if they do the EC2 thing of "any part of an hour is billed as an hour", in which case, I might as well go with EC2.

Now, sure, when I'm using just a single instance, GAE is a nice way to get a webserver, a database, memcache, etc all set up and ready to go for a reasonable price. But if my business takes off, and I have enough traffic for multiple servers, and auto-scaling front-ends, etc, I'll be better off moving to EC2 or Rackspace.

Yes, this was my feeling too. The great thing about GAE was that you paid for CPU time, not CPUs. Which means that if I want to run something tiny I only pay for the tiny amount of CPU it uses.

Wouldn't the perfect cloud platform be one that charges based on disk IO, disk space used, network IO, RAM space used, (Ram IO?,) and CPU used? Maybe there are other metrics I'm ignoring.

Someone should start making this.

https://www.nearlyfreespeech.net/services/pricing been around since 2002, does automatic load-balancing, have most of the benefits of what people are calling "cloud-computing", makes no presumptions about language of choice, does MySQL, and is extremely competitively priced.

"makes no presumptions about language of choice"

Yes, but don't they do this by running everything as CGI scripts? That won't perform well.

http://example72.nfshost.com/versions.php

There's a 'pools beta' that runs your stuff in bsd jail. Worked well with mod_wsgi in my tests (I'm not using it in production though).

That's effectively what is was. Only RAM was missing from the calculation.

I've certainly seen virtualization environments where RAM is a much larger fraction of the physical server's cost than the CPUs. How much RAM are you using when you aren't using many CPU cycles?

How much RAM does a web server need waiting for socket I/O? Not a lot. For most typical web apps, an instance of web frontend consumes a small fraction of the system's total memory. You could fit a surprisingly lot of such instances into a modern machine.

Big consumers of memory tend to be caching layer, which could (should, actually) run on different machines and bill based on memory usage.

I have to admit scheduling CPU and memory is an issue, but that shouldn't be the excuse to adopt a model that discourage optimizing for CPU usage.

JVM web servers seem to use a ton of ram. I'd love to know of a good way to minimize it, if one exists

Oops, sorry, I neglected that. I was talking about GAE Python runtime.

Didn't the change make I/O free? If I recall correctly, you aren't charged for time waiting for API calls.

The change means that it doesn't matter what you're waiting for. As long as you have an instance up, you are charged for it, even if it's not actually doing anything at that moment.

The multithreading change, though, will mean that a single instance will wait for multiple I/O calls to return. If these aren't charged, you'll only need to pay for that single instance and nothing more.

Unfortunately there's a limited number of threads to handle requests (like 8 per instance) and you can't create new long-lived threads. While an improvement, it's not a solution to the problem.

Where do you get the "8 per instance"? I can't find any information about the number of threads per instance. Thanks

Supposedly it will change, but that's what's available in Python 2.7 preview. The number might be different on release, but I don't think the limit itself will be removed.

Ah, I wasn't aware of that... That is too bad...

Reply on news.ycombinator.com