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
@@ -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.
+
+Именно такое разделение и нужно, чтобы дальше не смешивать хорошие рабочие метрики сервиса с чужим инфраструктурным ограничением.