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.
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.
--
> 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.
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.
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.
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?