Google Appengine / Python: Могу ли я рассчитывать на повторную попытку очереди задач из-за невозможности свести вставки к минимуму?

Question

Скажите, что у моего приложения есть страница, на которой люди могут добавлять комментарии. Скажем, после добавления каждого комментария добавляется рабочий. Таким образом, если добавлено 100 комментариев, то добавляется 100 задач.

(примечание: выше приведен гипотетический пример, иллюстрирующий мой вопрос)

Скажем, я хотел убедиться, что количество вставок сохраняется на минимум (поэтому я не сталкиваюсь с пределом вставки 10 КБ)

Могу ли я сделать что-то следующим образом.

a) По мере добавления каждого комментария вызывайте taskqueue.add (name = "stickytask", URL = "/ л") - Поскольку это именованная очередь задач, она не будет повторно вставлена, если задание с таким же именем существует.

b) Рабочий URL-адрес / blah читает вновь добавленные комментарии, обрабатывает первый и чем если обрабатывается больше комментариев, возвращается код состояния кроме 200 - Это обеспечит повторное выполнение задачи и при следующей попытке обработать следующий комментарий и так далее.

Таким образом, все 100 комментариев обрабатываются с добавлением 1 или нескольких задач. (Примечание: если есть затишье в деятельности, где новые комментарии не добавляются и все комментарии обработано, чем следующий добавленный комментарий приведет к добавлению новой очереди задач. )

Однако из документов (см. Фрагмент ниже) отмечается, что «система будет постепенно отступать ". Означает ли это, что на каждом" не 200 "Http возвращен код состояния, вставлена ​​ли задержка при следующей попытке?

Из документов: Если выполнение конкретной задачи не удается (путем возврата любого HTTP код состояния, отличный от 200 OK), App Engine будет пытаться повторить до это успешно. Система будет постепенно отключаться, чтобы не затопить Ваше приложение слишком много запросов, но оно будет повторено неудачно задачи по крайней мере один раз в день, как минимум.

Answer 1

Нет причин фальсифицировать неудачу (и нести отсрочку и т. Д.) - это хакерская и хрупкая договоренность. Если вы опасаетесь, что простое планирование задачи для каждого нового комментария может превысить текущие строгие ограничения для очередей задач, тогда «пакетируйте» еще не обработанные комментарии в хранилище (и, возможно, также в memcache, я полагаю, для потенциального ускорения, но это необязательно) и не планируйте никаких задач на это время.

Скорее, продолжайте выполнять (скажем) задание cron каждую минуту, что может относиться к некоторым комментариям или планировать соответствующее количество задач для обработки ожидающих комментариев - поскольку вы планируете задания только из одного задания cron, легко обеспечить Вы никогда не планируете более 10000 в день.

Не позволяйте очередям задач заставить вас забыть о том, что cron также присутствует: хорошая архитектура для "пакетной" обработки, как правило, будет использовать как задания cron, так и задачи с очередями, чтобы упростить общий дизайн.

Чтобы максимизировать объем полезной работы, выполняемой за один запрос (из эфира в очередь или cron), рассмотрите подход, основанный на мониторинге использования вашего ЦП - когда ЦП ограничивает фактор работа, которую вы можете выполнить по запросу, это может помочь вам получить как можно меньше небольших планируемых единиц работы за один запрос, насколько это целесообразно. Я думаю, что этот подход более надежен, чем ожидание OverQuotaError , его перехват и быстрое закрытие, поскольку это может иметь другие последствия вне контроля вашего приложения.