GAE max. Task Queue processing rate

1
votes

Questions:

  1. Is it possible to process more than 500 tasks per second per one task queue?
  2. Is it possible to process more than 50.000 tasks per second per one GAE app?

Details:

Task queue quota documentation says:

Push Queue Limits
Queue execution rate: 500 task invocations per second per queue

Combined Limits (Push and Pull Queues)
Maximum number of active queues (not including the default queue) >
Free apps: 10 queues, Billed apps: 100 queues

500 * 100 = 50.000

I'm pushing our GAE app to its limits and my goal is to reach more than 100.000 processed requests per second.

It's possible:
http://googlecloudplatform.blogspot.com/2013/12/013-year-in-review-topping-100000-requests-per-second.html

I don't know if they used task queues at all.

Thank you for giving any hints!

1
pythongoogle-app-enginetask-queue
Two things here. #1 task queue requests have nothing to do with the web requests that they article is referring to. #2 does your app have a 1-to-1 relationship between a web request and task queue request? Or more specifically, why are task queue quotas relevant to the number of processed rps you want to achieve? - Josh J
Yes, it's 1-to-1 relationship for REST API requests to my app (my app processes messages, it's an integration platform). Other web requests are processed without task queue. - Adam Pawluczuk

1 Answers

1
votes

The answer would be no to both questions if using push queues, those are the task queue quotas.

You could go higher if using pull queues and you don't exceed other quotas - there is no execution rate limit for pull queues (that really depends on the worker configuration/scalability)

As Josh said, the article refers to web requests, not task queue requests. And that 100k rps just happens to be that specific app's top measured rate, it doesn't mean it can't do better.

The actual rate of successful responses to the web requests may be limited by the safety or billing limits/quotas imposed to various pieces of infra your app uses in building the responses to those requests. GAE usually still responds to the additional requests, but with error reponses (well, maybe not if the outgoing bandwidth quotas are also reached).

But if your app doesn't use any infra with quotas (say, for example, if it serves only static content) its response rate is limited only by the requests quotas, which for billed apps translate to 10 GB/minute outgoing bandwidth. If, say, your static content responses have 1K that'd amount to ~174k rps, if they have only 100 bytes the max would be a whooping ~1.747.000 rps. And so on.

As you see, the functionality, design and implementation of your app and the money you're willing to spend matter a lot in the performance you can achieve on GAE.