test/meTest?id=2 200 3008ms 0cpu_ms 0kb gzip(gfe)
> 03-02 08:35PM 22.623 /test/meTest?id=3 200 3009ms 0cpu_ms 0kb gzip(gfe)
> 03-02 08:35PM 22.603 /test/meTest?id=4 200 3008ms 0cpu_ms 0kb gzip(gfe)
>
> Once I start testing with more than 4 threads, it starts to slow down in its
> response ti
test/meTest?id=2 200 3008ms 0cpu_ms 0kb gzip(gfe)
> 03-02 08:35PM 22.623 /test/meTest?id=3 200 3009ms 0cpu_ms 0kb gzip(gfe)
> 03-02 08:35PM 22.603 /test/meTest?id=4 200 3008ms 0cpu_ms 0kb gzip(gfe)
>
> Once I start testing with more than 4 threads, it starts to slow down in its
> response ti
this up in less than 10kb or python code)...
>
> My guess is this will work. Without seeing sample code.. I can't tell
> where you may be going wrong (or where GAE may be breaking)
>
> On 3/2/10, Gary Orser wrote:
>
>
>
> > Actually, 4 threads was before we op
this up in less than 10kb or python code)...
>
> My guess is this will work. Without seeing sample code.. I can't tell
> where you may be going wrong (or where GAE may be breaking)
>
> On 3/2/10, Gary Orser wrote:
>
>
>
> > Actually, 4 threads was before we op
er dynamic request limit (only 4
> could run). This suggest that there is an important detail to how your
> "threads" are doing their work.. and we would need that to provide useful
> help.
>
> Thanks for info.
>
> On Tue, Mar 2, 2010 at 10:01 AM, Gary Orser wrot
ve at a time by
> > default; if the pages you're serving actually take 3 seconds to
> > complete you'll need to optimize things a whole lot or be stuck with a
> > 3.33 request/sec maximum.
>
> Actually, the default limit is 30 active requests.
>
> -Nick Johnso
ve at a time by
> > default; if the pages you're serving actually take 3 seconds to
> > complete you'll need to optimize things a whole lot or be stuck with a
> > 3.33 request/sec maximum.
>
> Actually, the default limit is 30 active requests.
>
> -Nick Johnso
he
> GAE team. We would very much like to continue working with you to figure out
> what actions we can take and what provisioning we can do to make our product
> successful and scale it as we grow in the near future. Gary Orser will be
> replying to this thread soon with more findin
Hi all,
We were trying to create programmatic parallel access to our appengine
application.
>From EC2, we were attempting (with threads) to run parallel access
(url gets/posts) to
our appid. There are some long running processes that we need to run
on EC2, for which
we would like to get a bunch
I have a couple of patches to to 1.25, which will work around this
problem.
The real problem is that the current implementation writes the entire
datastore to
disk, after each put, delete, or transaction. One tradeoff you can
make is, "not" to
guarrantee the transactions, by persisting to disk
10 matches
Mail list logo
