docs: add 32kb benchmark comparison

2026-04-12 08:44:11 +03:00
parent 70cfc0d83d
commit d5d3519836
5 changed files with 621 additions and 3 deletions
@@ -0,0 +1,104 @@
+# Сравнительный benchmark shared-sqs vs Yandex MQ до 32KB
+
+**Дата:** 2026-04-12 05:45 UTC
+
+## Область сравнения
+
+Этот отчёт специально ограничен сообщениями до 32KB.
+
+- Сценарии `64KB+` исключены из сравнения по решению пользователя.
+- Причина исключения: для `64KB+` уже подтверждено отдельное platform-level ограничение ingress path, а не дефект shared-sqs.
+- Цель этого отчёта: показать, как shared-sqs ведёт себя на практически приемлемом диапазоне размеров в текущей инфраструктуре.
+
+## Методика
+
+- Запуск выполнялся с удалённой ВМ `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. В диапазоне до `32KB` 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. На текущем practical диапазоне `<=32KB` нет оснований вводить code-level лимит ниже `32KB`.
+
+## Важное примечание по качеству измерений
+
+- В первом длинном прогоне [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).
+
+## Что сознательно не включено
+
+- `64KB+` payload.
+- Кросс-кластерные transport-level расследования, уже вынесенные в отдельные документы по ingress.
+- Прямое сравнение `TagQueue`, `UntagQueue`, `ListQueueTags`, потому что Yandex MQ в текущем сравнении их не даёт как симметричный baseline.
+
+## Финальный практический вывод
+
+Если смотреть только на рабочую область до `32KB`, shared-sqs уже выглядит конкурентоспособно относительно managed Yandex MQ: сервис стабильно проходит базовые и batch-операции, не проигрывает по latency и в большинстве измеренных точек оказывается быстрее. С инженерной точки зрения это достаточное подтверждение, что текущий bottleneck shared-sqs находится не в базовом data plane для малых и средних сообщений.