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

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

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

Задачи настройки производительности, выполняемые на этапе подготовки технических требований, обладают важной особенностью. Дело в том, что на этом этапе, безусловно, еще нет смысла заниматься физической настройкой системы, но решения по физической настройке системы, принятые в этот период, влекут за собой очень важные последствия. В частности, необходимо найти ответ на вопрос о том, желает ли заказчик в большей степени добиться повышения воспринятой производительности или сократить общее время выполнения задания. Если применяемые процессы в основном являются интерактивными, то пользователи, как правило, испытывают большее удовлетворение и выражают мнение, что система обеспечивает достаточно высокое быстродействие, если перед ними на экране сразу же обнаруживаются какие-то изменения (даже если они сводятся к перемещению индикатора выполнения). Кроме того, иногда вполне целесообразно немного увеличить обшую продолжительность выполнения процесса, при условии, что первый отклик поступает достаточно быстро, иными словами, пользователь сразу же получает хотя бы часть затребованных им данных. Именно о том, какой из этих вариантов является наиболее приемлемым, следует подумать на этапе разработки технических требований. Наконец, на этом этапе необходимо определить, каковы общие требования к производительности системы.

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

Прежде чем приступать к проектированию системы, необходимо уточнить все требования к этой сиетеме. Кроме того, следует обязательно проверить, соответствует ли система предъявленным к ней требованиям при реальной нагрузке во время эксплуатации с применением аппаратных средств, которые по своим характеристикам близки к тем, что будут применяться в действительности; недостаточно просто проверить систему в условиях нагрузки, которую создают один-два разработчика, занимающиеся отладкой программного обеспечения.

Безусловно, все проблемы повышения производительности невозможно решить на этапе предпроектной подготовки, поэтому данная работа продолжается также на этапе проектирования. Если проект создается с учетом повышения требований производительности, то, как правило, объем усилий, требуемых для настройки производительности на этапе завершения системы, существенно уменьшается. Кроме того, обнаруживается, что достигнуты или даже превышены наилучшие показатели производительности, на которые можно было рассчитывать.

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

Обнаруживается какое-то нарушение в работе (связанное с программной ошибкой).

Возникает необходимость в проведении модернизации определенной части системы.

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

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

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

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

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

Еще одна, но далеко не последняя рекомендация, позволяющая никогда не останавливаться на пути к достижению все более высоких показателей, состоит в следующем. Обращайтесь к конечным пользователям и старайтесь узнать, какие пожелания они могут высказать в отношении повышения производительности. Возможно, на каком-то этапе происходит замедление в работе. Не дожидайтесь того, что придет время и об этом скажут сами пользователи (безусловно, пользователи часто считают, будто система так и должна работать, и никому не сообщают о возникающих замедлениях, разумеется, кроме как самому старшему руководству); поэтому следует чаще обращаться непосредственно к пользователям, чтобы узнать, какие они испытывают затруднения.

Выбор индексов

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

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

По меньшей мере один индекс должен быть определен на любой таблице, на которой задан первичный ключ (а первичный ключ должен применяться на всех таблицах, за очень редким исьслючением). Но из того, что индекс задан на первичном 1слю-че, не следует, что это - наиболее полезный индекс с точки зрения производительности. Индексы следует предусматривать для любого столбца, который должен часто использоваться в качестве объекта в конструкциях WHERE, операторах JOIN, а также, в меньшей степени, в конструкции ORDER BY.

Но следует помнить, что по мере увеличения количества индексов скорость выполнения операторов вставки уменьшается. Дело в том, что при вставке строки в каждый индекс приходится вносить один или несколько элементов (в зависимости от того, насколько заполненными являются нелистовые узлы структуры в виде двоичного дерева). Это означает, что по мере увеличения количества индексов объем работы, выполняемый СУБД SQL Server, увеличивается. В среде оперативной обработки транзакций (Online Transaction Processing - OLTP) среда, которая характеризуется применением большого количества операций вставки, обновления и удаления, эксплуатация большого количества индексов может привести к существенному снижению производительности приложения. С другой стороны, в среде оперативной аналитической обработки (Online Transaction Processing- OLAP) такая проблема в основном не возникает, поскольку данные OLAP обычно являются относительно стабильными (количество вставок невелико), а операции вставки, как правило, выполняются с помощью фактически одинаковых, повторяющихся пакетных процессов (благодаря чему исключается такой фактор, как непредсказуемость выполнения операций вставки пользователями).