👆 Ну да.)

Любимый "Слоник" вытягивает вариативность за счет многопоточности. Вероятность того что одновременно придет 16 "аналитических" запросов не должна быть высокой.

MS же честно пилит запросы на кванты обеспечивая идеальную справедливость при приемлемой задержке.

Кстати, в следующую пятницу т.е. 27.10.2023
читаю доклад на ArchDays 2023

Простая «архитектурная» задача и немного ТРИЗ

Заходите, пообщаемся )

https://archdays.ru/?speaker=1346&session=1469

Наблюдаемость
(Observability)

1. Широко известно, что наблюдаемость необходимое качество системы.
2. Ведем журналы, фиксируем показатели, навешиваем метрики.
3. На вопрос какие метрики стоит навешивать легко отвечаю:
Включайте GOLD. Это правильный набор метрик.

4. Однако, так ли уж важна наблюдаемость. Точнее важна ли она сама по себе.
Если я захочу взять стакан воды, то глаза мне, конечно, пригодятся.
Но кроме этого неплохо бы иметь руки, да и сам стакан не помешает.

5. Для успеха любого действия нужны
- как минимум цель(стакан),
- возможность определить движемся ли мы к цели (глаза)
- и возможность скорректировать движение (руки).
То есть нужно сформировать механизм называемый в кибернетике "положительная обратная связь".

6. Наблюдение имеет смысл, если включено в этот механизм. А то получается как в анекдоте:
- Петька, приборы?
- 40
- Что 40?
- А что приборы?

7. То есть наблюдаемость не тянет на самостоятельность.
Я бы сказал, что это только часть качества.
Само качество надо назвать как-то иначе. (корректируемость ?)

8. Ну и в заключении процитирую один разговор:
- Какие метрики мы должны добавить в нашу систему ?
- Нужные метрики. Те, что позволят вам корректировать качества продукта.
- Это слишком умно (
- Включайте GOLD. Это правильный набор метрик. (сарказм)

#Наблюдаемость

Материалы по модели производительности

Вчера на конференции ArchDays2023 пообещал выложить материалы по мат. моделированию.
Вот то, что мне зашло больше всего:

1. Model-Based Software Performance Analysis
by Vittorio Cortellessa, Antinisca Di Marco, Paola Inverardi
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
рассмотрены различные подходы к моделированию производительности

2. Performance Modeling and Design of Computer Systems: Queueing Theory in Action
by Mor Harchol-Balter
https://www.amazon.com/Model-Based-Software-Performance-Analysis-Cortellessa/dp/3642136206
ИМХО одна из лучших книг по QNM модели

3. Вообще все, что читал у Harchol-Balter мне нравится.
Рекомендую её сайт, где много материалов для свободного скачивания.
В том числе презентации, "разжевывающие" предыдущую книгу.
https://www.cs.cmu.edu/~harchol/

4. Baron Schwartz практик, использующий модели в проектировании
Его книги есть в свободном доступе
Выкладывал на канале -
- The Essential Guide to Queueing Theory
https://news.1rj.ru/str/rect_arrow/159
Книга по теории массового обслуживания
- Practical Scalability Analysis With The Universal Scalability Law
https://news.1rj.ru/str/rect_arrow/167
по USL (масштабирование)

#Книга #производительность

Зачем нужен архитектор

Возвращаясь к вопросу.
Хотел накидать список полезностей архитектора, но решил проверить в интернете и нашел готовый )

На картинке карта компетенций по solution architecture.

Отвечает на вопросы: что нужно уметь и как себя продавать.

Архитектура как клиническая практика

Работа архитектора в чем-то схожа с работой врача.
Можно найти те же паттерны.
Например:
Пациент жалуется на головную боль
(Заказчику не достает производительности)
1. Подход "технология вперед"
Выпей аспирину - в прошлый раз помогло.
А еще лучше фуфломецин - его везде рекламируют
2. Подход "очевидное решение"
Головная боль - очевидно простуда. Выпей аспирин.
3. Архитектурный подход.
А какие симптомы кроме этого? Кашель, насморк?
Нога болела два дня назад?
Гугл подсказывает, что при таких симптомах нужен аспирин.
4. Инженерный подход.
Симптомы наводят на мысль, но точного диагноза поставить нельзя. Нужно сдать анализы.
Все хором - анализы это же дорого и долго - выпей аспирин.

В общем - очень похоже.
Разница только в том, что архитектор зачастую работает с еще не родившимся "пациентом".

#Сарказм

Отличная высокопроизводительная система

На одной встрече резануло слух следующее высказывание:
Задача архитектора построить высокопроизводительную систему.
Хмм.

В моём понимании задача это:
1. Цель
2. Данность (условия)
3. Метод решения

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

И отсюда сразу много выводов:
1. Первая активность это не натягивание редиски на слона, а выявление и объективизация заинтересованностей стейкхолдеров.
2. Далее надо сопоставить выявленные хотелки с возможностями и желаниями заказчика.
3. И наконец, сопоставить оставшиеся требования с нашими возможностями и желаниями.

Моё желание построить отличную высокопроизводительную систему (и получить с этого определенный драйв/опыт) - обычно никого не интересует.
Я могу сделать это за счёт заказчика, но это как-то не профессионально.

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

Резюмируя:
Цель архитектора (в контексте производительности) построить систему удовлетворяющую заказчика и прочих стейкхолдеров оптимальную с т. з. производительности.

Не сочтите за занудство )

Оптимизация задержки (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. Вот эта самая модель и является архитектурой, на базе которой принимаются решения.

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

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