Resource usage of google Go vs Python and Java on Appengine

JavaPythonGoogle App-EngineGo

Java Problem Overview


Will google Go use less resources than Python and Java on Appengine? Are the instance startup times for go faster than Java's and Python's startup times?

Is the go program uploaded as binaries or source code and if it is uploaded as source code is it then compiled once or at each instance startup?

In other words: Will I benefit from using Go in app engine from a cost perspective? (only taking to account the cost of the appengine resources not development time)

Java Solutions


Solution 1 - Java

> Will google Go use less resources than Python and Java on Appengine? > Are the instance startup times for go faster than Java's and Python's > startup times?

Yes, Go instances have a lower memory than Python and Java (< 10 MB).

Yes, Go instances start faster than Java and Python equivalent because the runtime only needs to read a single executable file for starting an application.

Also even if being atm single threaded, Go instances handle incoming request concurrently using goroutines, meaning that if 1 goroutine is waiting for I/O another one can process an incoming request.

> Is the go program uploaded as binaries or source code and if it is > uploaded as source code is it then compiled once or at each instance > startup?

Go program is uploaded as source code and compiled (once) to a binary when deploying a new version of your application using the SDK.

> In other words: Will I benefit from using Go in app engine from a cost > perspective?

The Go runtime has definitely an edge when it comes to performance / price ratio, however it doesn't affect the pricing of other API quotas as described by Peter answer.

Solution 2 - Java

The cost of instances is only part of the cost of your app. I only use the Java runtime right now, so I don't know how much more or less efficient things would be with Python or Go, but I don't imagine it will be orders of magnitude different. I do know that instances are not the only cost you need to consider. Depending on what your app does, you may find API or storage costs are more significant than any minor differences between runtimes. All of the API costs will be the same with whatever runtime you use.

Language "might" affect these costs:

  • On-demand Frontend Instances
  • Reserved Frontend Instances
  • Backed Instances

Language Independent Costs:

  • High Replication Datastore (per gig stored)
  • Outgoing Bandwidth (per gig)
  • Datastore API (per ops)
  • Blobstore API storge (per gig)
  • Email API (per email)
  • XMPP API (per stanza)
  • Channel API (per channel)

Solution 3 - Java

The question is mostly irrelevant.

The minimum memory footprint for a Go app is less than a Python app which is less than a Java app. They all cost the same per-instance, so unless your application performs better with extra heap space, this issue is irrelevant.

Go startup time is less than Python startup time which is less than Java startup time. Unless your application has a particular reason to churn through lots of instance startup/shutdown cycles, this is irrelevant from a cost perspective. On the other hand, if you have an app that is exceptionally bursty in very short time periods, the startup time may be an advantage.

As mentioned by other answers, many costs are identical among all platforms - in particular, datastore operations. To the extent that Go vs Python vs Java will have an effect on the instance-hours bill, it is related to:

  • Does your app generate a lot of garbage? For many applications, the biggest computational cost is the garbage collector. Java has by far the most mature GC and basic operations like serialization are dramatically faster than with Python. Go's garbage collector seems to be an ongoing subject of development, but from cursory web searches, doesn't seem to be a matter of pride (yet).

  • Is your app computationally intensive? Java (JIT-compiled) and Go are probably better than Python for mathematical operations.

All three languages have their virtues and curses. For the most part, you're better off letting other issues dominate - which language do you enjoy working with most?

Solution 4 - Java

It's probably more about how you allocate the resources than your language choice. I read that GAE was built the be language-agnostic so there is probably no builtin advantage for any language, but you can get an advantage from choosing the language you are comfortable and motivated with. I use python and what made my deployment much more cost-effective was the upgrade to python 2.7 and you can only make that upgrade if you use the correct subset of 2.6, which is good. So if you choose a language you're comfortable with, it's likely that you will gain an advantage from your ability using the language rather than the combo language + environment itself.

In short, I'd recommend python but that's the only app engine language I tried and that's my choice even though I know Java rather well the code for a project will be much more compact using my favorite language python.

My apps are small to medium sized and they cost like nothing:

enter image description here

Solution 5 - Java

I haven't used Go, but I would strongly suspect it would load and execute instances much faster, and use less memory purely because it is compiled. Anecdotally from the group, I believe that Python is more responsive than Java, at least in instance startup time.

Instance load/startup times are important because when your instance is hit by more requests than it can handle, it spins up another instance. This makes that request take much longer, possibly giving the impression that the site is generally slow. Both Java and Python have to startup their virtual machine/interpreter, so I would expect Go to be an order of magnitude faster here.

There is one other issue - now Python2.7 is available, Go is the only option that is single-threaded (ironically, given that Go is designed as a modern multi-process language). So although Go requests should be handled faster, an instance can only handle requests serially. I'd be very surprised if this limitation last long, though.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionPer ArnengView Question on Stackoverflow
Solution 1 - JavaproppyView Answer on Stackoverflow
Solution 2 - JavaPeter RecoreView Answer on Stackoverflow
Solution 3 - JavastickfigureView Answer on Stackoverflow
Solution 4 - JavaNiklas RosencrantzView Answer on Stackoverflow
Solution 5 - JavaFoxyLadView Answer on Stackoverflow