4 ms·
I'm seeing going from $0 to around $1 per day (can be as low as $0.25), all of it for CPU hours. This can be seen in billing history. That's obviously not some
by kkowalczyk 15y ago
I'm seeing going from $0 to around $1 per day (can be as low as $0.25), all of it for CPU hours. This can be seen in billing history.
That's obviously not something to be happy about but then again an argument can be made that the introductory free quota that Google gave was very generous.
This might give Go a push - as I understand it Go is the most efficient of the supported languages which should translate into less CPU hours => less money. On the other hand, other than template parsing/substitution, my code doesn't do any CPU intensive tasks. On the other hand, the CPU hrs might count the overall overhead of the platform, which for statically linked Go will be the smallest (both Python and Java have sizable runtimes that need to be initialized at startup - according to http://www.youtube.com/watch?v=HQtLRqqB-Kk http://www.youtube.com/watch?v=HQtLRqqB-Kk, Java runtime is especially bad in that regard (this is towards the end of the talk in the q&a part).
- StavrosK 15y agoYou should also note that CPU hours turn into instance hours in the new pricing, but it's a straight conversion. With multithreading, the instances you use will go down, perhaps significantly. I believe they will about match your CPU hours, so you might see comparable pricing (if the price per instance hour is the same as the old CPU hour, anyway).
- ww520 15y agoI don't think it's a matter of Python/Java being slow and GO is faster. It actually doesn't matter which language you pick. If your GO app is IO/network bound, you will be charged for the idle CPU hours in the new billing scheme.
- antrix 15y agoGo isn't going to help at least in the near term. Concurrent request handling is not supported on Go. Nor do they have it on their roadmap, AFAIK.