БД и алгоритмы планирования

К слову, вот такая интересная табличка по БД

👆 Ну да.)

Любимый "Слоник" вытягивает вариативность за счет многопоточности. Вероятность того что одновременно придет 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/

☝☝☝

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