По мере приближения следующего десятилетия у меня была возможность поразмышлять над тем, чему я научился у своих коллег из обоих моих работодателей: Oracle и VMware за последнее десятилетие моей карьеры. В то время как некоторые коллеги действительно выделялись, яростно указывая на мои ошибки и ошибки в суждениях, другие позволили мне расти и учиться, приняв меня в качестве своих наставников. Позвольте мне резюмировать пять ключевых принципов, которым меня научили мои сверстники. Я выбрал эти принципы в основном потому, что они противоречили тому, во что я, начинающий инженер, верил, когда начал работать более 12 лет назад, но в нескольких случаях было доказано, что они неверны. Эти уроки действительно помогли мне вырасти.

Итак, вот мой список.

1. Разработайте архитектуру для повышения производительности. Эту ошибку я неоднократно повторял, когда отдельные лица или группы принимали проектные решения относительно архитектуры нового продукта или функции. Многие проекты ориентированы на причудливые идеи разработки (например, крутые конструкции, структуры данных, стили программирования и т. д.) или на быстрый оборот (например, развертывание функции/продукта как можно раньше). Это не без причины, большинство проектов разрабатывается разработчиками программного обеспечения или менеджерами по персоналу/продукту, которые по своей природе предвзято относятся к аспектам дизайна программного обеспечения, которые они ценят больше всего. Однако при этом забывается один ключевой аспект. Продукты или функции продукта конкурируют за пользовательский опыт (UX). И производительность является ключевой частью пользовательского опыта. И это также часть, которая регистрирует наиболее благоприятное или неблагоприятное впечатление среди пользователей. Так что, будь то веб-страница, которая загружается медленно, или резервное копирование/восстановление системы, которое занимает слишком много времени; ваши пользователи обязательно его запомнят, особенно если у нашего конкурента это получается лучше. К сожалению, если дизайн не рассматривает производительность как одну из своих основных целей, все, что можно сделать позже, — это микрооптимизация производительности; которые могут улучшить, но не революционизировать пользовательский опыт. Итак, я хочу сказать, что подумайте о том, чтобы привлечь человека в вашу команду или организацию, который занимается или работал над некоторыми аспектами проектирования производительности на ранних стадиях вашего проекта.

2. Инвестируйте в автоматизацию. Когда я впервые начал работать над проектированием производительности, я был предельно сосредоточен на аспектах отладки проблем с производительностью и оптимизации кода для повышения производительности. Раньше я отслеживал, анализировал и переписывал код. Аспекты, связанные с автоматической загрузкой системы в желаемое состояние программного обеспечения и автоматическим запуском эксперимента, казались ниже моего уровня оплаты, чтобы инвестировать в них. Поэтому я в основном занимался этими аспектами вручную. Однако любые ручные операции, хотя и простые для начала, начинают занимать все больше и больше времени по мере увеличения сложности экспериментов и сбора данных. Инженерия производительности требует повторения экспериментов при строго контролируемых настройках, чтобы можно было исключить из анализа вариации результатов от запуска к запуску. Невозможно проводить такие эксперименты в масштабе.

Автоматизация решает все эти проблемы, избавляя от скучных и грязных частей проектирования производительности. Структура автоматизации должна быть разработана для: (i) настройки системной инфраструктуры с желаемыми битами кода (например, конкретной сборки операционной системы, которую необходимо протестировать), (ii) начальной загрузки и запуска желаемого эксперимента. (iii) Запустите все инструменты, необходимые для анализа показателей производительности системы в ходе эксперимента, (iv) Соберите и заархивируйте все данные, чтобы обученный инженер мог быстро и эффективно их проанализировать. Автоматизация экономит ценное человеческое время и усилия, а также повышает коэффициент использования машин и другого оборудования.

3. Блокировки стоят недешево. Цитата из Википедии. В компьютерных науках блокировка или мьютекс (от взаимного исключения) — это механизм синхронизации для обеспечения ограничений на доступ к ресурсу в среде, где есть много нити исполнения. Разработчик программного обеспечения очень часто определяет и использует блокировку везде, где требуется какая-либо форма контроля доступа. Первая цель использования блокировки должна состоять в том, чтобы гарантировать, что она достигает желаемой цели в коде, и отсутствуют серьезные проблемы, такие как взаимоблокировки. Имейте в виду, что замки также могут оказаться очень дорогими. Проще говоря, блокировка — это часть памяти, к которой два или более разных ЦП (где запланировано выполнение потоков) потребуются для доступа при получении и освобождении блокировки. В соответствии с аппаратной конструкцией эта часть памяти может быть кэширована только на том уровне, к которому оба этих ЦП будут иметь одновременный доступ. В худшем случае, когда процессоры не расположены на одном процессорном сокете, этот кусок памяти вообще не может быть закэширован. В случае жесткой конкуренции за блокировку при доступе к этой области памяти можно было бы увидеть значительные задержки процессора.

Следовательно, нужно быть усердным в дизайне замка. Другая проблема, которая часто возникает, заключается в том, что мы пишем код для вызова подпрограммы/API без понимания парадигмы блокировки, которую использует API. Следовательно, тип используемых блокировок и аспекты масштабируемости должны быть хорошо задокументированы в описании любой общедоступной процедуры.

4. Вспомните закон Амдала. Хотя закон Амдала определен для достижимого ускорения при параллельной обработке, он прекрасно применим и к проектированию производительности. Проще говоря, общее улучшение производительности конвейера выполнения диктуется улучшением самого медленного шага выполнения. В качестве примера рассмотрим подпрограмму, в которой самый медленный шаг A занимает 80% времени выполнения. Улучшение скорости на шаге А на 25% приведет к общему увеличению скорости выполнения упражнения на 20%. Это хороший выигрыш. С другой стороны, 25-процентное улучшение любой оставшейся части программы, не включающей шаг А, улучшит программу только на 5%. Следовательно, всегда важно собрать данные и выявить самого медленного игрока в игре. Хороший инженер по производительности всегда будет использовать данные, чтобы определить самые низкие висящие плоды, прежде чем тратить циклы на работу над оптимизацией. Следовательно, инструменты и автоматизация выделяются как очень важный фактор в разработке производительности.

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

Я всегда открыт для мыслей/комментариев/опыта коллег-инженеров по этой теме. Напишите мне по электронной почте или, лучше, примите участие в обсуждении ниже.