Heh, yes.. I printed out your Java and it seemed perfectly fine after
reading through it several times... But Java is just wayy to busy
looking for my tastes.
Good luck getting some clarification on what's happening with this.
On 3/3/10, Gary Orser wrote:
> Eli,
>
> Python as usual is sooo much
What I'm suggesting is.. You need to create a simple test setup that
recreates this dynamic request limit error.. (It definitely should not
take 8mb of code).
I will see if I can create a handler like the one you posted, deploy
it, and then run 30 seperate processes that keep getting from that
han
Correction/addition to my last email.
It turns out that our requests for this EC2 pull thing are actually much faster
now. Gary and our other devs have reworked it. I need updated numbers, but
they don't take 10s, probably more like 2s. We still have some heavy ~5s
services though, so the s
Nick,
If we (I work with Gary) require fairly heavy requests which run for multiple
seconds then it is not possible to get anywhere near 400 QPS. The math used
on the docs page only applies to 75ms requests.
(1000 ms/second / 75 ms/request) * 30 = 400 requests/second
so lets say each requ
Hi Gary,
Practically speaking, for an app that hasn't been given elevated
permissions, you should be able to have at least 30 concurrent requests -
equating to around 400 QPS if your app is fairly efficient. What problems
are you running into that lead you to conclude you're hitting a limit at 4
Q
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
