Performance и scalability: сначала кривая нагрузки

Performance — latency, throughput или resource cost при заданном workload. Scalability — как эти показатели меняются при изменении нагрузки и ресурсов. Один быстрый server может иметь отличную performance и плохой запас роста; cluster может масштабироваться, но иметь высокую coordination cost.

Рабочий процесс

1. Определить correctness и SLO.
2. Зафиксировать endpoint mix, payload, cache state и dependency limits.
3. Построить load curve: offered load → achieved throughput, percentiles, errors, saturation.
4. Найти bottleneck профилированием.
5. Изменить один фактор и повторить тот же тест.
6. Проверить отказ одного capacity unit и cost per successful request.

Вертикальное увеличение часто проще и выгоднее до фактического потолка. Horizontal scale требует partitionable/stateless work, shared state outside app process и балансировки. У него нет свойства «без потолка»: serial sections, locks, shared databases, network and coherence ограничивают gain.

Сценарии

User count не определяет архитектурный stage. Два продукта с одним числом пользователей имеют разные traffic shape, payload и SLO. Решение начинается с измерения.

Если одна instance даёт X, две обычно дают меньше 2X из-за shared dependencies и coordination. Scale efficiency измеряется, а не предполагается.

Учебное допущение: 10% работы serial. Для восьми workers верхняя граница 1 / (0.10 + 0.90 / 8) ≈ 4.71x до дополнительных расходов. При бесконечном числе workers bound равен 10x, а не бесконечности.

Sharding распределяет независимые ownership keys, но добавляет cross-shard constraints, migration, skew и partial failure. Если один primary всё ещё выполняет SLO с запасом, sharding может ухудшить систему.

Модели и границы

Amdahl law показывает bound от serial fraction. Universal Scalability Law добавляет fitted coefficients contention и coherency и может показать retrograde scaling. Обе модели полезны для гипотез, но параметры надо получать из данных; они не заменяют load test.

Не привязывайте курс к «самой большой VM» конкретного облака: ceilings меняются, а реальный limit может быть connection pool, storage latency, license или recovery time.

Связанные темы

[CONCEPT]partitioning-strategies

[CONCEPT]capacity-planning-deep

Первичные источники

• Amdahl 1967: https://doi.org/10.1145/1465482.1465560
• Google SRE introduction: https://sre.google/sre-book/introduction/
• Google SRE service best practices: https://sre.google/sre-book/service-best-practices/
• Gunther, computational scalability: https://arxiv.org/abs/0808.1431