Как создать X задач как можно быстрее в Google App Engine

Question

Мы выдвигаем оповещения от GAE, и, скажем, нам нужно отправить 50 000 оповещений на CD2M (обмен сообщениями устройств 2 в облаке).Для этого мы:

1. Читаем всем, кому нужны оповещения из хранилища данных
2. Цикл и создаем «задание push» для каждого уведомления

Проблемазаключается в том, что создание задачи занимает некоторое время, поэтому оно не масштабируется при увеличении пользовательской базы.По моему опыту, мы получаем 20-30 секунд, просто создавая задачи, когда их много.Причина одной задачи пр.push-сообщение так, что мы можем повторить задачу, если что-то не получится, и это повлияет только на одного подписчика.Также C2DM поддерживает отправку только одному пользователю за раз.

Будет ли это быстрее, если мы:

1. Читаем всем, кто хочет получать оповещения из хранилища данных
2. Цикл и создание «задачи пула» для каждых 100 подписчиков
3. Каждая «задача пула» будет генерировать 100 «push-задач» при выполнении

Выполнение задачи очень быстрое, поэтому в нашем сценарии кажется, что создание задач является узким местома не выполнение заданий.Вот почему я подумал об этом сценарии, чтобы увеличить параллелизм приложения.Я предполагаю, что это приведет к более быстрому выполнению, но с другой стороны, я могу ошибаться :-)

Answer 1

Звучит так, как будто меняется в зависимости от количества отправляемых оповещений, продолжительности отправки каждого оповещения и количества запущенных активных экземпляров.

Я предполагаю, что отправка оповещения CD2M занимает от нескольких миллисекунд до десятков миллисекунд, в то время как для запуска экземпляра требуется несколько секунд, поэтому вы, вероятно, можете выдать несколько сотен или несколько тысяч предупреждений до того, как обоснование другого экземпляра задачи. Отношение количества времени, которое требуется для отправки каждого сообщения CD2M, к времени, которое требуется для запуска экземпляра, будет определять, сколько сообщений вы хотите отправить за задачу.

Если у вас уже есть достаточное количество запущенных экземпляров, у вас нет задержки для ожидания запуска экземпляров.

Кстати, это выглядит почти как идеальное приложение API MapReduce. Он в основном выполняет то, что вы описали во второй версии, за исключением того, что он принимает ваш первоначальный запрос и разбивает его на подзапросы, каждый из которых возвращает «страницу» набора результатов. Задача запускается для каждого подзапроса, который обрабатывает все элементы на своей «странице». Это улучшение по сравнению с тем, что вы описываете, потому что вам не нужно тратить время на просмотр исходного набора результатов.

Я считаю, что реализация по умолчанию для API MapReduce просто запрашивает все объекты определенного вида (т.е. все объекты пользователя), но вы можете изменить используемый фильтр.

Answer 2

Мы делаем нечто подобное с APNS (Apple Push Notification Server): мы создаем задачу для пакета уведомлений за раз (= задача пула, как вы ее называете). Когда задача выполняется, мы перебираем пакет и отправляем его на сервер push.

Разница в вашей настройке заключается в том, что у нас есть отдельный сервер для связи с push, поскольку APNS поддерживает только сокетную связь.

Единственный недостаток - если есть ошибка, тогда вся задача будет повторена, и некоторые пользователи могут получить два уведомления.