3 ms·
I agree with the author that GAE is fascinating, for hosting large scale web apps. But I strongly recommend to avoid using the Java runtime on GAE. Each GAE ins
by tapirl 9y ago
I agree with the author that GAE is fascinating, for hosting large scale web apps.
But I strongly recommend to avoid using the Java runtime on GAE. Each GAE instance has very limited memory, 128M (the prices of high memory instances are much higher). 128M is not enough for most Java web apps! Another big problem of Java apps on GAE is a general Java app needs 20 seconds to fully warm-up (considering that the 128M instance has a 600MHz CPU). GAE instances stop and start frequently. If a user visits your website and the visit is served by an instance which has not warmed-up yet, the unlucky user will wait 10s+ to get responded. Then the user experience is very bad. (GAE really provides a way to avoid cold instances serving requests, but the way is tedious to setup and often needs more instances to run. More instances mean higher cost.)
So if you would like to use GAE to host your web app, Go is most preferred. Go instances consume much less memory than Java instances (less than 1/5) and need much less time to fully warm-up (less than one second, so you don't need to handle the cold instance problems at all).
Just my personal experiences.
- stickfigure 9y agoAs someone that's been building GAE apps on Java since the runtime first launched... well, it's a mixed bag, mostly good. It works fine for basic web apps. If you have any significant traffic it's a good idea to upgrade to F2 or F4 instances; you get more throughput per-instance so it's break-even costwise. The instance warmup time tends not to be an issue at scale, but it does mean you end up paying for more idle instances than "optimum". It's still cheaper than hiring a devops team. The cool thing about GAE is that you can build a multi-million-dollar business with a couple engineers and they can both go camping for a weekend at the same time. Go is nice on GAE because you have near-zero instance start time. But then you must work in Go, which is a poor language for general business processing (despite its other merits). The Go runtime also lags behind the Java and Python runtimes on GAE Standard. The GAE community does not think "Go is most preferred"; actually the GAE/Go community tends to whine a bit about support. It's not perfect, but then again nothing is.
- tapirl 9y agoYes, if the traffic of your web app is large and need tons of GAE instances, then the memory and warm-up problems will become much less severe. But if the traffic is not large, then the two problems are the big obstacles to save spending and happy roll deployments. One the other hand, Go is good for both low traffic and high traffic websites. I disagree on "Go is a poor language for general business processing". The current Go runtime on GAE is very mature to build all kinds of websites.
- cube2222 9y agoI love Go and use it daily, but it really is inferior to other languages for general business processing. The lack of generics, and a nice map, filter, reduce, flatten workflow cause this for me. Sometimes I'll just use goderive then, but it still looks clunky. (No pipe or fluent API)
- jpalomaki 9y agoHaven't been working too much with Java lately, but I think the main cause for the slow startup times are the frameworks. Many frameworks such as Spring had different use case in mind and therefore different things were optimized (for example easy of packaging/deployment vs app startup times). Scanning the classpath, generating proxies etc done at the application startup.
- tapirl 9y agoYes, framework libraries loading contributes much of the 20s warm-up time. However loading the libraries in the official GAE Java SDK will also occupy about 7 seconds if the request needs handle datastore even if frameworks are not used.