Как обслуживать запросы веб-сервисов с интенсивным использованием ЦП в облаке?

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

Каждый запрос можно разбить примерно на 150 независимых (и одинаково маленьких) подзадач.

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

Что я подумал: я изучил Google App Engine и Rackspace.

Мне кажется, что GAE предназначен для простых запросов, требующих небольших ресурсов для обработки. Проблема с чем-то вроде Rackspace заключается в том, что я не могу заранее сказать, сколько vCPU мне может понадобиться (и даже если бы я знал, насколько большими будут всплески в будущем, я не хочу сидеть, скажем, с 40 серверами, простаивающими остальные). время)

Вопросы:

  1. Можно ли использовать GAE следующим образом:

    1. Для каждого запроса разбейте его на 150 подзадач.

    2. Обрабатывайте все подзадачи независимо, выполняя 150 одновременных HTTP-запросов к одному и тому же веб-приложению (но другим методом).

    3. Соберите результаты из «подрезультатов» и верните ответ на исходный запрос.

  2. Есть ли вероятность, что Map Reduce для GAE может помочь?

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


cloud google-app-engine concurrency web-services rackspace
person aioobe    schedule 02.11.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

  1. Да, это возможно. Обычно используется Очередь задач, возможно, через DeferredTask вспомогательный класс.

    1.3 Обычные веб-запросы (к экземплярам внешнего интерфейса) ограничены 30 с, поэтому выполнение этого синхронным способом не гарантирует успеха. Также обратите внимание, что экземпляры искусственно ограничены выполнением 10 параллельных запросов (если включена многопоточность).

  2. Да, это задание для уменьшения карты. Но обратите внимание, что уменьшение карты является асинхронным — вы даете ему задачи, и это будет сделано когда-нибудь в будущем.

  3. Учитывая необходимую обработку, вы можете посмотреть на бэкенды GAE ( они давно работают с мультитрейдингом и используйте различные размеры). Если вам нужна еще большая вычислительная мощность, обратите внимание на Compute Engine.

person Peter Knego    schedule 03.11.2012

arrow_upward
0
arrow_downward

Если все эти 150 подзадач не доступны только для чтения, попытка запустить их все в одном потоке просто небезопасна. Веб-запросы ненадежны — люди могут отменить, нажать «Обновить», если это занимает слишком много времени, закрыть окна посередине или просто отключиться из-за проблем с сетью. Фоновые HTTP-запросы также могут иметь массу проблем. Стандартное решение состоит в том, чтобы ваш внешний код просто создавал список вещей, которые необходимо сделать, чтобы он мог быстро вернуться к пользователю, а внутренний «рабочий» процесс обрабатывал (потенциально ненадежные) подзадачи. . В зависимости от того, что делает ваше приложение, вы можете перенаправить пользователя на «рабочий» экран (например, поиск авиабилетов), где он может безопасно дождаться результатов, или он может быть просто заполнен. прочь как «ожидающую» работу (например, заказать что-то на Amazon).

Существует бесчисленное множество способов справиться с этим основным рабочим процессом. Если вы придерживаетесь Google App Engine, у них есть «очередь задач» как часть платформы. — предоставляет простые механизмы для создания и диспетчеризации фоновых задач. Если вы выберете Rackspace, их облачное предложение не будет похоже на унифицированную платформу, поэтому вам придется либо создать собственную очередь, либо получить ее для подключения к вашей установке.

person Sean McSomething    schedule 03.11.2012