Все, что я могу найти о производительности Amazon Simple Queue Service (SQS), включая их собственную документацию, предполагает, что для получения высокой пропускной способности требуется несколько потоков. И я сам проверил это, используя JS API с Node 12. Если я создаю несколько потоков, я получаю примерно одинаковую пропускную способность в каждом потоке, поэтому общее увеличение пропускной способности в значительной степени линейно. Но я запускаю это на хорошей машине с большим количеством ядер. Когда я работаю в Lambda на одном ядре, несколько потоков не улучшают производительность, и, как правило, это то, что я ожидаю от многопоточных приложений.
Но вот что я не понимаю - должно быть здесь очень мало внимания уделяется процессорам, большая часть времени уходит на ожидание веб-запросов. API AWS SQS выглядит асинхронным в том смысле, что все методы используют обратные вызовы для ответов, а я использую Promises для «асинхронизации» всех вызовов API, при этом несколько задач выполняются одновременно. Обычно выполнение этого с любым асинхронным c IO отлично обрабатывается Node и значительно повышает пропускную способность, я делаю это все время с API-интерфейсами баз данных, несколькими потоками и т. Д. c. Но SQS определенно не ведет себя таким образом, он ведет себя так, как будто его IO на самом деле является синхронным и блокирует потоки сетевых вызовов, что было бы возмутительно для любого современного API. пропускная способность в одном потоке Node? Максимум, который я вижу, составляет от 50 до 100 сообщений / с c для очередей FIFO (отправка, получение и удаление, все из которых вызывают методы пакета с максимальным размером пакета 10). И это работает в лямбде, то есть в их собственной сети, что лишь немного быстрее, чем запускать его на моем ноутбуке через Inte rnet, еще одна удивительная находка. В документации Amazon говорится, что очереди FIFO должны поддерживать до 3000 сообщений в секунду при пакетной обработке, что было бы просто замечательно для меня. Действительно ли для этого требуется несколько потоков на нескольких ядрах или виртуальных процессорах? Это было бы смешно, я просто не могу поверить, что будет использоваться много ЦП, это должно быть в основном время ввода-вывода, которое должно быть асинхронным.
Редактировать:
Продолжая тестирование, я обнаружил, что линейное улучшение числа потоков происходит только тогда, когда каждый поток обрабатывает свою очередь. Если все потоки обрабатывают одну и ту же очередь, улучшения не добавляются. Таким образом, он ведет себя так, как будто каждая очередь задушена Amazon. Но пропускная способность, на которую он, похоже, падает, намного ниже того, что я обнаружил задокументированным как максимальная производительность. Действительно растерян и разочарован прямо сейчас!