Future Billing Advantages of Go

[rvjcallanan]

Given all the talk on billing recently, I am wondering how the Go platform would compare with Java and Python at some future date when the Go run-time is stable and the full efficiencies of the language can be exploited.

All other things being equal, a single Go instance should handle far more throughput than Java or Python instances by virtue of its tighter stack. Go should also make massive parallelism more practical in terms of cost. I am surprised that the potential cost advantages of Go have not been mentioned or have I missed something obvious? 

[Rodrigo Moraes]

On Jan 24, 5:17 pm, rvjcallanan wrote:
> I am
> surprised that the potential cost advantages of Go have not been mentioned
> or have I missed something obvious?

The Go advantage is related to concurrency and processing power. This
should affect the cost of backend and frontend instances: supposedly
you can deliver more responses per instance. *But* response times are
highly dependent on the RPC latency, which is theoretically the same
for all languages. And cost of RPC calls are the same and many items
are priced per unit. I'm curious about what is the result in practice,
but skeptical that it would mean much lower costs.

-- rodrigo

[Wilson MacGyver]

We've been playing with go, the one thing we've found is, go uses MUCH less
ram at least compare to java. By the time the instance starts up, our
JVM instances
is already using 45MB o 50MB.

the go version is about 3.9MB. While this doesn't translate directly
to lower billing.
with the recent changes, GAE is much more strict about the amount of
ram available to you.

go leaves you with much more of it, and opens the door to tricks that
you can do to take advantage
of it.

--
Omnem crede diem tibi diluxisse supremum.

[Rodrigo Moraes]

On Jan 25, 12:45 pm, Wilson MacGyver wrote:
> We've been playing with go, the one thing we've found is, go uses MUCH less
> ram at least compare to java. By the time the instance starts up, our
> JVM instances
> is already using 45MB o 50MB.

Ah yes, *fast* start-ups are a big advantage too. It is something you
have to take care in Python or Java but you basically don't worry
about in Go.

-- rodrigo

[Sanjay Menakuru]

Also, concurrency is awesome!

While waiting for an RPC to complete, if you can halfway handle the next users requests, thats pretty cool. And much more lightweight than Java threads.

Sanjay

[Wilson MacGyver]

I'm curious to see how go will handle allowing multiple threads. java
now has thread factory in trusted testing mode. which allow you to run
more than 1 threads on your instance.

but this potentially will be another advantage with go's lightweight
channel. I know you can use it now,
but it's multiplexed into a single thread.

--

[Kyle Lemons]

I actually run all of my daemons (non-GAE project) using only one OS thread (GOMAXPROCS=1) because the scheduler is not yet good enough to make it worth it to use more than one for active goroutines in my case.  We still have yet to even find the upper bound of what they can handle even on that one thread.  With something like GAE where you have relatively few goroutine switches that don't take "a long time" it might not make as much difference and you might see better request throughput.  It'd be interesting to test out.

[David Symonds]

On Thu, Jan 26, 2012 at 7:48 AM, Wilson MacGyver <wmac...@gmail.com> wrote:

> I'm curious to see how go will handle allowing multiple threads. java
> now has thread factory in trusted testing mode. which allow you to run
> more than 1 threads on your instance.

While that would be neat, it's worth pointing out that almost all web
apps are I/O bound, so CPU parallelism gains nothing.

Dave.

[vin...@callanan.ie]

While individual requests may be I/O bound, of more immediate interest is the aggregate performance of an instance over many concurrent requests (assuming that I/O latencies are non-blocking). I would argue that instance throughput is a key cost determinant for many GAE apps in light of the recent changes to instance scheduling.

For example, if a busy GO app requires an average of 5 active instances then an equivalent JAVA or PYTHON app might require as many as 50 based on what I have read thus far. This represents a significant cost saving for a GO implementation. More fine-grained concurrency would also allow for more efficient scheduling of background tasks from within the app.

I think it is important to tease out these issues. On the face of it, the GO run-time option is addressing key limitations of GAE that have emerged as the platform has evolved to meet the needs of the real world.

[Ikai Lan]

While David is right that most operations will be I/O bound, there's one hidden processing sink when you use GAE: protocol buffer serialization/deserialization. This is a problem in Python and even CPython protobuf libraries (GAE uses CPython protobuf). It's not a problem in Java. My assumption is it's a non-issue in Go.

--

Ikai

[Ugorji Nwoke]

Yes. most web apps are I/O bound, but that's only valid in a single-processing environment (like the classic python app engine instance where requests are handled serially). If requests are handled concurrently, and the number of concurrent requests is a factor of the CPU utilization, a GO runtime can theoritically handle many more concurrent requests than a Java or Python instance, even if the latency of each request is a factor of I/O cost. 

This is why it's still important to make the GO runtime/SDK very efficient (e.g. try not to use an excess of goroutines just to ensure a elegant API if the problem is not one of parallelism/concurrency. see thread: https://groups.google.com/forum/#!topic/google-appengine-go/ijMfskEqqk0)

This is actually one of my main reasons for using GO: I believe it can save me instance costs compared to python or Java. 

[Johnson]

has anyone fleshed this out a bit more? do equivalent java/python apps require 10x more instances for the same traffic?

[Wilson MacGyver]

I've never actually seen this happen myself. For our testing, the two areas that
gae-go performed great in was instance startup time and instance memory usage.

We use concurrent request on gae-java. which you can also use on gae-go.

On Sun, Apr 29, 2012 at 8:41 PM, Johnson <ben...@gmail.com> wrote:
> has anyone fleshed this out a bit more? do equivalent java/python apps
> require 10x more instances for the same traffic?
>

[Johnson]

that's disappointing. i was expecting the lower cpu/memory footprints would allow Go instances to handle more requests than python or java. what is the bottleneck that tends to require the spawning of new Go instances? i understand that it's based on how long the next request is expected to take, but what's causing that increase at the top end? running low on ram/cpu? or what?

[Wilson MacGyver]

well, in our case, it goes back to what David pointed out earlier,
which is in general I/O will
be the bottleneck for a lot of applications.

For us, the bottle neck is in fact I/O. Our usage case makes heavy
usage of blob store/file system service /(google storage on java
side). So while go is fast and uses very little ram, waiting for I/O
is still waiting
for I/O.

I suppose if you write gae-go app to say, do a bunch of computations.
go will win out here
big time.

But then, the biggest draw of GAE is the datastore/blobstore/memcache
able to infinite scale
(as much as you can afford to pay anyway). These are all I/O intensive.

[Johnson]

thanks, i understand now. i should be looking for opportunities to use excess ram and cpu resources, and minimize the use of things that require i/o. now to find a list of what types of things eat up the most i/o capacity...

[Johan Euphrosine]

On Tue, May 1, 2012 at 4:30 PM, Wilson MacGyver <wmac...@gmail.com> wrote:

well, in our case, it goes back to what David pointed out earlier,
which is in general I/O will
be the bottleneck for a lot of applications.

For us, the bottle neck is in fact I/O. Our usage case makes heavy
usage of blob store/file system service /(google storage on java
side). So while go is fast and uses very little ram, waiting for I/O
is still waiting
for I/O.

Yep, but my understanding is that when 1 goroutine is waiting for I/O another one could be spawned to handle an incoming request.

 

I suppose if you write gae-go app to say, do a bunch of computations.
go will win out here
big time.

But then, the biggest draw of GAE is the datastore/blobstore/memcache
able to infinite scale
(as much as you can afford to pay anyway). These are all I/O intensive.

