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

Важность синхронизации или использования ConcurrentHashMap не может быть занижена.

До тех пор, пока пару лет назад у меня не было ложного впечатления, мне не удавалось синхронизировать только операции размещения и удаления в HashMap. Это, конечно, очень опасно и фактически приводит к бесконечному циклу в HashMap.get () на некоторых (я думаю, ранних 1.5) jdk.

То, что я сделал пару лет назад (и на самом деле не должно быть сделано):

public MyCache {
    private Map map = new HashMap();

    public synchronzied put(String key, Object value){
        map.put(key,value);
    }

    public Object get(String key){
        // can cause in an infinite loop in some JDKs!!
        return map.get(key);
    }
}

РЕДАКТИРОВАТЬ : думал, что я добавлю пример того, что не делать (см. выше)

5
задан Jonik 17 April 2010 в 14:21
поделиться

3 ответа

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

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

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

11
ответ дан 18 December 2019 в 07:56
поделиться

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

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

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

3
ответ дан 18 December 2019 в 07:56
поделиться

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

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

Я поддерживаю вилку Workling, которая добавляет клиента SQS . Есть некоторые недостатки (подробнее см. В комментариях или моем сообщении в блоге ), но в целом это сработало для нас при моем последнем запуске.

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

4
ответ дан 18 December 2019 в 07:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: