<!-- ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ. Исторический бенчмарк (апрель 2026). Помечено 2026-08-13. -->

# Сравнительный 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 уже находится на хорошем уровне.