AppEngine Go realworld performance compared to Java? instance loading, concurrent requests?

[awx]

Do projects written in Go for GAE perform better than Java? Can AppEngine spin up instances of Go apps more quickly then Java? Is the Go environment better at serving concurrent requests?

My smallish Java projects are written in such a way that I think they could be translated in Go in a week or two. Reading the Go press releases, it is made to sound like apps written in Go would load and begin serving much quicker than a Java version and limit the loading problems that the Java version has. Does Go actually deliver any performance benefits?

"Also, although goroutines and channels are present, when a Go app runs on App Engine only one thread is run in a given instance. That is, all goroutines run in a single operating system thread, so there is no CPU parallelism available for a given client request. We expect this restriction will be lifted at some point."

That sounds bad.

[Sanjay Menakuru]

One thing I noticed about Go apps is that they can spin up a new instance incredibly quickly.

For me, its like 50-100 ms to spin up a new instance. Probably because its just the time to copy the binary across the network and run it, as opposed to spinning up a JVM.

Now, one thing to note is that external file accesses (reading template files etc) is strangely expensive. Unlike the sub millisecond time I get on a local machine, it'll be more like 70 ms in production. I suspect that youre not really in a local filesystem, but a FUSE-like filesystem where local file accesses are network operations the first time and are cached after that. So I suggest keeping your templates for dev on the local filesystem, then minify them, and put them in code, instantiating the template from a string literal. This gives me ease of development, and excellent performance using templates. Also, I suggest parsing templates on first use, not at startup.

As for concurrent requests, it doesn't have them yet. Hopefully, it will be out soon, near the python concurrency update.

I could never get Java starting up in faster than 2 seconds, so 50 ms as a new low time point is pretty amazing for me. It gives a lot more flexibility playing with Max-Pending-Latency because I know starting up instances wont take that long.

Sanjay

[Wilson MacGyver]

Our primary app is on GAE-J, using gaelyk.

we also have an experimental version using go. What we've noticed is
the ram usage is much much lower. an average GAE-J instance for us, is about
64MB to 72MB.

a typical go instance is about 4MB.

It's easy for you to try it yourself for your usage case though, you
can just write a
couple of simple go functions and deploy it as a different version for your app.

there are a few other limitations on the GO side, no namespace support yet, no
backend yet, and no concurrent request is a big one.

we end up with a lot more go instances vs GAE-J during stress test.

--
Omnem crede diem tibi diluxisse supremum.

[Ikai Lan (Google)]

Sanjay,

You're pretty observant =). Yes, the filesystem is a distributed virtual filesystem. One more cool thing to know: loading a single big file is better than loading a lot of tiny files. Some performance testing has shown that for frameworks that do classpath scanning on startup (JDO/JPA), loading classes from a big JAR file is better than a lot of little classes. Of course, I feel like this would be a bit of an overoptimization if you were looking to do this for your templates by just making a giant template that's loaded once and split up at render time.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

plus.ikailan.com | twitter.com/ikai

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/c_jvZfVchdMJ.

To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Sanjay Menakuru]

Yea, what clinched it for me was when loading a template from disk took longer than it took to spin up a new instance of my app. A dead giveaway, if ever there was one :)

Someone at google backported the current Go template library to the version of Go running on Appengine, and it supports multiple templates in one file, if you want to go that way, itll be only one network read per instance (per file).

Since I was minifying anyways, and had a foo.template and a minified version named foo.min.template, it made sense for me to switch to a model with a foo.template and a foo.template.go. In the go file, I just have the minified template as a string literal. Since this is compiled into the binary, no file access!

For people who dont have a distinct minify step, maybe the multiple templates in a file option is the way to go. But I highly recommend having a minify step for all of your html, css, and js anyways, it can save you a significant amount of time from startup, and will save you and your users some bandwidth

Sanjay

[Tim]

On Saturday, 10 September 2011 00:33:23 UTC+1, Ikai Lan wrote:

You're pretty observant =). Yes, the filesystem is a distributed virtual filesystem. 

OT (but see my reply to queries about hibernation of processes) but is it AFS?

I know the Google CIO has a background of a very large global AFS based system (which is not entirely without its own issues), but I'd be interested to know what you're using, or if you can't say, perhaps you can at least what its NOT !

Cheers

--

T

[Ikai Lan (Google)]

To me, AFS stands for "AdSense for Search."

Have a great weekend!

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

plus.ikailan.com | twitter.com/ikai

T

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/vr_DXaIM2YAJ.

[Brandon Thomson]

Thanks for this compiled template idea, Sanjay. I implemented it on a go app with about 30 templates today and it took average cold start time from 250ms down to just over 100ms.

Even better is that I suspect this will reduce the chance that instances will fail to start correctly during the occasional performance problems with the distributed filesystem (on the Python runtime these show up as DeadlineExceeded errors during an import statement).

This is a great tip. Did you think about crossposting to google-appengine-go?

[Sanjay Menakuru]

This is a great tip. Did you think about crossposting to google-appengine-go?

Yeah, sure I'll do it.

Sanjay