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