Task queues and user facing requests

[MLTrim]

Hi there

I'm trying to squeeze the performance of a couple of applications I've hosted on GAE (python, No backend, M/R) and I'm starting to see some result on the estimated billing.
These applications have some background tasks, and before starting to optimize them, I would like to clarify some things about how task-queue and frontend billing works.

Are the Url requests invoked by a push task queue counted as User-facing requests?
For example, if I have a long 10 minute task, would this task keep busy an entire front-end instance for 10 minutes ?

If I remember correctly task-queue processes could run on a slow pool that don't interfer with web-facing requests? Am I right?

How the task triggered by the deferred api is counted?
Is it a background process? Does it count as a request?

Thanks
Michele [Systempuntoout]
www.stackprinter.com
www.gaecupboard.com

[stevep]

Additional Question:

1) How does the burst rate affect The Scheduler and instance counts?

Overall a detailed description of how TQs are handled now would be
terrific.

thnx,
stevep

[Joshua Smith]

There has been some discussion about this point in the comments on:

http://code.google.com/p/googleappengine/issues/detail?id=5773

Personally, I think throwing an error and depending on retry is a pretty ugly way to do prioritization, but it's an option.

[stevep]

Thanks Joshua. I did read that thread, but it is more speculative in
nature by the participants all of whom are not GAE engineers.

My thinking is that task queues can provide an excellent means for GAE
to improve overall instance efficiencies, but am still thinking about
that. Some initial thoughts...

I believe that one can avoid the burst/instance issues by setting a
queue "rate" to 1 (without specifying any "eta" or "coutdown" values).
If I am reading the TQ Python docs right, that will result in one task
being released when resources are available up to a max per second
rate equal to the TQ bucket size.

What is not clear is how the TQ scheduler interacts with the instance
scheduler. Reading the Python TQ docs, the description of the TQ
scheduler: "...The [TQ] system attempts to deliver the lowest latency
possible for any given task via specially optimized notifications to
the scheduler...." (Again, that is from the TQ docs, not the Instance
Scheduler.)

If the instance scheduler communicates effectively with the TQ
scheduler, I think there can be some very significant efficiencies --
but I'm just not sure.

For example, My typical architecture is to cascade my High Replication
puts(): 1) On-line handler puts critical "can not fail" record, then
launches a task if secondary records are needed, 2) task will complete
a secondary record put(), then launch another task for next secondary
put(). I don't do any very-long processing in these queues -- just
write functions that can be split out from the on-line handler because
their data recs do not need to be immediately available. Tasks are
almost always launched serially - i.e. the last statement in the
handler function is the TQ add, the last statement in the first TQ
task will launch the next TQ task, etc.

Right now I am thinking to stay with this because it seems very likely
that instance optimization can be realized by GAE using TQs. The
reason for this is TQ scheduler can offer a lot options to the
instance scheduler -- it can let TQ task latency build to minutes
rather than seconds, and it can cherry-pick tasks if the available
instance resource is not big enough to handle the task at the front of
the queue. Again, the latter is my reading of the Python docs:
"...Thus, in the case that a queue has a large backlog of tasks, the
system's scheduling may 'jump' new tasks to the head of the queue."

However, if I can not get my burst rate = 1, then TQ parallelism could
be very bad for instance costs.

Sorry this got so long. Love TQs, and am hoping they are part of the
long-term plan.

cheers,
stevep