Отличная высокопроизводительная система
На одной встрече резануло слух следующее высказывание:
Задача архитектора построить высокопроизводительную систему.
Хмм.
В моём понимании задача это:
1. Цель
2. Данность (условия)
3. Метод решения
Цель
- Казалось бы просто:
- Цель - построение высокопроизводительной системы.
- Однако это не цель архитектора.
Архитектору производительность не нужна.
- Точнее:
- Цель - удовлетворение хотелок заказчика в контексте производительности.
- Увы, зачастую заказчику производительность тоже не нужна, его чаще интересуют деньги.
- Еще точнее:
- Цель - удовлетворение хотелок стейкхолдеров в контексте производительности.
- Предполагая связь: удовлетворенный стейкхолдер - счастливый заказчик (что в общем то не всегда так)
И отсюда сразу много выводов:
1. Первая активность это не натягивание редиски на слона, а выявление и объективизация заинтересованностей стейкхолдеров.
2. Далее надо сопоставить выявленные хотелки с возможностями и желаниями заказчика.
3. И наконец, сопоставить оставшиеся требования с нашими возможностями и желаниями.
Моё желание построить отличную высокопроизводительную систему (и получить с этого определенный драйв/опыт) - обычно никого не интересует.
Я могу сделать это за счёт заказчика, но это как-то не профессионально.
Вместо отличной системы я должен построить систему удовлетворительную - удовлетворяющую в разной степени стейкхолдеров проекта.
Резюмируя:
Цель архитектора (в контексте производительности) построить систему удовлетворяющую заказчика и прочих стейкхолдеров оптимальную с т. з. производительности.
Не сочтите за занудство )
На одной встрече резануло слух следующее высказывание:
Задача архитектора построить высокопроизводительную систему.
Хмм.
В моём понимании задача это:
1. Цель
2. Данность (условия)
3. Метод решения
Цель
- Казалось бы просто:
- Цель - построение высокопроизводительной системы.
- Однако это не цель архитектора.
Архитектору производительность не нужна.
- Точнее:
- Цель - удовлетворение хотелок заказчика в контексте производительности.
- Увы, зачастую заказчику производительность тоже не нужна, его чаще интересуют деньги.
- Еще точнее:
- Цель - удовлетворение хотелок стейкхолдеров в контексте производительности.
- Предполагая связь: удовлетворенный стейкхолдер - счастливый заказчик (что в общем то не всегда так)
И отсюда сразу много выводов:
1. Первая активность это не натягивание редиски на слона, а выявление и объективизация заинтересованностей стейкхолдеров.
2. Далее надо сопоставить выявленные хотелки с возможностями и желаниями заказчика.
3. И наконец, сопоставить оставшиеся требования с нашими возможностями и желаниями.
Моё желание построить отличную высокопроизводительную систему (и получить с этого определенный драйв/опыт) - обычно никого не интересует.
Я могу сделать это за счёт заказчика, но это как-то не профессионально.
Вместо отличной системы я должен построить систему удовлетворительную - удовлетворяющую в разной степени стейкхолдеров проекта.
Резюмируя:
Цель архитектора (в контексте производительности) построить систему удовлетворяющую заказчика и прочих стейкхолдеров оптимальную с т. з. производительности.
Не сочтите за занудство )
👍5
В связи с вышесказанным
хотелось бы узнать ваше мнение:
Архитектор это тот, кто
хотелось бы узнать ваше мнение:
Архитектор это тот, кто
Anonymous Poll
10%
строит качественную систему преодолевая условия, и ограничения,
58%
строит ситему удовлетворяющую стейкхолдеров с учётом условий и ограничений,
19%
может работать на качество или на удовлетворегие заказча - зависит от проекта.
13%
Не скажу, но ответ посмотрю
image_2023-11-19_15-19-03.png
14 KB
Оптимизация задержки (latency)
Прикинул показатели задержки по простенькому сервису.
Дано:
Нагрузка (X) - 70 tps
Время обслуживания (без нагрузки) (S) - 10 ms
Коэффициент вариации по размерам задач (C2) - 50 (характерный разброс для задач под unix)
Вопрос:
Что улучшать?
Уменьшать нагрузку, уменьшать время обслуживания, или снижать вариативность?
График зависимости задержки от каждого из этих параметров (в процентах) на картинке
Казалось бы ответ однозначный. Задержка более всего зависит от S - нужно повышать эффективность системы.
Ан, нет )
Зачастую повышение эффективности стоит очень дорого, и в конечном счете упирается в стороннее ПО.
Например, в какую-нибудь криптопро.
Уменьшить пропускную способность можно масштабированием. Это железо.
Плюс к этому здесь вступают в действие всякие USL и прочие Амдалы, которые могут украсть весь выигрыш.
Свести же вариативность к около нулевым показателям - дело элементарное. Достаточно поставить умный планировщик.
Рекомендую.)
Прикинул показатели задержки по простенькому сервису.
Дано:
Нагрузка (X) - 70 tps
Время обслуживания (без нагрузки) (S) - 10 ms
Коэффициент вариации по размерам задач (C2) - 50 (характерный разброс для задач под unix)
Вопрос:
Что улучшать?
Уменьшать нагрузку, уменьшать время обслуживания, или снижать вариативность?
График зависимости задержки от каждого из этих параметров (в процентах) на картинке
Казалось бы ответ однозначный. Задержка более всего зависит от S - нужно повышать эффективность системы.
Ан, нет )
Зачастую повышение эффективности стоит очень дорого, и в конечном счете упирается в стороннее ПО.
Например, в какую-нибудь криптопро.
Уменьшить пропускную способность можно масштабированием. Это железо.
Плюс к этому здесь вступают в действие всякие USL и прочие Амдалы, которые могут украсть весь выигрыш.
Свести же вариативность к около нулевым показателям - дело элементарное. Достаточно поставить умный планировщик.
Рекомендую.)
👍2
В догонку к предыдущему посту
Читаю очередную книгу по моделям производительности и вижу у автора мысль, типа "от S(размер задачи) latency зависит сильнее всего, значит прежде всего оптимизируем S".
Но, черт побери, это так не работает!
В контексте задачи эту самую S может быть оптимизировать легко , сложно, или даже вообще невозможно.
Я работаю по следующему сценарию:
1. В начале расправляюсь с антипаттернами
Например: Разраб заюзал чужой запрос в стиле n+1 - переписываем на жадность.
2. Когда очевидные косяки устранены, вытягиваю список тактик и смотрю какая из них эффективнее и безвреднее в конкретных условиях.
Например: мне нужна низкая задержка, смотрю на повторное использование результатов, повышение эффективности, масштабирование, умное планирование и т.п.
Эффективность тактики прикидываю на модели.
Безвредность определяю по матрице.
3. Если ничего не помогает изобретаю новое решениение или, чаще всего, уговариваю заказчика о смягчении требований.
Каждый раз приходится думать.
Пропагандируемые в книжках механические алгоритмы не срабатывают.(
Читаю очередную книгу по моделям производительности и вижу у автора мысль, типа "от S(размер задачи) latency зависит сильнее всего, значит прежде всего оптимизируем S".
Но, черт побери, это так не работает!
В контексте задачи эту самую S может быть оптимизировать легко , сложно, или даже вообще невозможно.
Я работаю по следующему сценарию:
1. В начале расправляюсь с антипаттернами
Например: Разраб заюзал чужой запрос в стиле n+1 - переписываем на жадность.
2. Когда очевидные косяки устранены, вытягиваю список тактик и смотрю какая из них эффективнее и безвреднее в конкретных условиях.
Например: мне нужна низкая задержка, смотрю на повторное использование результатов, повышение эффективности, масштабирование, умное планирование и т.п.
Эффективность тактики прикидываю на модели.
Безвредность определяю по матрице.
3. Если ничего не помогает изобретаю новое решениение или, чаще всего, уговариваю заказчика о смягчении требований.
Каждый раз приходится думать.
Пропагандируемые в книжках механические алгоритмы не срабатывают.(
🔥6
Проектирование_высоконагруженного_решения_на_примере_СМЭВ_4_v2.pdf
2.3 MB
Еще одна версия на туже тему.
Докладывал сегодня в IT-one.
Добавил карту, для навигации по качествам
Докладывал сегодня в IT-one.
Добавил карту, для навигации по качествам
🔥9
Are We Really Engineers?
https://www.hillelwayne.com/post/are-we-really-engineers/
https://www.hillelwayne.com/post/are-we-really-engineers/
Hillel Wayne
Are We Really Engineers?
This is part one of the Crossover Project. Part two is here and part three is here. A conference talk based on this work is now available here.
I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking…
I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking…
👍2
☝☝☝
Гилель Уэйн провел исследование по теме является ли разработка ПО инженерией.
Пришел к ожидаемому выводу - в общем случае нет.
Большинство разработчиков не инженера.
Гилель Уэйн провел исследование по теме является ли разработка ПО инженерией.
Пришел к ожидаемому выводу - в общем случае нет.
Большинство разработчиков не инженера.
🤔2😢1
Коллеги, а каково ваше мнение по прогрманной инженерии ?
Anonymous Poll
11%
Мы все программные инженера
54%
Часть айтишников инженера, часть просто техники, зависит от квалификации
6%
IT - особая сфера. Здесь инженерия неприемлема. Только чистое творчество (дизайн)
20%
Наша отрасль еще не дозрела до инженерии
13%
Не знаю/не скажу/отвечу в коментарии
Результат деятельности архитектора
Коротко:
архитектура
Развёрнуто (много букв):
Архитектура никому кроме архитектора не нужна и даже не доступна.
Обоснование:
1. Изначально архитектурой называли структуру некоторых взаимодействующих элементов + принципы развития этой структуры.
2. Чуть позже зафиксировали, что у программного продукта подобных структур множество, в разных плоскостях и под разные потребности (т. н. системный подход)
3. Были сформированы сложные алгоритмы фиксации этих структур через модели и представления, отображающие разные аспекты.
4. Фактически одновременно с этим было замечено, что эти представления бесполезны. Если представление фиксирует ситуацию как есть, то в скором времени оно становится не актуальным. Если фиксирует целевую картинку, то висит гирей на ногах разработки. Особенно если подписано и сдано вместе с ТЗ. Большое предварительное проектирование отливало эти гири в граните.
5. Сторонники гибкого сервисного подхода, предпочитают рассматривать архитектуру с т. з. потребителя. Т.е. архитектура это набор значимых решений.
Многие уточняют, что значимыми являются необратимые или сложно обратимые решения, сильно влияющие на судьбу продукта.
6. Архитектора свели к проектировщику поставляющему решения, и архитектор оказался не нужен.
7. Однако, вскоре выяснилось, что решения могут быть приняты только человеком глубоко погруженным в контекст задачи. "Решатель" должен пропитаться информацией о продукте.
8. То есть на входе набор разнообразных фактов, а на выходе решения. Что между? Между мозг Архитектора нейронные связи которого построили модель продукта из множества информационных осколков. (Ну почти АИ)
9. Аджайл сразу предложил механизм формирования метафор - первичных представлений продукта, которые потом разрастаются в красивую модель. Очень близко первоначальному понимаю архитектурного стиля.
10. Вот эта самая модель и является архитектурой, на базе которой принимаются решения.
Чем сочнее эта структура тем точнее решения.
С другой стороны, чем больше информации впитал мозг архитектора, тем сложнее (невозможнее) отчуждение имеющегося знания.
Можно только чуть приоткрывать завесу отображая знания в различных представлениях.
Таким образом архитектор формирует архитектуру, которая кроме него никому не доступна, да и не нужна.
И на базе этой ненужной модели может принимать оптимальные и обоснованные решения, ценность которых очевидна.
Коротко:
архитектура
Развёрнуто (много букв):
Архитектура никому кроме архитектора не нужна и даже не доступна.
Обоснование:
1. Изначально архитектурой называли структуру некоторых взаимодействующих элементов + принципы развития этой структуры.
2. Чуть позже зафиксировали, что у программного продукта подобных структур множество, в разных плоскостях и под разные потребности (т. н. системный подход)
3. Были сформированы сложные алгоритмы фиксации этих структур через модели и представления, отображающие разные аспекты.
4. Фактически одновременно с этим было замечено, что эти представления бесполезны. Если представление фиксирует ситуацию как есть, то в скором времени оно становится не актуальным. Если фиксирует целевую картинку, то висит гирей на ногах разработки. Особенно если подписано и сдано вместе с ТЗ. Большое предварительное проектирование отливало эти гири в граните.
5. Сторонники гибкого сервисного подхода, предпочитают рассматривать архитектуру с т. з. потребителя. Т.е. архитектура это набор значимых решений.
Многие уточняют, что значимыми являются необратимые или сложно обратимые решения, сильно влияющие на судьбу продукта.
6. Архитектора свели к проектировщику поставляющему решения, и архитектор оказался не нужен.
7. Однако, вскоре выяснилось, что решения могут быть приняты только человеком глубоко погруженным в контекст задачи. "Решатель" должен пропитаться информацией о продукте.
8. То есть на входе набор разнообразных фактов, а на выходе решения. Что между? Между мозг Архитектора нейронные связи которого построили модель продукта из множества информационных осколков. (Ну почти АИ)
9. Аджайл сразу предложил механизм формирования метафор - первичных представлений продукта, которые потом разрастаются в красивую модель. Очень близко первоначальному понимаю архитектурного стиля.
10. Вот эта самая модель и является архитектурой, на базе которой принимаются решения.
Чем сочнее эта структура тем точнее решения.
С другой стороны, чем больше информации впитал мозг архитектора, тем сложнее (невозможнее) отчуждение имеющегося знания.
Можно только чуть приоткрывать завесу отображая знания в различных представлениях.
Таким образом архитектор формирует архитектуру, которая кроме него никому не доступна, да и не нужна.
И на базе этой ненужной модели может принимать оптимальные и обоснованные решения, ценность которых очевидна.
👍6🔥3
☝️☝️☝️Некоторые следствия
1. Архитектор нужен в системах где
- сложность не позволяет свести структуру к нескольким простым моделям
- требуется значимые решения, то есть от решений зависит судьба продукта
(и соответственно, очень часто архитектор избыточен)
2. Шапочки архитектора и программного инженера - две разные шапочки
- Архитектор, творец который принимает решение на основе слабо формализуемых представлений
- Программный инженер - логик, который из А выводит Б, предсказывая характеристики системы до ее построения.
Это впрочем не исключает процесса перевода одного подхода в другой.
С накоплением опыта интуитивные практики можно формализовать.
3. На системе может быть только один архитектор, либо система должна быть декомпозирована, под разных архитекторов.
Два архитектора над одной системой - две разные ментальные модели, по которым строятся разные решения.
4. Большинство книг/курсов по архитектуре заточены на инженерные практики.
Практика формирования ментальной модели либо вообще аут оф скоуп либо рассмотрена крайне поверхностно.
Это и понятно. То что слабо формализуется, то и плохо передается.
(Хотя в последнем случае, я могу быть не прав. Возможно я просто не попадал на стоящие курсы по этой тематике.)
5. Архитектор, отчётливо проявляющийся в ИТ сфере, должен присутствовать и в других областях связанных со слабо формализуемыми моделями.
И чем дальше от цифр и железок, тем важнее его роль.
Тот же самый "главный конструктор", принимающий не только инженерные решения, тоже архитектор - только еще и отягощенный властью.
6. Для чего я погружаюсь во все эти аспекты мета-архитектуры? Для того чтобы делать значимые выводы )
1. Архитектор нужен в системах где
- сложность не позволяет свести структуру к нескольким простым моделям
- требуется значимые решения, то есть от решений зависит судьба продукта
(и соответственно, очень часто архитектор избыточен)
2. Шапочки архитектора и программного инженера - две разные шапочки
- Архитектор, творец который принимает решение на основе слабо формализуемых представлений
- Программный инженер - логик, который из А выводит Б, предсказывая характеристики системы до ее построения.
Это впрочем не исключает процесса перевода одного подхода в другой.
С накоплением опыта интуитивные практики можно формализовать.
3. На системе может быть только один архитектор, либо система должна быть декомпозирована, под разных архитекторов.
Два архитектора над одной системой - две разные ментальные модели, по которым строятся разные решения.
4. Большинство книг/курсов по архитектуре заточены на инженерные практики.
Практика формирования ментальной модели либо вообще аут оф скоуп либо рассмотрена крайне поверхностно.
Это и понятно. То что слабо формализуется, то и плохо передается.
(Хотя в последнем случае, я могу быть не прав. Возможно я просто не попадал на стоящие курсы по этой тематике.)
5. Архитектор, отчётливо проявляющийся в ИТ сфере, должен присутствовать и в других областях связанных со слабо формализуемыми моделями.
И чем дальше от цифр и железок, тем важнее его роль.
Тот же самый "главный конструктор", принимающий не только инженерные решения, тоже архитектор - только еще и отягощенный властью.
6. Для чего я погружаюсь во все эти аспекты мета-архитектуры? Для того чтобы делать значимые выводы )
👍4
7. Топология "Архитектура как сервис" подходит под инженеров программистов. Им для работы достаточно чёткой постановки задачи и недолгого погружения в контекст.
Архитектор должен работать по схеме плотного взаимодействия с командой.
Архитектор должен работать по схеме плотного взаимодействия с командой.
👍4
1.png
80.7 KB
Граф противоречий: Производительность
Наигравшись вдоволь с матрицей противоречий (аля ТРИЗ) счёл её не эффективной, для решения задач производительности.
Остановился на графе связывающем основные параметры системы с основными хотелками заказчиков.
Работаю так:
1. Выбираю хотелку (потребность). На графе розовые
2. По стрелкам нахожу связанные параметры и определяю:
а. Что из этих параметров сильнее влияет на нужную характеристику
б. Что из этих параметров проще всего изменить
3. Фиксирую пару хотелка-параметр как противоречие
4. Из списка концептов, соответствующих выбранной паре, выбираю более-менее подходящие (короткий список)
5. Взвешиваю концепты исходя из понимания системы (архитектурное решение) и фиксирую вывод в ADR
6. Если решение не найдено, перехожу на фазу "изобретения", которую начинаю с представления идеального решения задачи.
В общем вполне себе механический процесс, который при желании можно легко воспроизвести.
Если интересны детали, могу рассказать или показать на примере.
Пишите )
Наигравшись вдоволь с матрицей противоречий (аля ТРИЗ) счёл её не эффективной, для решения задач производительности.
Остановился на графе связывающем основные параметры системы с основными хотелками заказчиков.
Работаю так:
1. Выбираю хотелку (потребность). На графе розовые
2. По стрелкам нахожу связанные параметры и определяю:
а. Что из этих параметров сильнее влияет на нужную характеристику
б. Что из этих параметров проще всего изменить
3. Фиксирую пару хотелка-параметр как противоречие
4. Из списка концептов, соответствующих выбранной паре, выбираю более-менее подходящие (короткий список)
5. Взвешиваю концепты исходя из понимания системы (архитектурное решение) и фиксирую вывод в ADR
6. Если решение не найдено, перехожу на фазу "изобретения", которую начинаю с представления идеального решения задачи.
В общем вполне себе механический процесс, который при желании можно легко воспроизвести.
Если интересны детали, могу рассказать или показать на примере.
Пишите )
🔥6👍3
Тенденции 2023
Вышел свежий Trends Report от InfoQ
Микросервисы продолжают закатываться.
Вышел свежий 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.
Теперь каждый раз, перед поиском подходящих тактик, я прикидываю простейшую, банальную мат. модель для интересующей меня метрики. ИМХО это эффективнее чем вспоминать слабо-структуированные каталоги тактик разных арх. школ.
Предположим нужно оптимизировать время отклика (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.
Теперь каждый раз, перед поиском подходящих тактик, я прикидываю простейшую, банальную мат. модель для интересующей меня метрики. ИМХО это эффективнее чем вспоминать слабо-структуированные каталоги тактик разных арх. школ.
👍4🔥3😁1
Чуть более сложная математика в довесок
(Кисонька, ну еще капельку)
В предыдущий пост я включил простейшую математику, в которой длительность (время отклика) рассматривалось как одно число.
Что в статистике называют центральной тенденцией.
Однако в реальности измерение времени отклика дает некоторую случайную величину, которую можно оценить распределением.
На графике представлены возможные распределения при времени обработки 1 сек.
Замечу, что пик двух распределений (т. н. мода) одинаков.
Тактики изложенные выше позволяют сдвигать моду влево.
Хотелось бы еще иметь тактики вытягивающие график вверх (зеленый в синий)
Зеленый график имеет существенно худшие показания SLA и на верхних перцентилях ведет себя недостойно.
Причиной такого размазывания зачастую является декомпозиция задачи.
Если браузеру нужно скачать не один файл а сто, распределение просядет вниз.
Отсюда еще одна - седьмая тактика:
7. Уменьшение количества запросов требуемых на выполнение одной операции.
Если слабо влияет на метрики центральной тенденции (среднее, медиану, моду), то может существенно улучшить статистику (высшие перцентили)
(Кисонька, ну еще капельку)
В предыдущий пост я включил простейшую математику, в которой длительность (время отклика) рассматривалось как одно число.
Что в статистике называют центральной тенденцией.
Однако в реальности измерение времени отклика дает некоторую случайную величину, которую можно оценить распределением.
На графике представлены возможные распределения при времени обработки 1 сек.
Замечу, что пик двух распределений (т. н. мода) одинаков.
Тактики изложенные выше позволяют сдвигать моду влево.
Хотелось бы еще иметь тактики вытягивающие график вверх (зеленый в синий)
Зеленый график имеет существенно худшие показания SLA и на верхних перцентилях ведет себя недостойно.
Причиной такого размазывания зачастую является декомпозиция задачи.
Если браузеру нужно скачать не один файл а сто, распределение просядет вниз.
Отсюда еще одна - седьмая тактика:
7. Уменьшение количества запросов требуемых на выполнение одной операции.
Если слабо влияет на метрики центральной тенденции (среднее, медиану, моду), то может существенно улучшить статистику (высшие перцентили)
🔥3
Забавно, но факт.
Архитектора в процессе проектирования выявляют основные цели стейкхолдеров, но зачастую не осознают собственные цели на проекте.
Архитектора в процессе проектирования выявляют основные цели стейкхолдеров, но зачастую не осознают собственные цели на проекте.
😁4😢2