docs: add 32kb benchmark comparison
This commit is contained in:
Naeel
@@ -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 для малых и средних сообщений.
|
||||
+4
-2
@@ -15,10 +15,12 @@
|
||||
| Размер | shared-sqs | Yandex MQ | Сравнение |
|
||||
|--------|-----------|-----------|-----------|
|
||||
| 1KB | ~800ms | ~700ms | Паритет |
|
||||
| 10KB | ~800ms | ~700ms | Паритет |
|
||||
| 32KB | **805-917ms** | 869-3490ms | **Быстрее** (нет cold start) |
|
||||
| 10KB | **880-965ms** | 916-996ms | **Быстрее** |
|
||||
| 32KB | **883-939ms** | 905-948ms | **Быстрее** |
|
||||
| 64KB+ | ❌ 10-52s зависание | ~900ms | Проблема nginx+botocore |
|
||||
|
||||
- Детальный сравнительный отчёт по API операциям до 32KB: [doc/api/benchmark-comparison-2026-04-12.md](/home/naeel/remote_dev/SQS-service/doc/api/benchmark-comparison-2026-04-12.md)
|
||||
|
||||
### Проблема 65KB+ payload (расследование 2026-04-11)
|
||||
|
||||
**Root cause:** botocore (AWS SDK) + urllib3 2.0 + TLS record boundary.
|
||||
|
||||
@@ -285,4 +285,32 @@
|
||||
3. Что реально сгенерировано в `/etc/nginx/nginx.conf` у ingress controller.
|
||||
4. Не изменились ли версия штурвала и версия ingress-nginx controller.
|
||||
5. Не включили ли на platform уровне `allow-snippet-annotations`.
|
||||
6. Не появился ли доступ к source-of-truth конфигурации платформенного ingress controller.
|
||||
6. Не появился ли доступ к source-of-truth конфигурации платформенного ingress controller.
|
||||
|
||||
---
|
||||
|
||||
## Задача: собрать отдельный сравнительный benchmark-отчёт только до 32KB
|
||||
|
||||
### Контекст
|
||||
После завершения расследования по 64KB+ пользователь явно зафиксировал новую рамку: в сравнительном отчёте не трогать `64KB` и выше, а ограничиться practically useful диапазоном до `32KB`.
|
||||
|
||||
### Что сделал
|
||||
1. Выделил отдельный benchmark-сценарий `tests/benchmark_compare_32k.sh`, чтобы не смешивать его с прежними широкими сценариями.
|
||||
2. Запустил прогон по общим операциям API и получил полноценную таблицу latency для control-plane и data-plane вызовов.
|
||||
3. Нашёл, что секция `PurgeQueue` искусственно раздувает время всего прогона, потому что повторный purge требует cooldown `60s` по самому контракту API. Убрал многократные sleep и оставил одиночный контрольный замер.
|
||||
4. Нашёл ещё один дефект уже в самом benchmark harness: в общем длинном прогоне для `SendMessage 10KB` и `SendMessage 32KB` у shared-sqs появились артефактные нули, хотя отдельная точечная проверка `5/5` показала, что обе операции реально проходят стабильно.
|
||||
5. Чтобы не оставлять сомнительные данные, вынес для этих размеров отдельный узкий probe `tests/payload_latency_probe.sh` и снял повторные latency-цифры отдельно.
|
||||
6. На основе общего прогона и узкого probe собрал отдельный документ `doc/api/benchmark-comparison-2026-04-12.md`.
|
||||
|
||||
### Что подтвердилось
|
||||
- До `32KB` shared-sqs не проиграл Yandex MQ ни по одной из общих измеренных операций.
|
||||
- На `SendMessage 10KB` и `SendMessage 32KB` shared-sqs в повторном узком прогоне получился немного быстрее Yandex MQ.
|
||||
- На control-plane вызовах `GetQueueUrl`, `ListQueues`, `GetQueueAttributes`, `SetQueueAttributes` shared-sqs выглядит стабильно сильнее в текущей конфигурации.
|
||||
- Throughput в тесте через AWS CLI фактически ограничивается самим клиентом, поэтому там паритет по грубому `msg/s` и небольшой выигрыш shared-sqs по общему времени.
|
||||
|
||||
### Почему это важно
|
||||
Этот отчёт теперь отделяет две разные темы, которые раньше легко спутать:
|
||||
- вопрос прикладной конкурентоспособности shared-sqs в practically useful диапазоне до `32KB`;
|
||||
- отдельную transport/platform проблему `64KB+`, уже локализованную на ingress path.
|
||||
|
||||
Именно такое разделение и нужно, чтобы дальше не смешивать хорошие рабочие метрики сервиса с чужим инфраструктурным ограничением.
|
||||
Reference in New Issue
Block a user