4 ms·

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

by riobard 15y ago

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.

jnw2 15y ago
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?
- riobard 15y ago
  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.
  - jshen 15y ago
    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
    - riobard 15y ago
      Oops, sorry, I neglected that. I was talking about GAE Python runtime.
Hawramani 15y ago
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.
- buff-a 15y ago
  That's effectively what is was. Only RAM was missing from the calculation.
- sdrinf 15y ago
  https://www.nearlyfreespeech.net/services/pricing 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.
  - sciurus 15y ago
    "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 http://example72.nfshost.com/versions.php
    - sergeys 15y ago
      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).
buff-a 15y ago
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.
StavrosK 15y ago
Didn't the change make I/O free? If I recall correctly, you aren't charged for time waiting for API calls.
- andypants 15y ago
  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.
  - StavrosK 15y ago
    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.
    - sergeys 15y ago
      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.
      - StavrosK 15y ago
        Ah, I wasn't aware of that... That is too bad...
      - ool 15y ago
        Where do you get the "8 per instance"? I can't find any information about the number of threads per instance. Thanks
        sergeys 15y ago
        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.
AndrewDucker 15y ago
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.

by riobard 15y ago

jnw2 15y ago

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?

riobard 15y ago
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.
- jshen 15y ago
  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
  - riobard 15y ago
    Oops, sorry, I neglected that. I was talking about GAE Python runtime.

Hawramani 15y ago

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.

buff-a 15y ago
That's effectively what is was. Only RAM was missing from the calculation.
sdrinf 15y ago
https://www.nearlyfreespeech.net/services/pricing 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.
- sciurus 15y ago
  "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 http://example72.nfshost.com/versions.php
  - sergeys 15y ago
    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).

buff-a 15y ago

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.

StavrosK 15y ago

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

andypants 15y ago
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.
- StavrosK 15y ago
  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.
  - sergeys 15y ago
    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.
    - StavrosK 15y ago
      Ah, I wasn't aware of that... That is too bad...
    - ool 15y ago
      Where do you get the "8 per instance"? I can't find any information about the number of threads per instance. Thanks
      - sergeys 15y ago
        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.

AndrewDucker 15y ago

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.