Оптимизация задержки (latency)

Прикинул показатели задержки по простенькому сервису.

Дано:
Нагрузка (X) - 70 tps
Время обслуживания (без нагрузки) (S) - 10 ms
Коэффициент вариации по размерам задач (C2) - 50 (характерный разброс для задач под unix)

Вопрос:
Что улучшать?
Уменьшать нагрузку, уменьшать время обслуживания, или снижать вариативность?

График зависимости задержки от каждого из этих параметров (в процентах) на картинке

Казалось бы ответ однозначный. Задержка более всего зависит от S - нужно повышать эффективность системы.

Ан, нет )

Зачастую повышение эффективности стоит очень дорого, и в конечном счете упирается в стороннее ПО.
Например, в какую-нибудь криптопро.

Уменьшить пропускную способность можно масштабированием. Это железо.
Плюс к этому здесь вступают в действие всякие USL и прочие Амдалы, которые могут украсть весь выигрыш.

Свести же вариативность к около нулевым показателям - дело элементарное. Достаточно поставить умный планировщик.

Рекомендую.)

В догонку к предыдущему посту

Читаю очередную книгу по моделям производительности и вижу у автора мысль, типа "от S(размер задачи) latency зависит сильнее всего, значит прежде всего оптимизируем S".

Но, черт побери, это так не работает!

В контексте задачи эту самую S может быть оптимизировать легко , сложно, или даже вообще невозможно.

Я работаю по следующему сценарию:
1. В начале расправляюсь с антипаттернами
Например: Разраб заюзал чужой запрос в стиле n+1 - переписываем на жадность.
2. Когда очевидные косяки устранены, вытягиваю список тактик и смотрю какая из них эффективнее и безвреднее в конкретных условиях.
Например: мне нужна низкая задержка, смотрю на повторное использование результатов, повышение эффективности, масштабирование, умное планирование и т.п.

Эффективность тактики прикидываю на модели.
Безвредность определяю по матрице.

3. Если ничего не помогает изобретаю новое решениение или, чаще всего, уговариваю заказчика о смягчении требований.

Каждый раз приходится думать.

Пропагандируемые в книжках механические алгоритмы не срабатывают.(

Презентация с HL++
С тремя бонусными слайдами )

Еще одна версия на туже тему.
Докладывал сегодня в IT-one.


Добавил карту, для навигации по качествам

Are We Really Engineers?
https://www.hillelwayne.com/post/are-we-really-engineers/

☝☝☝

Гилель Уэйн провел исследование по теме является ли разработка ПО инженерией.
Пришел к ожидаемому выводу - в общем случае нет.
Большинство разработчиков не инженера.

Результат деятельности архитектора

Коротко:
архитектура

Развёрнуто (много букв):
Архитектура никому кроме архитектора не нужна и даже не доступна.
Обоснование:
1. Изначально архитектурой называли структуру некоторых взаимодействующих элементов + принципы развития этой структуры.
2. Чуть позже зафиксировали, что у программного продукта подобных структур множество, в разных плоскостях и под разные потребности (т. н. системный подход)
3. Были сформированы сложные алгоритмы фиксации этих структур через модели и представления, отображающие разные аспекты.
4. Фактически одновременно с этим было замечено, что эти представления бесполезны. Если представление фиксирует ситуацию как есть, то в скором времени оно становится не актуальным. Если фиксирует целевую картинку, то висит гирей на ногах разработки. Особенно если подписано и сдано вместе с ТЗ. Большое предварительное проектирование отливало эти гири в граните.
5. Сторонники гибкого сервисного подхода, предпочитают рассматривать архитектуру с т. з. потребителя. Т.е. архитектура это набор значимых решений.
Многие уточняют, что значимыми являются необратимые или сложно обратимые решения, сильно влияющие на судьбу продукта.
6. Архитектора свели к проектировщику поставляющему решения, и архитектор оказался не нужен.
7. Однако, вскоре выяснилось, что решения могут быть приняты только человеком глубоко погруженным в контекст задачи. "Решатель" должен пропитаться информацией о продукте.
8. То есть на входе набор разнообразных фактов, а на выходе решения. Что между? Между мозг Архитектора нейронные связи которого построили модель продукта из множества информационных осколков. (Ну почти АИ)
9. Аджайл сразу предложил механизм формирования метафор - первичных представлений продукта, которые потом разрастаются в красивую модель. Очень близко первоначальному понимаю архитектурного стиля.
10. Вот эта самая модель и является архитектурой, на базе которой принимаются решения.

