Фактор скорости
Александр Темерев
http://iworld.ru
Фраза «компьютерная техника быстро совершенствуется» мелькает
в статьях и пресс-релизах уже более пятнадцати лет. Но и требования
пользователей к производительности информационных систем не отстают
от технического прогресса. Впрочем, в эпоху персональных компьютеров
каждый пользователь мог принимать меры по увеличению
производительности самостоятельно. Александр Темерев
С появлением Интернета ситуация с производительностью несколько
усложнилась. Неудовлетворительная работа интернет- и
интранет-приложений способна у многих миллионов пользователей
вызвать нервный срыв и нанести им финансовый ущерб. Никто не отменял
и «правила Нильсена», известного специалиста по юзабилити, который
заявлял, что максимальное время реакции системы на запрос, не
раздражающее пользователя, составляет 10 секунд, оптимальное – до 1
секунды, а для того, чтобы у человека возникало ощущение, что
система работает в реальном времени, оно не должно превышать 0,1
секунды. И никуда от этого не деться. Способов решения этой проблемы
два: экстенсивный и интенсивный – добавление новых ресурсов и
оптимизация существующих.
С линейным ростом загрузки сервера интернет-приложений сложность
поддержки производительности системы на необходимом уровне
возрастает экспоненциально. Часто кажется, что для устранения
проблемы достаточно добавить серверу памяти, сменить процессор на
более мощный или увеличить производительность аппаратной части любым
другим способом. И все бы хорошо, но следует учитывать то
обстоятельство, что, к примеру, четырехпроцессорный сервер может
стоить в три раза дороже двухпроцессорного, в то время как
эффективность работы системы возрастет лишь на 60–70%. Не окажется
выходом из ситуации и объединение пары двухпроцессорных серверов в
кластер – программное обеспечение, необходимое для осуществления
этой операции, как правило, далеко не бесплатно, а относительный
прирост производительности может оказаться еще более низким. Часто
оказывается, что главной причиной неудовлетворительной скорости
реакции интернет-приложений на запросы пользователей является
отсутствие какой-либо их оптимизации (или окружения, в котором они
исполняются). Рассмотрим этот вопрос более детально.
Оптимизация программного кода
20% людей выпивают 80% пива. Эмпирическое правило 20/80
Загрузка системы, создаваемая приложением, практически всегда
неравномерно распределена по времени. Известное эмпирическое правило
20/80 может применяться и в этой прикладной области: в большинстве
случаев 20% кода программы будут работать в течение 80%
процессорного времени. Таким образом, оптимизация скорости
выполнения должна затрагивать в первую очередь именно эти
критические участки.
Как же определить, какие именно фрагменты кода программы
нуждаются в переработке? Программист со стажем может выявить их,
основываясь на собственном опыте и общеизвестных паттернах
оптимизации производительности (вынос объявления переменных за
пределы циклов, устранение промежуточных вычислений и т. п.). Но это
тупиковый путь – ни один программист, даже группа программистов, не
сможет провести подобный аудит проекта объемом несколько миллионов
строк кода с зависимостями от сотен внешних библиотек – эту
процедуру следует автоматизировать, насколько это вообще возможно.
Для этого используются специальные программные инструменты –
профилировщики (profilers).
По особенностям работы профилировщики напоминают отладчики – в
работающей под их управлением программе исполняется строка за
строкой, метод за методом. Но в отличие от отладчиков,
предназначенных для выявления логических ошибок в процессе
выполнения, профилировщики измеряют скорость работы отдельных частей
приложения и выводят подробные отчеты об их состоянии, а в некоторых
случаях – сразу рекомендации по улучшению производительности
выявленных проблемных участков (bottlenecks). Во многих
профилировщиках реализована поддержка новейших интернет-технологий,
вплоть до веб-сервисов. К числу наиболее известных относятся
Quantify от компании Rational Software (для использования с Visual
Basic, Visual C++ и Java) и JProbe от Sitraka (для использования в
окружении Java).
Оптимизация «трудных» участков кода может заключаться в изменении
алгоритма реализации требуемой функциональности, использовании более
производительных внешних библиотек, а также переписывании их в
рамках эффективнее взаимодействующего с аппаратной частью окружения.
Например, в Java-проекте иногда может иметь смысл вынести наиболее
критичные к скорости выполнения модули во внешние библиотеки,
реализованные средствами C или C++, и подключить их к основному
проекту через механизм JNI.
Оптимизация среды исполнения
Современные интернет-приложения могут исполняться в очень сложном
окружении, собранном из множества взаимосвязанных компонентов.
Архитектуры, предназначенные для развертывания веб-сервисов, такие
как Java 2 Enterprise Edition и Microsoft .NET, включают в себя
несколько слоев (tiers), каждый из которых отвечает за определенный
уровень функциональности всего приложения. А это означает, что в
каждом из этих слоев потенциально могут возникнуть проблемы с
производительностью, которые, накапливаясь, могут превратить жизнь
пользователя в настоящий кошмар.
Не стоит также недооценивать роль правильной конфигурации
операционной системы. Параметры, установленные в ней по умолчанию,
как правило, не предназначены для развертывания сколько-нибудь
масштабных проектов с высокой загрузкой. Подстройка их под
конкретные условия может в отдельных случаях на порядок улучшить
производительность исполняемых приложений.
Серверы приложений – основной архитектурный компонент платформы
J2EE, как правило, обладают очень широким спектром настраиваемых
параметров. К ним относятся, например, свойства пула соединений с
базой данных, параметры активации и пассивации EJB-компонентов,
предельное количество одновременно открытых сессий с пользователями
и многие другие. А уж об оптимизации производительности баз данных и
веб-серверов, находящихся по разные стороны серверов приложений, но
формирующих вместе с ними единую среду исполнения, написаны целые
книги. Например, для веб-сервера Apache хорошим местом для начала
размышлений по этому поводу является соответствующий раздел сайта
проекта – http://httpd.apache.org/docs-2.0/misc/perf-tuning.html.
К счастью, современные Unix-подобные операционные системы
обладают широчайшими возможностями приспособления к конкретным
условиям и конкретным проектам. Рассмотрим их чуть более подробно на
примере ОС Solaris, позиционируемой компанией Sun Microsystems в
качестве основной платформы для развертывания веб-сервисов и
комплексных корпоративных решений.
Наиболее важными факторами, влияющими на скорость выполнения
приложений в окружении Solaris, являются параметры ядра ОС, системы
управления памятью и файловой системы. Поскольку структура ядра
Solaris модульная, то для оптимизации производительности системы под
конкретный проект следует исключить из него все установленные по
умолчанию, но не используемые в реальных условиях модули. Особое
внимание необходимо уделить переменной окружения maxusers,
определяющей максимально допустимое число одновременных
пользовательских сессий. Завышенное ее значение приведет к выделению
системой излишних ресурсов, которые никогда не будут задействованы в
реальных условиях; заниженное – к невозможности подключения к ней
необходимого количества пользователей (в том числе и
зарезервированных системой и приложениями) и критическим сбоям в
функционировании приложений.
К критичным настройкам системы управления памятью относятся,
прежде всего, параметры файла подкачки. Для оценки эффективности
текущих настроек служат, в частности, такие инструменты ОС Solaris,
как vmstat, swap, sar и ps. Команда sar, к примеру, позволяет
получить статистический отчет о функционировании системы управления
памятью, а vmstat – наблюдать за большим количеством ее параметров в
динамике.
Количество настроек файловых систем, поддерживаемых Solaris,
также внушает уважение. Оптимизация таких из них, как плотность
индексов, количество цилиндров в цилиндровой группе и максимальное
число блоков на один файл, могут заметно улучшить производительность
системы по сравнению с производительностью при установках по
умолчанию. Для работы с параметрами файловых систем служит команда
Solaris tunefs.
Разумеется, настройки операционной системы Solaris далеко не
исчерпываются упомянутыми выше. Более подробную информацию о них
можно получить на сайте http://docs.sun.com/, задав в
качестве строки поиска фразу «Solaris Tunable Parameters Reference
Manual». Подобные документы существуют и для других распространенных
операционных систем.
Таким образом, оптимизация производительности интернет-приложений
во многих случаях позволяет решить проблемы пользователей,
возникающие из-за ее недостатка. Но, к сожалению, существуют и
физические пределы, определяемые характеристиками используемого
аппаратного обеспечения, и никакие программные ухищрения не способны
преодолеть этот барьер – на это способен лишь апгрейд. Впрочем, это
уже совсем другая история...
|