Tuning Azure Service Bus (RU)
- 1. Tuning Azure Service Bus
- 2. Сервисы служебной шины Для обмена сообщениями – Queues – Topics – Event Hubs – Relays Не совсем, но очень близко – Notification Hubs
- 3. Почему их несколько? Реализуют разные паттерны обмена сообщениями Queues: Запрос-Ответ, Цепочки событий, Транзакции Topics: Бродкастинг, Фильтрация содержимого, Отладочные подписки Event Hubs:Стриминг Relays: Доступ к legacy данным, Реакция в реальном времени, Разделение подключений и системы Имеют разные форматы сообщений Биллинг отличается
- 4. Почему всё это служебная шина? Все эти сервисы ● Хранятся одинаково ● Имеют REST API ● Реализуют AMQP
- 5. По умолчанию Окружение и утилиты ● VS 2013 / Azure SDK 2.7.1 ● Console app for local ● Worker roles for Azure CloudService ● Service Bus Explorer Сообщения Small message: default BrokeredMessage (empty body) Big message: 64 KB body Настройки MaxRetries = 4 RetryInterval = 2s SendAsync/ReceiveAsync Все настройки выключены
- 6. Тайминги Azure обещает latency около 20-25 ms для того же датацентра. Соответственно раундтрип должен быть около 50 ms. Попробуем отправить сообщение в очередь и раздел; получить его и сравнить таймстамп. Среднее за 1000 сообщений. West Europe North Europe US West 1 Local Machine 0 50 100 150 200 250 300 BigQueue BigTopic SmallQueue SmallTopic
- 7. Пропускная способность Azure обещает производительность одной шины до 2000 транзакций в секунду (для 1KB сообщений). Попробуем отправить 100000 сообщений в шину и потом получить их (5 соединений по 10 потоков и после столько же на прием). Сообщений в секунду Send Queue Send Topic Receive Queue Receive Topic 0 200 400 600 800 1000 1200 1400 1600 1800 Small PeekLock Big PeekLock Small ReceiveDelete Big ReceiveDelete
- 8. Следим за... размером Сообщения <= 256 KB (Заголовка <= 64 KB) Очереди или раздела <= 5 GB (x16 when using Partitioning) а иначе будет неприятно и количеством подключений, TCP подключений <= 100 HTTP подключений можно создавать сколько угодно
- 9. Крутим настройки Попробуем что-нибудь сделать, для того, чтобы поднять пропускную способность и уменьшить тайминги. Но также хотелось бы упомянуть несколько вещей, о которых часто забывают, потому что они выключены по умолчанию: ● DeadLettering ● ResponseTo ● Forwarding
- 10. Partitioning ● Можно включить и забыть. (Azure справится самостоятельно) ● Указав ViaPartitionKey, можно сказать, какое сообщение куда положить. ● Так можно увеличить размер шины в 16 раз. ● Транзакции должны лежать в одной секции. Попробуем SendQueue SendTopic ReceiveQueue ReceiveTopic 0 500 1000 1500 2000 2500 Small RD Small RD Part Big RD Big RD Part
- 11. Batched Operations ● Не работает через HTTP ● Пакетная обработка включена по умолчанию (20 ms на каждой стороне) ● Влияет только на асинхронные операции типа Send и Complete Попробуем включить пакетную обработку для уже секционированной шины. SendQueue SendTopic ReceiveQueue ReceiveTopic 0 500 1000 1500 2000 2500 3000 Small PL Small PL Batched Big PL Big PL Batched
- 12. Prefetching ● Тоже не работает по HTTP. ● При использовании стратегии PeekLock нельзя превышать LockDuration. ● Регулируется по количеству сообщений, но имеет ограничение по объему 256KB. ● TTL проверяется ДО кэширования. Попробуем (взяв за исходные настройки предыдущий ReceiveQueue ReceiveTopic 0 500 1000 1500 2000 2500 Small PL Small PL Prefetch Big PL Big PL Prefetch
- 13. Express ● Включается сразу для раздела или очереди. ● SLA служебной шины всего 99.9% ● Можно установить сообщению флаг ForcedPersistency для записи в хранилище. Попробуем включить экспресс-обработку SendQueue SendTopic ReceiveQueue ReceiveTopic 0 1000 2000 3000 4000 5000 6000 Small PL Small PL Express Big PL Big PL Express
- 14. Всё сразу Для повышения производительности ● Включите Partitioning (в режиме round-robin, если не нужны секции). ● Включите Express. ● Включите Batching и Prefetching. ● Используйте асинхронные операции. ● Не плодите соединения без надобности. Для снижения задержки ● Подумайте о переходе на EventHub :) ● Выключайте Batching (как клиентский, так и серверный). ● Используйте Prefetching только если процесов чтения мало.
- 15. Наконец-то последний слайд Бесполезные ссылки ● https://azure.microsoft.com/en-us/documentation/ – videos/azure-service-bus-101-with-dan-rosanova/ – articles/service-bus-performance-improvements/ ● https://blog.sixeyed.com/ ● https://weblogs.asp.net/scottgu Ненужные контакты Skype: csi.pavelsokolov Email: tmpall@gmail.com Linkedin: https://www.linkedin.com/in/pavel-sokolov-82ba2387
Editor's Notes
- #2: Вступление (0.5) Кто использует О чем вообще речь
- #3: Введение Какие есть сервисы (1.5) Очереди Разделы и подписки Концентраторы событий Ретрансляторы Концентраторы уведомлений
- #4: Почему сервисов несколько? Паттерны второго рода: Queue (1) Запрос-Ответ Цепочки событий Транзакции Topic (1) Бродкаст Фильтр по содержимому Отладочная подписка
- #5: Почему все эти сервисы - служебная шина? ISO — AMQP (Advanced Messaging Queue Protocol) (0.5)
- #6: По умолчанию (1) PeekLock vs ReadAndDelete
- #7: Тайминги (2) Всё рядом Связанные датацентры Удаленные датацентры
- #8: Пропускная способность (2) Запись сообщений Чтение из очереди из подписки Упомянуть о 1000 одновременных транзакций для очереди и 1000 + 1000 для раздела + подписки
- #9: Следите за размером (2) И количеством сообщений Что произойдет при перегрузке Или большом количестве конекшенов 10 сек таймаут
- #10: Крутим настройки Дедлеттеринг (0.5) Ответы в очередь (0.5) Форвардинг
- #11: Партишенинг ВиаПартишенКи (0.5) Больший размер очереди (0.5) Аккуратнее с сессиями (0.5)
- #12: Батчед Оперейшенс (2) BatchFlushInterval — клиент EnableBatchedOperations - сервер
- #13: Предварительная выборка О размерах кэша (0.5) Не кэшируйте больше, чем нужно 20 x MaxRate(0.5)
- #14: Экспресс (1.5) Форсед Персистенси
- #15: Финальное сравнение (1)
- #16: Заключение (1) Блог Элтона Стоунмана И Скотта Гатри Контакты Вопросы