Является ли Amazon SQS правильным выбором здесь? Проблема производительности рельсов [закрыто]


Я близок к выпуску приложения rails с общими сетевыми функциями (обмен сообщениями, стена и т. д.). Я хочу использовать какую-то фоновую обработку (скорее всего, Bj) для выгрузки задач из цикла запроса/ответа.

Это происходит, когда пользователи приглашают друзей по электронной почте присоединиться и получать уведомления по электронной почте.

Я не уверен, должен ли я просто отбросить эти приглашения и уведомления в свою базу данных, используя модель, а затем просто обрабатывать ее с помощью рабочего процесса каждые x минут или если я должен пойти на Amazon SQS, храня сообщения и приглашения там, и пусть мой работник извлекает его из Amazon SQS для обработки (отправки приглашений / уведомлений).

Подход Amazon снимет нагрузку с моей базы данных, но я думаю, что там медленнее получать сообщения.

Что ты думаешь?

5   5   2009-05-23 17:04:05

5 ответов:

В вашем заголовке говорится, что у вас есть проблема с производительностью Rails, но знаете ли вы это наверняка? Из остальной части вашего вопроса это звучит так, как будто вы пытаетесь предвидеть возможную будущую проблему производительности. Единственный способ разумно справиться с проблемами производительности - это поместить ваше приложение в дикую среду и профайлинговать его. Это даст вам эмпирические данные о том, каковы реальные проблемы производительности.

Учитывая, что Amazon SQS не является бесплатным и тот факт, что его использование почти наверняка добавьте сложность в ваше приложение, я бы мигрировал в него , если и , Когда загрузка базы данных становится проблемой. Не пытайтесь предугадать проблемы, прежде чем они возникнут, потому что вы обнаружите, что, скорее всего, столкнетесь с различными проблемами, когда ваше приложение начнет работать, некоторые из которых вы, вероятно, не рассматривали.

Суть в том, что вы уже решили использовать фоновую обработку, что является правильным решением, учитывая, что любой вид обработки, который не является мгновенным, не делает принадлежите к циклу запроса/ответа Rails, так как он блокирует этот процесс Rails. Вы всегда можете масштабировать с Amazon позже, если вам это нужно.

Ваше приложение уже размещено на Amazon EC2? Я, вероятно, не стал бы перемещать существующее приложение на AWS только для того, чтобы использовать SQS, но если вы уже используете инфраструктуру Amazon, SQS-отличный выбор. Вы, конечно, можете настроить свою собственную систему обмена сообщениями (например, RabbitMQ), но, перейдя на SQS, вам придется беспокоиться об этом еще на одну вещь.

Есть много вариантов добавления фоновой обработки в приложения Rails, такие как delayed_job или background_job, но мой личный фаворит Workling. Это дает вам хороший слой абстракции, который позволяет подключать различные фоновые бегуны без необходимости изменять фактическую реализацию ваших заданий.

Меня вилка Workling, что добавляет ЗК клиента. Есть некоторые недостатки (читайте комментарии или мой пост в блоге для более подробной информации), но в целом это хорошо работало для нас в моем последнем запуске.

Я также использовал SQS для отдельного проекта Ruby (non-Rails) и вообще нашел его надежным и достаточно быстрым. Как указал Джеймс выше, вы можете прочитать до 10 сообщений одновременно, поэтому вы определенно захотите сделать это (мой клиент Workling SQS делает это и буферизует сообщения локально).

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

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

В настоящее время я проталкиваю пару миллионов сообщений в месяц через SQS, и это работает довольно хорошо. Убедитесь, что вы планируете, чтобы он был вниз или медленно время от времени, так что вам нужно будет работать в некоторых повторов объектов и экспоненциального отката. Одна из приятных вещей заключается в том, что вы можете получить 10 сообщений одновременно, что ускоряет работу через очередь, вы можете использовать один запрос, чтобы получить 10 сообщения и обрабатывать их 1 на 1.

Amazon SQS-отличный сервис, за исключением тех случаев, когда важны следующие вещи:

  • производительность
  • юридические
  • подтверждения и транзакции
  • Идиомы Сообщений Свойства Сообщений
  • безопасность, аутентичность и очередь
  • разрешения

Если какая-либо из этих вещей важна, вам нужно посмотреть на реальную службу enterprise MQ, такую как StormMQ, RabbitMQ или даже onlinemq.com.

Я нашел эту серию блогов интересной, как это сравнивает Amazon SQS с StormMQ, не сдерживая никаких ударов в ответ: http://blog.stormmq.com/2011/01/06/apples-and-oranges-performance/

Если у вас возникли проблемы с переходом на EC2, вы можете использовать другие сервисы, такие как onlinemq.com.