Чем сочнее эта структура тем точнее решения.
С другой стороны, чем больше информации впитал мозг архитектора, тем сложнее (невозможнее) отчуждение имеющегося знания.
Можно только чуть приоткрывать завесу отображая знания в различных представлениях.

Таким образом архитектор формирует архитектуру, которая кроме него никому не доступна, да и не нужна.
И на базе этой ненужной модели может принимать оптимальные и обоснованные решения, ценность которых очевидна.

☝️☝️☝️Некоторые следствия

1. Архитектор нужен в системах где
- сложность не позволяет свести структуру к нескольким простым моделям
- требуется значимые решения, то есть от решений зависит судьба продукта
(и соответственно, очень часто архитектор избыточен)
2. Шапочки архитектора и программного инженера - две разные шапочки
- Архитектор, творец который принимает решение на основе слабо формализуемых представлений
- Программный инженер - логик, который из А выводит Б, предсказывая характеристики системы до ее построения.
Это впрочем не исключает процесса перевода одного подхода в другой.
С накоплением опыта интуитивные практики можно формализовать.
3. На системе может быть только один архитектор, либо система должна быть декомпозирована, под разных архитекторов.
Два архитектора над одной системой - две разные ментальные модели, по которым строятся разные решения.
4. Большинство книг/курсов по архитектуре заточены на инженерные практики.
Практика формирования ментальной модели либо вообще аут оф скоуп либо рассмотрена крайне поверхностно.
Это и понятно. То что слабо формализуется, то и плохо передается.
(Хотя в последнем случае, я могу быть не прав. Возможно я просто не попадал на стоящие курсы по этой тематике.)
5. Архитектор, отчётливо проявляющийся в ИТ сфере, должен присутствовать и в других областях связанных со слабо формализуемыми моделями.
И чем дальше от цифр и железок, тем важнее его роль.
Тот же самый "главный конструктор", принимающий не только инженерные решения, тоже архитектор - только еще и отягощенный властью.
6. Для чего я погружаюсь во все эти аспекты мета-архитектуры? Для того чтобы делать значимые выводы )

7. Топология "Архитектура как сервис" подходит под инженеров программистов. Им для работы достаточно чёткой постановки задачи и недолгого погружения в контекст.
Архитектор должен работать по схеме плотного взаимодействия с командой.

Граф противоречий: Производительность

Наигравшись вдоволь с матрицей противоречий (аля ТРИЗ) счёл её не эффективной, для решения задач производительности.
Остановился на графе связывающем основные параметры системы с основными хотелками заказчиков.

Работаю так:
1. Выбираю хотелку (потребность). На графе розовые
2. По стрелкам нахожу связанные параметры и определяю:
а. Что из этих параметров сильнее влияет на нужную характеристику
б. Что из этих параметров проще всего изменить
3. Фиксирую пару хотелка-параметр как противоречие
4. Из списка концептов, соответствующих выбранной паре, выбираю более-менее подходящие (короткий список)
5. Взвешиваю концепты исходя из понимания системы (архитектурное решение) и фиксирую вывод в ADR
6. Если решение не найдено, перехожу на фазу "изобретения", которую начинаю с представления идеального решения задачи.

В общем вполне себе механический процесс, который при желании можно легко воспроизвести.

Если интересны детали, могу рассказать или показать на примере.

Пишите )

Тенденции 2023

Вышел свежий Trends Report от InfoQ

Микросервисы продолжают закатываться.

Банальная математика в помощь архитектору

Предположим нужно оптимизировать время отклика (R).
Чаще всего сразу предполагают, что время отклика эквивалентно времени пребывания (RT, обработка в системе) + транспортные расходы.
Ну или, если пренебречь транспортными расходами, R = RT.

Дальше в плане оптимизации ищем подходящее тактики.
Тут как в аптеке - подход рецепторный.
Чаще всего вспоминают про оптимизацию времени обработки (RT) и кэширование.

А что если пойти от математики и попытаться поиграть параметрами ?

Распишем R:
R = T_end - T_start (тут очевидно)

Что у нас T_start и T_end ?

По определению времени отклика
T_start - время окончания передачи запроса
T_end - время начала получения ответа