On Mon, Apr 30, 2012 at 9:48 PM, Johnson <ben...@gmail.com> wrote:
> that's disappointing. i was expecting the lower cpu/memory footprints would
> allow Go instances to handle more requests than python or java. what is the
> bottleneck that tends to require the spawning of new Go instances? i
> understand that it's based on how long the next request is expected to take,
> but what's causing that increase at the top end? running low on ram/cpu? or
> what?
>
>
> On Monday, April 30, 2012 11:49:12 AM UTC-4, Mac wrote:
>>
>> I've never actually seen this happen myself. For our testing, the two
>> areas that
>> gae-go performed great in was instance startup time and instance memory
>> usage.
>>
>> We use concurrent request on gae-java. which you can also use on gae-go.
>>
>>
>

--
Omnem crede diem tibi diluxisse supremum.

--
Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

[Wilson MacGyver]

Oh? I haven't heard about this. On gae-java, a instance can handle
multiple request
if you enable concurrent request. But it just means more than 1
requests are sent to
a single instance. So if the nature of the request tend to be I/O
bound like ours,
all that means is the instance can handle the other requests.

My understanding of gae-go runtime was it's similar till the request level.
ie, each instance can handle multiple request. and each request
functionals independently,
now each request itself can use goroutines to do more stuff per se
just like in java
you can get a new thread from the thread factory.

are you suggesting we can spawn more goroutines ourselves to handle
more request?

On Wed, May 2, 2012 at 6:19 AM, Johan Euphrosine <pro...@google.com> wrote:
> Yep, but my understanding is that when 1 goroutine is waiting for I/O
> another one could be spawned to handle an incoming request.

[Kyle Lemons]

On Wed, May 2, 2012 at 10:49 AM, Wilson MacGyver <wmac...@gmail.com> wrote:

Oh? I haven't heard about this.  On gae-java, a instance can handle
multiple request
if you enable concurrent request. But it just means more than 1
requests are sent to
a single instance. So if the nature of the request tend to be I/O
bound like ours,
all that means is the instance can handle the other requests.

My understanding of gae-go runtime was it's similar till the request level.
ie, each instance can handle multiple request. and each request
functionals independently,
now each request itself can use goroutines to do more stuff per se
just like in java
you can get a new thread from the thread factory.

are you suggesting we can spawn more goroutines ourselves to handle
more request?

The go http library starts every request in its own goroutine automatically.  The upper bound on number of goroutines is much higher than the upper bound on threads.  I suspect Java on GAE either spawns a thread per request or uses a fixed-side thread pool.  Go, on the other hand, will use (currently) a single thread, but I/O on that thread causes a goroutine switch and not a thread switch, and so has the potential to be lighter weight.  The java case has had a lot more time to mature, however, so the performance characteristics comparing the two for a particular task will be difficult to predict.  The real difference is probably when spawning *extra* threads/goroutines to handle concurrent tasks during a request; I posit that the thread pool in this case will likely be less performant and require more code than its go counterpart (simply spawning N goroutines).

[Wilson MacGyver]

On Wed, May 2, 2012 at 3:55 PM, Kyle Lemons <kev...@google.com> wrote:
> The go http library starts every request in its own goroutine automatically.
>  The upper bound on number of goroutines is much higher than the upper bound
> on threads.  I suspect Java on GAE either spawns a thread per request or
> uses a fixed-side thread pool.  Go, on the other hand, will use (currently)
> a single thread, but I/O on that thread causes a goroutine switch and not a
> thread switch, and so has the potential to be lighter weight.  The java case
> has had a lot more time to mature, however, so the performance
> characteristics comparing the two for a particular task will be difficult to
> predict.  The real difference is probably when spawning *extra*
> threads/goroutines to handle concurrent tasks during a request; I posit that
> the thread pool in this case will likely be less performant and require more
> code than its go counterpart (simply spawning N goroutines).

interesting... when gae-go adds support for google storage, I'll have
to build a new
go version to try it out again. On F1 frontend instances, we can't get
each instance
to serve more than 9-10 request per sec with gae-java. Even upping to
F2 doesn't seem to help this.