99 lines
6.7 KiB
Markdown
99 lines
6.7 KiB
Markdown
# Сравнительный benchmark shared-sqs vs Yandex MQ
|
||
|
||
**Дата:** 2026-04-12 05:45 UTC
|
||
|
||
## Область сравнения
|
||
|
||
Этот отчёт фиксирует результаты сравнительных тестов по основным пользовательским сценариям shared-sqs и Yandex MQ.
|
||
|
||
## Методика
|
||
|
||
- Запуск выполнялся с удалённой ВМ `5.172.178.213` в каталоге `~/terra/SQS-service`.
|
||
- Для сравнения использовался один и тот же AWS CLI клиент.
|
||
- Базовый прогон: [tests/benchmark_compare_32k.sh](/home/naeel/remote_dev/SQS-service/tests/benchmark_compare_32k.sh).
|
||
- Уточняющий прогон для `SendMessage 10KB` и `SendMessage 32KB`: [tests/payload_latency_probe.sh](/home/naeel/remote_dev/SQS-service/tests/payload_latency_probe.sh).
|
||
- Для большинства операций использовано `7` итераций.
|
||
- Для throughput использовалось `5` воркеров по `10` сообщений `1KB`.
|
||
- Для `PurgeQueue` зафиксирован одиночный контрольный замер, потому что повторный вызов упирается в стандартный cooldown `60s`.
|
||
|
||
## Покрытие API
|
||
|
||
Сравнение включало операции, которые есть у обоих сервисов:
|
||
|
||
- `GetQueueUrl`
|
||
- `ListQueues`
|
||
- `GetQueueAttributes`
|
||
- `SetQueueAttributes`
|
||
- `SendMessage`
|
||
- `SendMessageBatch`
|
||
- `ReceiveMessage`
|
||
- `DeleteMessage`
|
||
- `DeleteMessageBatch`
|
||
- `ChangeMessageVisibility`
|
||
- `ChangeMessageVisibilityBatch`
|
||
- `PurgeQueue`
|
||
|
||
Операции, которые есть в shared-sqs, но не участвуют в прямом сравнении с Yandex MQ:
|
||
|
||
- `TagQueue`
|
||
- `UntagQueue`
|
||
- `ListQueueTags`
|
||
|
||
## Итоги по latency
|
||
|
||
Формат значений: `min / avg / max / p95`, миллисекунды.
|
||
|
||
| Операция | Yandex MQ | shared-sqs | Вывод |
|
||
|---|---:|---:|---|
|
||
| GetQueueUrl | 766 / 1346 / 2266 / 2060 | 739 / 752 / 770 / 760 | shared-sqs заметно стабильнее |
|
||
| ListQueues | 765 / 786 / 817 / 811 | 740 / 756 / 775 / 762 | shared-sqs быстрее |
|
||
| GetQueueAttributes | 804 / 820 / 847 / 828 | 738 / 752 / 768 / 765 | shared-sqs быстрее |
|
||
| SetQueueAttributes | 805 / 816 / 835 / 835 | 750 / 765 / 803 / 774 | shared-sqs быстрее |
|
||
| SendMessage 1KB | 804 / 811 / 824 / 823 | 748 / 760 / 770 / 767 | shared-sqs быстрее |
|
||
| SendMessage 10KB | 916 / 967 / 996 / 987 | 880 / 913 / 965 / 951 | shared-sqs быстрее |
|
||
| SendMessage 32KB | 905 / 930 / 948 / 947 | 883 / 904 / 939 / 928 | shared-sqs быстрее |
|
||
| SendMessageBatch 10 | 784 / 803 / 827 / 820 | 718 / 746 / 782 / 759 | shared-sqs быстрее |
|
||
| ReceiveMessage | 782 / 826 / 869 / 864 | 738 / 748 / 777 / 751 | shared-sqs быстрее |
|
||
| DeleteMessage | 783 / 800 / 823 / 814 | 727 / 742 / 757 / 755 | shared-sqs быстрее |
|
||
| DeleteMessageBatch 10 | 818 / 845 / 872 / 864 | 742 / 783 / 821 / 810 | shared-sqs быстрее |
|
||
| ChangeMessageVisibility | 810 / 842 / 894 / 854 | 778 / 805 / 814 / 814 | shared-sqs быстрее |
|
||
| ChangeMessageVisibilityBatch 10 | 806 / 829 / 848 / 841 | 803 / 824 / 838 / 836 | почти паритет, но shared-sqs чуть быстрее |
|
||
| PurgeQueue | 867 | 801 | shared-sqs быстрее, но это одиночный контрольный замер |
|
||
|
||
## Throughput
|
||
|
||
Тест: `SendMessage 1KB`, `5` воркеров по `10` сообщений.
|
||
|
||
| Провайдер | Успешно | Общее время | Пропускная способность |
|
||
|---|---:|---:|---:|
|
||
| Yandex MQ | 50 / 50 | 9116 ms | ~5 msg/s |
|
||
| shared-sqs | 50 / 50 | 8580 ms | ~5 msg/s |
|
||
|
||
Вывод по throughput:
|
||
|
||
- В этом сценарии наблюдается паритет по грубому `msg/s`.
|
||
- shared-sqs завершает тот же объём немного быстрее по wall-clock time.
|
||
- Ограничение здесь задаётся в первую очередь AWS CLI, а не серверной частью обоих сервисов.
|
||
|
||
## Основные выводы
|
||
|
||
1. shared-sqs не уступает Yandex MQ ни по одной из измеренных общих операций.
|
||
2. На `SendMessage` с payload `10KB` и `32KB` shared-sqs в текущем прогоне стабильно быстрее Yandex MQ.
|
||
3. На control-plane вызовах `GetQueueUrl`, `ListQueues`, `GetQueueAttributes`, `SetQueueAttributes` shared-sqs показывает более низкий средний latency.
|
||
4. На batch-операциях shared-sqs также быстрее, но разница уже не драматическая.
|
||
5. По результатам прогона shared-sqs выглядит конкурентоспособно в реальных пользовательских сценариях.
|
||
|
||
## Важное примечание по качеству измерений
|
||
|
||
- В первом длинном прогоне [tests/benchmark_compare_32k.sh](/home/naeel/remote_dev/SQS-service/tests/benchmark_compare_32k.sh) для `SendMessage 10KB` и `SendMessage 32KB` у shared-sqs были получены артефактные нули.
|
||
- Повторная точечная проверка показала, что это был дефект benchmark harness, а не отказ сервиса.
|
||
- Для этих двух строк в таблице используются результаты повторного узкого прогона из [tests/payload_latency_probe.sh](/home/naeel/remote_dev/SQS-service/tests/payload_latency_probe.sh).
|
||
|
||
## Что сознательно не включено
|
||
|
||
- Кросс-кластерные transport-level расследования, уже вынесенные в отдельные технические документы.
|
||
- Прямое сравнение `TagQueue`, `UntagQueue`, `ListQueueTags`, потому что Yandex MQ в текущем сравнении их не даёт как симметричный baseline.
|
||
|
||
## Финальный практический вывод
|
||
|
||
shared-sqs выглядит конкурентоспособно относительно managed Yandex MQ: сервис стабильно проходит базовые и batch-операции, не проигрывает по latency и в большинстве измеренных точек оказывается быстрее. С инженерной точки зрения это достаточное подтверждение, что текущая реализация data plane уже находится на хорошем уровне. |