Забавный факт - эти времена принадлежат разным "дорожкам"
T_start - клиенту, T_end - системе
и, кроме того, никак не привязаны ко времени обработки.

То есть T_end жестко не привязан к T_start и мы можем двигать его влево

Сколько возможностей открывается:

1. Начинаем обработку ДО события T_start
Тут всевозможные предикативные тактики, предсказывающие действия пользователя, на основании модели пользователя или доменной модели
2. Выполняем всю обработку ДО T_start
Тут тактики раннего связывания, в частности уже упомянутое кэширование
3. Опять же оптимизируем время обработки (а с ним и транспортные расходы)
4. Таймаут ограничивающий время T_end справа, в случае всяких неприятностей.
5. Предсказываем ответ и выдаем его не дожидаясь окончания обработки.
Тактики оптимистичного дизайна и совершенного оптимизма.
6. И наконец, выдаем ответ по кусочку. Если нам важен момент получения первого байта ответа, незачем ждать завершения всей обработки.
(Было бы забавно если бы строители ждали пока завод ЖБИ заготовит все плиты перед поставкой их на стройку)
Тут тактики потоковой обработки

Вот сколько всего.
Больше из этой кошечки мне выжать не удалось (

Но даже этот скромный результат с лихвой покрывает все, что написано в методичках SEI.

Теперь каждый раз, перед поиском подходящих тактик, я прикидываю простейшую, банальную мат. модель для интересующей меня метрики. ИМХО это эффективнее чем вспоминать слабо-структуированные каталоги тактик разных арх. школ.

Чуть более сложная математика в довесок
(Кисонька, ну еще капельку)

В предыдущий пост я включил простейшую математику, в которой длительность (время отклика) рассматривалось как одно число.
Что в статистике называют центральной тенденцией.

Однако в реальности измерение времени отклика дает некоторую случайную величину, которую можно оценить распределением.

На графике представлены возможные распределения при времени обработки 1 сек.

Замечу, что пик двух распределений (т. н. мода) одинаков.

Тактики изложенные выше позволяют сдвигать моду влево.

Хотелось бы еще иметь тактики вытягивающие график вверх (зеленый в синий)

Зеленый график имеет существенно худшие показания SLA и на верхних перцентилях ведет себя недостойно.

Причиной такого размазывания зачастую является декомпозиция задачи.

Если браузеру нужно скачать не один файл а сто, распределение просядет вниз.

Отсюда еще одна - седьмая тактика:
7. Уменьшение количества запросов требуемых на выполнение одной операции.
Если слабо влияет на метрики центральной тенденции (среднее, медиану, моду), то может существенно улучшить статистику (высшие перцентили)

Забавно, но факт.

Архитектора в процессе проектирования выявляют основные цели стейкхолдеров, но зачастую не осознают собственные цели на проекте.

Референсные архитектуры

Референсная архитектура - это архитектура "из коробки"
Берём чьё-то готовое решение и используем у себя как некоторый baseline.

Часто спрашивают где брать.
В основном ищем в интернете. Интересные решения демонстрируются на разных конференциях.

Или, например, в приложенной книге.

Производительность и ТОС

Многие считают, что теория ограничений систем Голдратта (ТОС) хорошо справляется с задачей повышения производительности информационных систем.

ТОС даёт нам план:
1. Разбиваем процесс на этапы.
2. Находим бутылочное горлышко.
3. Определяем ограничение.
4. Устраняем ограничение.
5. Повторяем с первого шага.

Если двигаться по этому плану, то можно добиться существенного увеличения пропускной способности.
Если же оптимизировать случайные участки системы, то скорее всего пропускная способность упадёт.

Однако не всё так однозначно.

Если у нас другой concern, например, если нам необходимо улучшить отзывчивость, то план не работает:
1. Разбиваем процесс на шаги.
2. Находим участок с максимальной потребностью в ресурсе (bottleneck)
3. Определяем ограничение/ресурс (например SSD)
4. Устраняем...

А вот тут затык. Да, оптимизация бутылочного горлышка даст нам максимальный эффект.
Но эта оптимизация может быть крайне трудоёмкой или даже вовсе не возможной.

Оптимизация же соседнего участка, может оказаться не столь эффективной, но очень дешевой.

То есть правило работающее на пропускную способность, не работает на отзывчивость или, например, справедливость.

Теория ограничений имеет ограниченную область применения при проектировании программных систем.)

#ТОС