[Title will be auto-generated] by Smith John

Р У С С К А Я РЕЩЦП

Microsoft

Пусть не иссякнет в Microsoft тот дух товарищества, который дал возможность единомышленникам из АСЕ Team написать эту книгу.

PERFORMANCE TESTING MICROSOFr

.NET WEB APPLICATION

Microsoft ACE Team

Microsoft Press

ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ WEB-ПРИЛОЖЕНИЙ MICROSOFT

.NET

Microsoft ACE Team Москва 2003

ISi,

УДК 004.45 ББК 32.973.26-018.2 М59

М59

Microsoft Corporation Тестирование производительности Web-приложений Microsoft .NET/ Пер. с англ. — М.: Издательско-торговый дом «Русская Редакция», 2003. - 352 С.: ил. ISBN 5-7502-0224-0 Эта книга написана группой специалистов Microsoft, протестировавших и настроивших сотни Web-сайтов и Web-приложений, — Microsoft Application Consulting and Engineering (ACE) Team (группа консалтинга и проектирования приложений Microsoft). Она познакомит вас с новинками в области тестирования, анализа и настройки производительности Web-приложении. В книге рассматривается применение инструментов для планирования и выполнения тестов производительности, настройка средств профилирования, а также анализ данных о производительности Microsoft IIS, ASP.NET, упрааляемого кода и SQL-уровня. Также здесь описана методология, которую Microsoft применяет для нагрузочного тестирования собственных, наиболее загруженных и высокопроизводительных сайтов. Книга состоит из 10 глав и предметного указателя, и снабжена компакт-диском, содержащим примеры кода. УДК 004.45 ББК 32.973.26-018.J Подготовлено к изданию по лицензионному договору с Microsoft Corporation, Редмонд, Вашингтон, США. Application Expert — охраняемый товарный знак компании Compuware Corporation. ActiveX, BackOffice, BizTalk, JScript, Microsoft, Microsoft Press, .Net, PowerPoint, Visual Basic, Visual C++, Visual C#, Visual InterDev, Visual ) + + , Visual SourceSafe, Visual Studio, Win32, Windows и Windows NT являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствующих фирм. Все названия компаний, организаций и продуктов, а также имена лиц, используемые з примерах, вымышлены и не имеют никакого отношения к реальным компаниям, организациям, продуктам и лицам.

ISBN 0-7356-1538-1 (англ.) ISBN 5-7502-0224-0

Оригинальное издание на английском языке, Microsoft Corporation, 2003

Перевод на русский язык, Microsoft Corporation, 2003

Оформление и подготоака к изданию, издательоко-торговый дом «Русская Редакция», 2003

Благодарности Введение

XI XII

Для кого написана эта книга Материалы на прилагаемом к книге компакт-диске Как пользоваться прилагаемым компакт-диском Требования к конфигурации Обзор глав книги Поддержка

XII XIII XIII XIV XV XVI11

ГЛАВА 1 ОСНОВЫ АНАЛИЗА ПРОИЗВОДИТЕЛЬНОСТИ Важность тестирования и настройки производительности Эффекты старых и новых технологий Что такое .NET Платформа .NET Стандартные протоколы .NET Язык\Л/5О1 Спецификация UDDI Что такое Web-сервис XML Необходимость Web-сервисов для поддержки новых типов устройств Необходимость Web-сервисов для тестирования Web-производительности Целевые показатели производительности Поведение пользователей при взаимодействии с компьютером Тестирование производительности вашего приложения Планирование анализа производительности Создание эффективных нагрузочных сценариев Исполнение нагрузочных сценариев Анализ результатов измерения производительности Заключение...

1 1 3 4 5 7 8 8 9 10 11 11 12 13 15 15 15 16 18

Оглавление

ГЛАВА 2 ПОДГОТОВКА И ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ Определение целевых параметров производительности Допустимое время отклика Пропускная способность и число одновременных пользователей Анализ потенциального роста производительности Профиль активности пользователей Профиль активности сервера Идентификация пользовательской активности Web-приложения Выявление «узких» мест в серверной части приложения Ключевые метрики производительности Моделирование реальной среды работы приложения Составление плана тестирования производительности Заключение

ГЛАВА 3 НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ С ПОМОЩЬЮ ACT Основы Что такое ACT Установка Microsoft ACT на компьютер Базовые понятия ACT Динамические тесты Параллельные пользователи и параллельные браузерные сессии ACT Пользователи и группы «Cookie» Заголовки Аутентификация и шифрование SSL

Использование SOAP с ACT Обработка состояния отображения Защита Web-сайта от ошибочного нагрузочного тестирования Запуск ACT Обзор пользовательского интерфейса ACT Создание тестового сценария Исполнение нагрузочного теста Заключение...

19 20 20 21 23 24 26 26 26 27 29 30 31

32 32 33 34 35 36 36 38 38 39 39 42

42 43 44 45 45 49 66 .. 69

Оглавление

VII

ГЛАВА 4 МОНИТОРИНГ ПРОИЗВОДИТЕЛЬНОСТИ ПРИЛОЖЕНИЯ С ПОМОЩЬЮ СИСТЕМНОГО МОНИТОРА

Использование системного монитора Наблюдение за производительностью в реальном времени Частота замеров Генерация и просмотр журналов Мониторинг удаленных компьютеров Объекты, счетчики и экземпляры, применяемые для выявления «узких» мест «Узкие» места при использовании процессора Решение типичных проблем, связанных с перегрузкой процессора Объект System «Узкие» места при работе с диском Как ACT Team выявила «узкое» место дисковой подсистемы Влияние архитектуры дисковой подсистемы на производительность Память Как ACT Team выявила утечку памяти Создание и настройка оповещений Заключение

96 96 98 100 107

ГЛАВА 5 АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ РАБОТЫ В СЕТИ

108

Проведение анализа сетевой производительности приложения Сетевые задержки Сетевые обмены Уменьшение числа сетевых обменов Передаваемые данные Уменьшение объема передаваемых данных Задержки обработки Сокращение задержек обработки Время отклика Пользовательские сценарии Работа с Microsoft Network Monitor Сбор сетевого трафика

108 109 111 112 112 113 116 116 118 119 120 127

72 77 78 84 85 86 89 90 92 93

VIM

Оглавление

Работа с Application Expert фирмы Compuware Анализ сетевых данных с помощью Application Expert Заключение

1 30 136 141

ГЛАВА 6 АНАЛИЗ И НАСТРОЙКА ПРОИЗВОДИТЕЛЬНОСТИ WEB-УРОВНЯ

142

Особенности конфигурации и параметры производительности Расширения имен файлов для ASP.NET Аутентификация в ASP.NET Конфигурационные файлы Знакомство с Web-приложением Профилирование Web-приложения .МЕТ Файлы журнала IIS Трассировка на уровне кода Счетчики системного монитора Советы по настройке производительности Состояние приложения и состояние сессии Кэширование в ASP.NET Отключение состояния отображения ADO.NET Типичные «узкие» места Web-уровня Масштабируемость на Web-уровне Масштабирование вширь, масштабирование вверх или настройка производительности? Когда следует масштабировать Web-уровень Как масштабируется Web-уровень Заключение

181 182 183 1 84

ГЛАВА 7 АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ УПРАВЛЯЕМОГО КОДА

185

CLR и производительность Microsoft Intermediate Language Компилятор по требованию Возможность предварительной компиляции Жизненный цикл Web-приложения .NET Период загрузки — домены приложения Период выполнения - взаимодействие Период выполнения — сбор мусора Период выполнения — исключения

185 186 186 188 188 1 88 189 190 1 94

143 144 144 146 148 149 149 157 162 165 165 167 1 70 171 177 181

Оглавление

Счетчики производительности .NET Объект.NET CLR Memory Объект .NET CLR Loading Объект .NET CLR Locks And Threads Объект .NET CLR Exceptions Объект .NET CLR Security Профилирование управляемого кода Знакомство с Compuware DevPartner Studio Использование AppMetrics для наблюдения за компонентами .NET Enterprise Services Использование AppMetrics для предварительного мониторинга Мониторинг рабочего приложения Заключение

196 197 200 201 202 203 205 205

ГЛАВА 8 АНАЛИЗ SQL-УРОВНЯ

219

Выявление «узких» мест Наш инструментарий Проблемы блокирования Настройка индексов Анализ планов выполнения Индексы Правильный выбор индексов Заключение

220 221 229 237 237 245 246 262

ГЛАВА 9 ОЦЕНКА ЭФФЕКТИВНОСТИ MS-УРОВНЯ ПОСРЕДСТВОМ ТСА

263

Одновременные подключения: термин без четкого определения Обработка одновременных запросов на сервере Одновременные подключения в ТСА Преимущества проведения ТСА Пять этапов ТСА Этап 1: создание профиля пользователя Этап 2: нагрузочный тест для определения затрат на действия пользователя Этап 3: расчет стоимости каждого действия пользователя Этап 4: оценка пропускной способности сайта Этап 5: проверка пропускной способности сайта Заключение...

211 213 215 218

265 265 266 267 269 270 273 276 281 285 287

Оглавление

ГЛАВА 10 МОДЕЛИРОВАНИЕ: ИНСТРУМЕНТЫ ПРОГНОЗА ПРОИЗВОДИТЕЛЬНОСТИ 288 Прогнозирование и оценка производительности с помощью ТСА Усложненное моделирование производительности Технология моделирования производительности Сценарии моделирования Методы моделирования производительности Инструменты моделирования производительности Indy: инфраструктура технологии оценки производительности Концепции Indy Архитектура Indy IndyView Итоговое сравнение ТСА и моделирования производительности Создание сценариев «что, если» с помощью Indy Заключение

314 314 316

Предметный указатель

318

Об авторе

325

289 290 291 291 293 297 298 298 299 301

Группа Microsoft Application and Consulting Engineering (ACE) Team выражает свою благодарность всем тем, кто оказал нам помощь и поддержку при работе над данной книгой. Во-первых, мы говорим «спасибо» нашим шефам — Майку Адамсу (Mike Adams) и Трейси Шелл (Tracy Shell), поверившим в то, что работа над книгой не помешает исполнению нами своих основных обязанностей. Далее, несколько технических редакторов обеспечили точность материала книги. Мы признательны Мэтту Однеру IMatt Odhner) за проницательные замечания no ACT в главах, начиная с третьей, Джиму Пирсону (Jini Pierson) -— за редактирование главы 5, Фабио Иону (Fabio Yeon) и Митике Ману (Mitica Manu) — за главу 6, Эрику Рэхнеру (Eric Rachner), Чаду Диллинжеру (Chad Dellinger) и Митика Ману (Mitica Manu) за их вклад в создание седьмой главы. Отзывы по восьмой главе предоставили Джулиус Чен (Julius Chen) и Кен Хендерсон (Ken Henderson), тогда как рецензентом девятой стал один из обладателей патента no TCA (Transaction Cost Analysis — анализ стоимости транзакции) — Дэвид Гуимбелло (David Guimbellot). Кроме того, в работе над главой 9 участвовал Перри Кларк (Perry Clarke), также обладатель патента no TCA, и Крис Лоусон (Chris Lawson) -— смышленый интерн, любезно согласившийся выполнить верификационные тесты ТСА. Мы выражаем искреннюю благодарность группе MSN Enterprise Tools и особенно Джонатану Хардвику (Jonathan Hardwick) и Стасису Папаэфстафиу (Stathis Papaefstathiou), потратившим много времени и сил на десятую главу. Мы также хотели бы отметить помощь в редактировании, которую оказал Роберт Диллингем (Robert Dillingham) — программный менеджер из АСЕ Team. Кроме того, говорим «спасибо» Джулиане Алдоус (Juliana Aldous) и Линн Финнел (Lynn Finnel} из Microsoft Press за их терпение, которое они проявляли, пока мы работали над книгой. И, наконец, мы очень благодарны Махешу Пракрия (Mahesh Prakriya) из группы .NET Framework, который помог направить изложение материала в правильное русло.

За написание этой книги нас заставило взяться жгучее желание поделиться нашим опытом и знаниями, полученными при работе в группе Microsoft Application Consulting and Engineering (ACE) Team, в задачи которой входит анализ производительности некоторых из наиболее загруженных Web-приложений и сайтов Microsoft. В частности, мы занимались определением численных параметров производительности и времени отклика, идентификацией «узких» мест, а также оптимизацией и настройкой Webприложений масштаба предприятия. В общем, всем тем, что позволяет повысить производительность Web-приложений Microsoft. Наша группа занимает лидирующие позиции в области анализа производительности и разрабатывает сервисы настройки производительности мирового уровня. В этой книге изложена методология, которая появилась на свет при работе в условиях динамичной и сложной среды корпоративной интра- и экстасети Microsoft.

Для кого написана эта книга Так как анализ производительности Web — весьма новая область (в сравнении с разработкой программ, где традиционно выделяются роли разработчика, специалиста по тестированию и сопровождению), назвать аудиторию, которой предназначается эта книга, сложно. Однако можно доподлинно утверждать, что она окажется полезной каждому, кто отвечает за обеспечение адекватной производительности Web-приложений, построенных на основе технологий Microsoft. Специалисты групп тестирования найдут в книге описание конкретных приемов анализа производительности приложений. Менеджерам, отвечающим за планирование производительности Web-приложений, наверняка пригодятся рекомендации о том, как включить анализ производительности в цикл разработки, определить требования к аппаратным средствам и вычислить потенциальные затраты на развитие инфраструктуры.

Введение

XIII

Материалы на прилагаемом к книге компакт-диске Прилагаемый к книге компакт-диск содержит: •

автоматически запускающееся меню доступа к ресурсам компакт-диска;

• примеры из книги; • информацию о таймерах ASP; • шаблоны для системного монитора; • программу установки примеров; • презентацию Compuware Application Expert (в формате Microsoft PowerPoint); • оригинальную версию книги,

Как пользоваться прилагаемым компакт-диском Программа StartCD предоставляет графический интерфейс доступа к содержимому компакт-диска. Если у вас на компьютере включен режим автозапуска, то данная программа запустится сама, когда вы вставите компакт-диск. Если же он отключен, запустите 5tartCD.exe из корневого каталога компакт-диска и воспользуйтесь появившимся на экране меню Start. Из него доступны все ресурсы диска, в том числе ссылки, вызывающие установку программ, необходимых для просмотра содержащихся на нем файлов, и ссылки на Web-сайт поддержки Microsoft Press, Файлы примеров Тестовые сценарии ACT, обсуждаемые в книге, хранятся в папке Sample Files на прилагаемом компакт-диске. Чтобы скопировать их на свой жесткий диск, запустите Setup.exe из папки Setup и следуйте указаниям. Для установки требуется около 5 Мбайт пространства на жестком диске. Чтобы удалить установленные примеры, вызовите Панель Управления, затем — Установка и удаление программ и выберите соответствующий пункт. Таймеры ASP Документ в формате Microsoft Word, описывающий создание ASPтаймера с помощью Microsoft Visual Basic Scripting Edition (VBScript) или (Script, хранится в папке ChapterOS на компакт-диске.

XIV

Введение

Шаблоны для системного монитора Шаблоны для системного монитора — это готовые счетчики производительности, также записанные на компакт-диске (каталог Chapter04). С их помощью зы быстро запустите мониторинг производительности IIS (Internet Information Services) или SQL Server. Презентация PowerPoint: Compuware Application Expert Compuware Application Expert рассматривается в пятой главе. Презентация PowerPoint в папке ChapterOS на прилагаемом компакт-диске иллюстрирует некоторые часто используемые возможности Application Expert. Электронная версия книги Полный текст книги находится на компакт-диске в формате, поддерживающем текстовый поиск. Для установки запустите Autorun.ехе из папки eBook. Для просмотра вам потребуются Microsoft Internet Explorer 5.01 (или более поздний), а также соответствующие компоненты HTML Help. Если Internet Explorer 5.01 (или более поздний) не установлен на вашем компьютере, то программа установки предложит вам Internet Explorer 5.5 в минимальной конфигурации, необходимой для просмотра электронной книги. При установке ваша текущая настройка не изменится. Если вы работаете в ОС Microsoft Windows NT 4.0, Microsoft Windows 2000 или Microsoft Windows XP. то для запуска электронной книги вам потребуются административные права. Если у вас таких прав нет, но на компьютере установлен Internet Explorer 5.01 (или более поздний), то для просмотра книги достаточно открыть файл perftest.CHM в папке \eBook\ls_001.

Требования к конфигурации • Microsoft Windows XP или Windows 2000. • Microsoft Visual Studio .NET, Enterprise Developer или Enterprise Architect. Ниже приведены требования для работы Visual Studio .NET: • компьютер/процессор ПК с процессором типа Pentium II, 450 МГц; • память 96 Мбайт для Windows 2000 Professional; 160 Мбайт для Windows XP Professional;

Введение

• жесткий диск 2.5 Гбайт, включая не менее 500 Мбайт на системном диске; •

дисковод

привод CD-ROM или DVD-ROM;

• дисплей Super VGA (800 х 600) или с более высоким разрешением, 256 цветов; • операционная система Windows 2000 или Windows XP; •

мышь

Microsoft Mouse или совместимое устройство.

Обзор глав книги Эта книга состоит из четырех частей, в каждой из которых описана соответствующая фаза процесса тестирования производительности (табл. 1-1.). Табл. 1-1, Фазы тестирования производительности Фаза тестирования

Главы

Планирозание Исполнение Анализ Моделирование

1,2 3,4

5,6, 7,8 9, 10

Далее приведен краткий обзор каждой главы. Тем, кто не любит читать все подряд, он даст общее представление об излагаемых темах. Глава 1: Основы анализа производительности В главе 1 рассказывается о месте тестирования производительности в цикле разработки программного обеспечения и поясняется, почему тестирование производительности не менее важно, чем функциональное тестирование. Мы расскажем о том, как результаты тестирования производительности позволяют получить более реалистичные сценарии развертывания приложения и существенно снижают проектные расходы. Кроме того, здесь описаны основы используемой в этой книге методологии тестирования производительности. Глава 2: Подготовка и планирование тестирования производительности Прежде чем приступить к тестированию производительности, необходимо собрать определенную информацию о тестируемом

XVI

Введение

приложении. В главе 2 перечислены виды информации, которую должен собрать тестер, а также источники ее получения, в том числе публикуемые прогнозы развития рынка, журналы работы IIS, журналы производительности и функциональные спецификации приложения. Глава 3: Нагрузочное тестирование с помощью ACT

Так как в книге обсуждаются Web-приложения, созданные исключительно с помощью ПО и технологий Microsoft, то в качестве инструмента нагрузочного тестирования мы взяли Microsoft Application Center Test (ACT). ACT — это относительно новый инструмент. В главе 3 приводится его подробный обзор, в том числе создание с помощью ACT тестовых сценариев, а также обсуждаются проблемы написания сценариев для Web-приложений, Глава 4: Мониторинг производительности приложения с помощью системного монитора

System Monitor (Системный монитор) — основное средство для анализа производительности Web-приложения. Глаза 4 познакомит вас с System Monitor и наиболее часто используемыми счетчиками производительности, а также с их применением для идентификации «узких» мест, связанных с использованием процессора, диска и памяти. Глава 5: Анализ производительности работы в сети

В глазе 5 приведен обзор анализа сетевой производительности. Его назначение — определение страниц или функций приложения, на пересылку которых требуется наибольшее время, Рекомендации АСЕ позволяют выявить медленно работающие страницы или функции путем сбора всего трафика эашего приложения с помощью Network Monitor и последующего анализа собранных данных с целью экстраполяции времени отклика для конечного пользователя, объемов передаваемой информации и числа сетевых обменов (round trip). Глава 6: Анализ и настройка производительности Web-уровня

Данные, собранные на уровне IIS, помогут вам выявить «узкие» места в коде ASP.NET, на промежуточном уровне или на уровне SQL. Из этой главы вы узнаете, как интерпретировать содержимое журналов 11$ и монитора производительности для поиска этих

Введение

XVII

«узких» мест. Кроме того, здесь содержатся рекомендации по устранению «узких» мест на уровне IIS. Глава 7: Анализ производительности управляемого кода Для успешного тестирования производительности Web-приложений на основе Microsoft .NET абсолютно необходимо знать способы анализа и профилирования управляемого кода, В главе 7 рассмотрены характеристики .NET Framework, непосредственно влияющие на производительность Web-приложения на основе .NET. Здесь также описаны основные счетчики производительности .NET и два полезных приложения для профилирования производительности управляемого кода. Глава 8: Анализ SQL-уровня «Узкие» места на SQL-уровне снижают производительность Webприложений на порядок. Кроме того, идентификация и устранение «узких» мест в серверной части в некоторых случаях крайне сложны. Для правильной диагностики и устранения проблем на уровне Microsoft SQL Server требуется высокий профессионализм в области SQL. В главе 8 описаны некоторые, наиболее простые методы профилирования активности SQL Server, обнаружения «узких» мест и последующего устранения проблем путем оптимизации кода SQL Server и изменения архитектуры базы данных, Глава 9; Оценка эффективности US-уровня посредством ТСА В главе 9 подробно рассказывается о методологии Microsoft для расчета стоимости транзакции (ТСА) Web-приложений. Значения ТСА необходимы для измерения возможностей Web-сайта по обслуживанию пользователей; они также позволяют оценивать изменения, внесенные в приложение с целью улучшения производительности. Глава Ю: Моделирование: инструменты прогноза производительности

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

XVIII

Введение

оценки производительности, о разных методах моделирования и случаях, в которых они применяются. Также приведен краткий обзор современных средств моделирования производительности и подробно рассматривается использование набора инструментальных средств (toolkit) на примере проекта Microsoft Indy.

Поддержка Мы приложили максимум усилий, чтобы устранить все возможные неточности з книге и на прилагаемом к ней компакт-диске. Однако от ошибок никто не застрахован, поэтому Microsoft Press выделил для замеченных опечаток специальную страницу: http://www.microsoft.com/mspress/support/ Получить доступ к Microsoft Press Knowledge Base и отправить запрос по возникшей у вас проблеме можно по адресу: http://www.rnicrosoft.com/mspress/support/search.asp Если у вас есть замечания, вопросы или идеи относительно данной книги или прилагаемого компакт-диска, просим направлять их в Microsoft Press одним из следующих способов: Обычная почта: Microsoft Press Attn: Performance Testing Microsoft .NET Web Applications Editor One Microsoft Way Redmond, WA 98052-6399 Электронная почта: MSPINPUT@MICROSOFT.COM Пожалуйста, обратите внимание, что поддержка продуктов по указанным выше адресам не оказывается. Информацию о поддержке можно получить на Web-сайте Microsoft Product Support: http://support.microsoft.com

Глава 1

Теперь, когда стратегия .NET компании Microsoft позволила получить унифицированный способ связи с информацией, устройствами и людьми, включение в традиционные настольные приложения Web-поддержки становится не опцией, а требованием. Пользователям понадобится доступ к своим офисным приложениям с любого подключенного к Интернету устройства, будь то браузер настольного компьютера, устройство PDA (Personal Digital Assistant) или телефон с поддержкой WAP (Wireless Application Protocol). И чтоб реализовать такую возможность, разработчикам придется приложить массу усилий. К Web-приложениям будут предъявляться те же требования по производительности, надежности и расширяемости, что и к их настольным аналогам. Больше внимания будет уделяться тестированию и настройке производительности на протяжении всего цикла разработки программ по мере выявления различных факторов, влияющих на производительность.

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

Глава 1

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

Реальный пример — пиковый сетевой трафик Поток новостей об атаке на Всемирный торговый центр и Пентагон 11 сентября 2001 года привел к троекратному увеличению трафика Web-сайта новостей Microsoft. В последующие дни он не уменьшился, так как сохранялся интерес общества к этом событию. В результате время загрузки страниц с этого сайта увеличилось до неприемлемого уровня, а Web-серверы приходилось перезагружать каждые два часа из-за критического падения обьема доступной памяти. Позже было установлено, что в результате роста трафика резко увеличились уточки памяти, которая имела место на этом сайте и ранее, Описанная в этой книге методология позволяет заранее протестировать и, следовательно, предотвратить неприемлемое снижение производительности Web-сайта даже в случае внезапных всплесков трафика, вызванных . экстраординарными событиями наподобие тех, что имели место 11 сентября 2001 года. , Возникает вопрос; «Каким образом решается задача точного тестирования производительности и настройки Web-hpu- . , ложения?» К сожалению, на данный вопрос нет единственI; ного правильного ответа. Подобнае методологии постоянно развиваются, чему способствует возникновение новых ;; средств, позволяющих получить более точные результаты. Для простого Web-сайта иногда достаточно набора сценариев статических нагрузок, тогда как для сложного сайта 1 электронной коммерции точное предсказание реакции приI лаже»ия в условиях больших нагрузок невозможно без инструментов моделирования производительности и сценариев динамических нагрузок. Так как приемлемая производительность Web-сайта зависит от используемого приложения ; и архитектуры, анализ производительности Web-сайтое

Основы анализа производительности

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

Эффекты старых и новых технологий Хотя данная книга в основном посвящена тестированию производительности приложений, построенных на основе Microsoft .NET Framework, описанная методология обладает также обратной совместимостью с приложениями Windows DMA (Windows Distributed interNet applications Architecture). Так как на момент издания этой книги основная часть пользователей еще не успеет перейти на .NET и no-прежнему будет применять традиционные Web-приложения на основе ASP, мы представляем методологию анализа производительности, которая годится как для Webсервисов .NET, так и для Web-приложен и и Windows DNA. Там где нужно, для приложений Windows DNA мы покажем специальные способы. «Изюминка» методологии — определение критических метрик производительности, таких, как время отклика, пропускная способность и масштабируемость. Как показано в следующем примере, задание требуемых параметров производительности на этапе планирования определяет критические точки в процессе тестирования производительности.

Реальный пример — параметры производительности сайта Для Интернет-сайтов электронной коммерции Microsoft мы определяем максимальную пропускную способность для отдельных сценариев поведения пользователя, например просмотра товаров, добавлений товаров в корзину и заказа то•'= sapoe. Мы тестируем производительность и для каждого • сценария по отдельности, и при выполнении так-называв .; мого «смешанного теста». 8 первом случае определяется максимальная масштабируемость для каждого отдельного сценарий, когда серверы больше нучем не занять*. Второй .'• пример (смешанный тест) более точно моделирует происходящее на реальном сайте при различных уровнях активное- ;| см. след. стр.

Глава 1

ти, назначаемых разным типам транзакции. Определение максимальной пропускной способности сайтов электронной коммерции Microsoft напрямую зависит -от минимальных! - : целевых параметров производительности. Например, когда ' 5 сайт оформляет по 10 пользовательских заказов 8 секунду, любая страница должна загружаться за 10 секунд, средняя загрузка процессоров на серверах не должна превышать. 70%, а объем доступной памяти весь период тестирования должен оставаться стабильным. Если время выдачи страну- ... цы возрастает при более высокой загрузке до 11 секунд, то производительность сайта считается неприемлемой, В этот \: момент следует определить, чем вызвано неприемлемое : . время,отклика. Таким образом, целевые параметры производительности, установленные в фазе планирования, опре,; 'делают критические точки во время фазы тестирования производительности. Когда планирование параметров производительности завершено, определяются способы использования программных инструментов моделирования нагрузки для доведения Web-приложений до их критических точек производительности. Задача фазы тестирования — выявление реальных пределов производительности Web-приложения. И, наконец, наша методика позволяет исследовать все уровни приложения с помощью эффективных приемов анализа для идентификации «узких» мест и формулирования предложений по повышению производительности.

Что такое .NET Эта книга посвящена тестированию производительности приложений для .NET, и многие из приводимых в ней примеров написаны с помощью .NET Framework, поэтому сначала необходимо рассказать о том, что же такое .NET. Наш опыт доказывает, что без глубоких знаний технологий, используемых приложением, эффективное тестирование производительности крайне затруднительно, если вообще возможно. Однако материал этой книги можно считать лишь введением в Microsoft .NET. Более подробная информация о перспективах .NET опубликована на http:// www.rnicrosoft.com/net.

Основы анализа производительности

Платформа .NET Что такое .NET? Или no-друеому: какие сервисы составляют платформу .NET? Платформа .NET — это набор средств разработки и операционных сред, используемых для создания, предоставления и использования Web-сервисов XML, что делает возможным создание персонализированной, интегрированной Web-среды, доступной посредством интеллектуальных устройств и базирующейся на открытых стандартах. Ниже перечислены основные компоненты платформы .NET, •

.NET Framework — это среда для создания, развертывания и исполнения Web-сервисов XML и других приложений. Она состоит из двух частей: общеязыковой исполняющей среды (common language runtime, CLR) и библиотек классов, включающих ASP.NET, Enterprise Services, ADO.NET и Windows Forms.

• Visual Studio .NET — полнофункциональная среда разработки приложений для платформы Microsoft .NET. • Mobile Internet Toolkit — это набор программных интерфейсов для обмена информацией с мобильными устройствами типа PDA и смартфонов, а также серверная инфраструктура. • Серверы .NET Enterprise включают Application Center 2000, BizTalk Server 2000, Commerce Server 2000, Exchange Server 2000, Internet Security and Acceleration Server, Host Integration Server 2000, Mobile Information Server 2001 и SQL Server 2000. •

.NET-сервисы — это набор базовых Web-сервисов XML, которые будут поставляться Microsoft; однако Web-сервисы XML может создавать кто угодно.

На рис. 1 -1 показано, как основные компоненты платформы .NET взаимодействуют друг с другом, обеспечивая доступ пользователей к приложениям из любого места и с любого устройства. Разработчики могут применять .NET Framework для создания Web-сервисов. CLR — это механизм, позволяющий исполнять управляемый код. С его помощью разработчики Web-сервисов интегрируют и исполняют код, написанный на разных языках программирования. Web-сервисы, созданные на основе .NET Framework, исполняются на серверах .NET Enterprise и доступны в любое время, из любого места и с помощью любых устройств.

Глава 1

.NET Framework

; •

Python

Web-сервисы Win Forms ASP.NET Библиотеки классов (ADO.NET, Библиотеки базовых классов Общеязыкова« исполняющая среда Серверы .NET Enterpise

Windows 2000 (Server, Advanced Server, Datacenter Server) Доступ ил любого места, посредством любого устройства

П1

Рис. 1-1. Базовые компоненты платформы .NET Реальный пример — служба планирования согласованной работы нескольких фирм на основе .Net Допустим, еы летите домой и, чтоб не терять времени в полете, решили заняться планированием соеещания с поставщиками, назначив его на завтрашнее утро. Поскольку поставщики не имеют доступа к системе планирований вашей фирмы, вы не можете просмотреть их расписания и отправить запрос на проеедение совещания. Кроме того, во еремя полета Интернет доступен только посредством мобильного телефона или беспроводного PDA. Однако, если

Основы анализа производительности системы планирования как зашей фирмы, так и фирм-по! ставщиков построены на основе Web-сервисов XML и про- = : ; граммных интерфейсов из Mobile Internet Toolkit, то вам • удастся не только просмотреть расписание ваших поставщиков, но и послать запрос на проведение совещания с помощью беспроводного PDA или мобильного телефона благодаря различным интерфейсам программ ирозания мобиль-.. ных устройств. 8 .NET это возможно, потому что системы планирования вашей фирмы и фирм-поставщиков теперь '! \*,- совместимы (т. е. интегрированы посредством различных .. .; программных интерфейсов), а Web-сервисы планирования - : ; расписаний позволяют вам назначить совещание с помощью любого устройства. Многие Web-сайты уже сегодня предлагают аналогичные возможности, но все они используют собсгаенные решения, не всегда совместисые друг с другом.

Стандартные протоколы .NET Тот факт, что в основе .NET лежат открытые Интернет-стандарты, делает .NET Framework расширяемой и позволяет легко взаимодействовать с другими решениями, построенными или не построенными на основе Web. Основными стандартами, используемыми .NET для поддержки Web-сервисов, считаются: • XML (Extensible Markup Language — расширяемый язык разметки); • SOAP (Simple Object Access Protocol — простой протокол доступа к объектам); • HTTP (Hypertext Transfer Protocol — протокол пересылки гипертекста). XML — текстовый язык, который очень похож на повсеместно распространенный HTML; он позволяет определять новые HTMLподобные теги, описывающие как структуру документа (метаданные), так и содержимое (данные). XML потребовался .NET из-за присущих HTML врожденных проблем. Существуют противоречащие друг другу стандарты HTML, из-за чего разные браузеры обрабатывают одни и те же теги no-разному. Это означает, что Web-дизайнерам приходится создавать для разных браузеров разные версии одного HTML-документа. До настоящего време-

Глава 1

ни усилия по созданию международных стандартов HTML не увенчались успехом. Кроме того, HTML обладает неадекватной системой ссылок. Ссылки HTML жестко зашиваются в документы и при изменении любой из них необходимо отыскать и изменить все ее вхождения. XML позволяет связывать ссылки с любым элементом и создавать ссылку, указывающею на несколько мест сразу, и это эффективный способ преодоления ограничений HTML. .NET также использует новейший XML-стандарт, ранее известный под названием SDL (Service Description Language), а теперь WSDL (Web Services Description Language — язык описания Webсервисов). Как следует из названия, WSDL предназначен для описания Web-сервиса. Он применяется для создания или генерации файла .wsdl, который требуется другим сервисам для определения функциональных возможностей, предоставляемых данным Web-сервисом. Протокол SOAP считается базовым форматом передачи команд и данных между объектами и приложениями. Близкий по функциональным возможностям к RFC (Remote Procedure Call — удаленный вызов процедуры), SOAP использует XML для описания передаваемой информации. XML делает SOAP простым, доступным для восприятия человеку, открытым и расширяемым.

Спецификация UDDI .NET также использует возможности спецификации UDDI (llniversal Description, Discovery u Integration — универсальное описание, поиск и интеграция), которая описывает создание реестров Web-сервисов. Помещая в такие реестры информацию о предоставляемых Web-сервисах, а также другие данные, компании облегчают их поиск всем желающим. INIM (Internet Native Integration Methodology — методология естественной интеграции для Интернета) обеспечивает возможность XML-взаимодействия между системами и открытый набор стандартов. INIM работает с любой ОС, моделью программирования или сетью и обеспечивает доступ к существующему коду как к Web-сервису, что позволяет разным системам взаимодействовать друг с другом.

Основы анализа производительности

Спецификация UDD! определяет стандарт публикации и поиска информации о Web-сервисах.

Что такое Web-сервис XML Современные Интернет-сервисы — это, в основном, порталы, предоставляющие услуги, которыми нельзя воспользоваться откуда-либо еще, Одно из неудобств подобных сервисов — сложность обмена информацией между компаниями. В частности, даже контактную и другую личную информацию приходится на каждом таком сайте вводить заново. Web-сервисы — это фрагменты приложений, предоставляющие данные и услуги другим приложениям и пользователям. Примером Web-сервиса может служить Microsoft .NET Passport, предоставляющий средства аутентификации. Приложения обращаются к Web-сервисам посредством стандартных Web-протоколов и форматов данных (т. е. HTTP, XML и SOAP) независимо от способа реализации данного Web-сервиса. В Web-сервисах, представляющих собой краеугольный камень программной модели Microsoft .NET, объединены преимущества разработки с использованием компонентов и Web. Web-сервисы XML превращают Web-сайты, доступные ранее только для просмотра, в вычислительные узлы, которые способны сами предоставлять методы, а также вызывать методы других Web-сервисов. Использование XML. обеспечивает обмен данными между любыми ОС и сетями посредством сервисов XML и SOAP, которые связывают ранее несовместимые или несхожие друг с другом системы (например, удается обеспечить доступ к приложению, исполняющемуся на компьютере Macintosh, Unix или Linux, посредством устройства на базе Windows СЕ). Web-сервисы -— это программные решения, доступные через Интернет любому устройству, поддерживающему Web. На сегодня таким устройством является Web-браузер на вашем компьютере, однако независимая от устройств архитектура .NET устранит данное ограничение. XML — это промышленный стандарт, и в настоящее время он поддерживается во всех продуктах Microsoft, включая последнее поколение серверов. .NET Framework встроена во все продукты .NET — Microsoft Visual Basic .NET, Microsoft Visual C++ и Microsoft Visual C#.

Глава 1

Реальный пример — Microsoft .NET Passport На платформе .NET предусмотрено создание таких Web-cepвисоз, как адресная книга, словарь или энциклопедия. Возьмем, к примеру, Microsoft *N£T Passport — один из де. сяти крупнейших Web-сайтов в мире,, насчитывающий более 160 миллионов активных учетных записей, число которых растет со скоростью более 10 миллионов в месяц. Хотя .NET Passport получает более 1,5 миллиардов аутентификационных запросов ежемесячно, сам Web-сайт посещается редко, так как это Web-сервис XML.

Необходимость Web-сервисов для поддержки новых типов устройств Устройствам, поддерживающим работу с Web, требуются сервисы, предоставляемые платформой .NET. На сегодняшний день их уже достаточно много. Все они мобильны, малы, интеллектуальны и способны взаимодействовать друг с другом. Как известно, пользователям нужна информация из множества разных источников, и причем немедленно. Приложения, поставляющие информацию в любое время и в любом месте, должны работать на разных клиентских платформах, значительно различающихся по возможностям. Перспективы, которые открывает XML-ориентированная программная модель .NET, иллюстрирует следующий пример.

Реальный пример — приготовь свою джакузи заранее Представьте себе, что- вы возвращаетесь домой после долгого перелета. Вы мечтаете, чтобы вода в джакузи к сзашему приходу была нагрета до нужной температуры. Благода^ ря .НЕТ Web-сервисам, этот футуристический сценарий легко осуществим, если термостат вашер джакузи использует Web-сероисы. По заранее заложенному алгоритму данный : компонент Web-сервисов выясняет время вашего прилета-:»: := и определяет время поездки из аэропорта домой, основы: ваясь 'наганных о текущей дорожной обстановке. Это возможно благодаря .NET, так как ваша домашняя сеть сможет

Основы анализа производительности

в реальном времени получать информацию о прибывающих =•; рейсах в стандартном XML-формате. Уже существует холодильник со встроенным интеллектуальным устройством, оснащенным считывателем штрих-кода. Это устройство способно автоматически заказывать продукты в супермаркете через заданные пользователем интервалы. Традиционные платформы и среды разработки с «зашитыми» решениями на это не способны.

Необходимость Web-сервисов для тестирования Web-производительности Радикальное изменение способов доставки информации устройствам требует новых методов тестирования и настройки производительности приложений. Подобно тому как традиционные платформы не успевают за современными технологиями, традиционные методологии функционального тестирования не в состоянии адекватно определить производительность приложения и выявить «узкие» места в новых .NET-приложениях. В мире .NET необходим новый подход к традиционному циклу разработки программного обеспечения, включающий постоянное эффективное тестирование производительности. Основной мотив написания данной книги — желание познакомить вас с этими новыми требованиями.

Целевые показатели производительности Исходя из общих представлений о Web-сервисах на основе .NET, которое вы получили , прочитав предыдущие разделы, становится очевидной огромная важность быстрого доступа к этим сервисам различных устройств в любое время и в любом месте. Производительность можно рассматривать с разных сторон, но наиболее важной с точки зрения группы АСЕ является увеличение производительности путем сокращения «узких» мест, увеличивающих время ожидания пользователя. Снижение времени ожидания пользователя — наша основная цель, так как это единственная метрика производительности, с которой пользователи имеют дело непосредственно. Масштабируемость и готовность (availability) как важные условия достижения оптимального времени отклика будут рассмотрены весьма подробно. Их значи-

Глава 1

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

Поведение пользователей при взаимодействии с компьютером Несмотря на то, что Интернет стал достоянием широкой публики лишь в последнее десятилетие, исследования времени отклика при взаимодействии с компьютерами проводились с момента появления последних. В статье «Response Time In Man-Computer Conversational Transactions», написанной Миллером (R.B. Miller) в 1968 году для осенней конференции AFIPS (AFIPS Fall Joint Computer Conference, Vol. 33, 267-277), перечислены возможные варианты поведения пользователя з зависимости от времени отклика компьютера: • 0,1 секунды — это предел, до которого пользователь считает, что система реагирует на его действия мгновенно, то есть кроме отображения результатов никакой другой обратной связи не требуется; • 1,0 секунда — если время отклика не превышает это значение, поведение пользователя не меняется, хотя он и замечает задержку; обычно, при задержке в интервале от 0,1 до 1 секунды дополнительная обратная связь не нужна, хотя у пользователя и теряется ощущение неопосредованной работы с данными; • 10 секунд — это предельное значение, когда внимание пользователя еще сосредоточено на экране; если оно превышено, пользователи отвлекаются на другие дела в ожидании, пока компьютер не закончит процесс, поэтому необходима обратная связь, информирующая, сколько осталось времени до его завершения. При подобных задержках обратная связь особенно важна, если время отклика сильно варьируется, так как при этом пользователь не знает, чего ему ожидать. При измерении времени отклика иногда выясняется, что главная причина большой задержки вам неподконтрольна, и потому уло-

Основы анализа производительности

житься в ограничение 0,1 секунды невозможно. Например, мало что можно поделать с перегрузками Интернета или с медленной телефонной линией, используемой клиентом для доступа в Сеть. Тем не менее все-таки стоит попытаться понять основную причину большого времени отклика, чтобы повлиять на него всеми возможными способами. Задача данной книги — познакомить вас с надежной методологией определения этой причины, известной также под именем ((узкое» место (bottleneck), и исправления ее. Мы надеемся, что поможем вам добиться субсекундных времен отклика .NET-приложения при условии интеграции в цикл разработки надлежащих методов тестирования и настройки.

Тестирование производительности вашего приложения С ростом объемов использования Web-сервисов, что приводит к еще большему увеличению трафика, основной проблемой становится обеспечение гарантированной оптимальной производительности приложения. Мы предлагаем решение этой проблемы на основе продуманного подхода к определению следующих ключевых факторов, влияющих на производительность: •

максимальной масштабируемости;

• средних времен отклика под нагрузкой; •

«узких» мест, мешающих росту производительности.

Все это позволит устранить «узкие» места и достичь оптимальной производительности. Кроме того, 8 книге показан альтернативный подход оценки возможностей Web-приложения по методологии, разработанной Microsof, — ТСА (Transaction Cost Analysis — анализ стоимости транзакции). Методология ТСА позволяет оценить будущие ресурсные потребности Web-приложений путем связывания стоимостей серверных ресурсов, таких, как процессор, со стоимостями типичных пользовательских операций. Это поможет оценить потенциальный рост нагрузки на сайт и подготовиться к ней заранее, до того как крупные перемены на рынке или в окружающем мире вызовут пиковый трафик. Схематично, «с высоты птичьего полета», цикл тестирования производительности состоит из:

Глава 1

•

планирования анализа производительности;

•

создания эффективных нагрузочных сценариев;

•

выполнения нагрузочных сценариев;

• анализа собранных данных для определения и устранения «узких» мест. Каждый из этих этапов подробно обсуждается в следующих глазах. Еще раз обращаем ваше внимание на то, что анализ производительности требует глубоко продуманного подхода в сочетании с опытом и знаниями в области используемых технологий, Схема анализа производительности, описанного в этой книге, показана на рис. 1-2. Планирование Создание среды тестирования Определение критических метрик производительности Определение граничных значений метрик Создание профиля использования сайта

2. Создание сценариев и выполнение нагрузочных тестов • Создание динамических сценариев • Проверка функциональности сценариев • Настройка Microsoft Performance Monitor 1 Тесты «на задымление» для эффективного моделирования загрузки сайта • Исполнение тестов п рои зводительности 3. Анализ и настройка • Анализ производительности сети • Лнализ производительности ASP.NET • Анализ производительности управляемого кода • Анализ производительности SQL • Анализ стоимости транзакции (планирование возможностей]

Рис. 1-2. Наша методология анализа производительности

Основы анализа производительности

Планирование анализа производительности На этом этапе собирается ключевая предварительная информация, позволяющая структурировать и планировать тесты. Данные должны содержать как минимум два элемента: 1) детали, необходимые для максимально точного воспроизведения реальной среды, G которой будет работать приложение, и 2) схему использования приложения, включая индикацию критических проблем производительности. Информацию собирают на основе публикаций о прогнозах развития рынка, рабочих журналов 115, рабочих журналов производительности, а также функциональных спецификаций приложения. Качество данных о производительности, собранных перед проведением самих тестов, критически важно. Они позволяют определить требования к тестовой среде и понадобятся на всех этапах анализа, от развертывания тестовой среды до разбора результатов тестов. Подробно о планировании рассказано в главе 2.

Создание эффективных нагрузочных сценариев После сбора необходимой информации и подготовки среды тестирования необходимо написать нагрузочные сценарии, точно моделирующие реальный ожидаемый трафик. Для этого данные следует собирать на реально функционирующем сайте, сочетая их с прогнозами, полученными от аналитиков рынка или бизнесаналитиков. Создание надежных нагрузочных сценариев с помощью Microsoft Application Center Test (ACT) рассматривается в главе 3.

Исполнение нагрузочных сценариев После создания сценариев, моделирующих пиковые нагрузки, проводят нагрузочное тестирование. На этом этапе важно проверить функциональность сценариев, чтобы удостовериться, что они максимально точно моделируют реальный трафик, так как качество нагрузочного теста напрямую связано с качеством сценариев. Кроме того, перед выполнением собственно нагрузочных тестов, генерирующих показатели производительности, которые будут использоваться для определения «узких» мест, необходимо определить оптимальную нагрузку с использованием методологии, которую мы назвали тестом на задымление (smoke test).

Глава 1

Особенности нагрузочного тестирования, включая ключевые цели тестов на задымление, описаны в главе 3.

Анализ результатов измерения производительности Фаза анализа начинается после того, как выполнены нагрузочные тесты и собраны их результаты. Сначала необходимо убедиться в том, что нагрузочный тест прошел успешно, так как качество данных не может быть лучше, чем качество теста. Этап анализа наиболее технически сложный, поэтому наличие качественных исходных данных критически важно для получения достоверных результатов и выводов. На данный этап следует выделить большую часть времени, отведенного на анализ производительности. Именно по этой причине анализу посвящены три главы книги. В главе 6 описана методология анализа производительности Web-уровня. В главе 7 — способы профилирования управляемого кода. И наконец, глава 8 посвящена методам определения «узких» мест на уровне данных или SQL-уровне. Опыт показывает, что на SQL-уровне очень часто возникают «узкие» места, если код не был надлежащим образом спроектирован и настроен. «Узкие» места на SQL-уровне наиболее опасны, так как масштабирование баз данных посредством кластеризации сложнее, чем возможные приемы масштабирования на Web-уровне. Конечно, написаны книги, целиком посвященные каждой из этих технологий. Основная наша цель -— эффективное выявление «узких» мест и предложение способов настройки для достижения максимальной производительности, Выявление «узких» мест К «узким» местам, влияющим на время ожидания пользователя, относятся; пропускная способность приложения и сервера, скорость соединения по Интернету и перегрузки в Интернете. Пропускная способность сервера (скорость обработки им клиентских запросов) не представляет проблему, так как аппаратные средства легко доступны и дешевы по сравнению со средствами, расходуемыми на разработку сайта. Пропускную способность сети при условии адекватного мониторинга текущей сетевой загрузки так же, как и серверные аппаратные средства, легко увеличить до того, как трафик превзойдет текущие возможности. Хотя соединение пользователя с Интернетом в техническом плане дос-

Основы анализа производительности

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

Глава 1

емов тестирования производительности пропускную способность приложения удается точно предсказать, что позволяет администраторам сайта подготовиться к наихудшим вариантам развития ситуации. Проверка результатов настройки производительности Окончательный этап анализа производительности — в ясной форме донести результаты нагрузочного тестирования до разработчиков приложения. Это следует делать таким способом, который позволит им оценить и повысить производительность приложения на основании результатов анализа. Доказательное тестирование (повторное исполнение нагрузочных тестов после анализа и настройки и сравнение новых результатов с предыдущими) считается наиболее эффективным способом отражения результатов настройки производительности. Одних лишь предположений о том, что ваши усилия по настройке повысили производительность, недостаточно; это должно быть объективно и убедительно доказано! Уменьшилось ли время отклика, возросла ли масштабируемость? Удалось ли значительно сократить ресурсы сервера, требуемые для обслуживания того же уровня клиентских запросов? Вот вопросы, на которые должен ответить квалифицированный анализ производительности,

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

Глава 2

Зачастую Web-приложения не соответствуют потребностям и ожиданиям пользователей. Потребители быстро разочаровываются в Web-приложении, которое постоянно выдает ошибки, медленно отвечает на запросы или часто недоступно. Таким образом, успех начальной «раскрутки» Web-приложения будет в значительной степени сведен «на нет», если нет продуманной и правильно спланированной процедуры или методологии тестирования. В этой главе описаны ключевые моменты планирования, которые необходимо предусмотреть прежде, чем проводить сами тесты. Следуя этой методике, вы получите дополнительные выгоды за счет повышения эффективности тестов производительности. Итак, вам необходимо определить целевые показатели производительности, создать профили активности пользователей, а также определить при составлении плана тестирования ключевые метрики, подлежащие контролю и анализу.

ПРИМЕЧАНИЕ Известно, что многие проекты потерпели неудачу, потому что тестирование откладывали на заключительные этапы цикла разработки Web-приложения либо выдвигали слишком сложные требования, которые нельзя выполнить за отведен-

Глава 2

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

Определение целевых параметров производительности Установить требования к основным параметрам производительности абсолютно необходимо — это гарантирует, что ваше Webприложение удовлетворит текущее и даже будущие проектные требования. Наилучший подход — использовать накопленные исторические данные или результаты обширных маркетинговых исследований. Плохо спланированы, например, те Интернет-магазины, которые не з состоянии справиться с предпраздничным покупательским ажиотажем. Каждый год в прессе появляются сообщения о таких магазинах, которые не в состоянии доставить все заказы, медленно обрабатывают команды пользователей, выдают сообщения об ошибках Web-сервера или вовсе прекращают работу из-за системных сбоев. Все это не только снижает объемы продаж, но и вызывает плохие отклики в прессе. Главные требования к параметрам производительности можно разделить на три основные категории: • допустимое время отклика; • пропускная способность и число одновременных пользователей; • требования к будущему росту производительности.

Допустимое время отклика Определив, как и когда пользователи будут связываться с вашим Web-приложением, вы можете построить таблицу, аналогичную табл. 2-1, где показаны скорости соединения и задержки на линиях связи для потенциальных пользователей. Это поможет вам определить приемлемое время загрузки каждой страницы приложения. Установив, каким образом пользователи будут получать доступ к Web-приложению, вы можете определить целевые параметры

Подготовка и планирование тестирования

допустимого времени отклика. Они задают максимально приемлемую продолжительность обработки пользовательских команд или загрузки содержимого для разных типов соединения. Например, при прочих разных условиях 70-килобайтная страница, безусловно, быстрее загрузится по линии DSL со скоростью 256 кбит/с, чем по модему (28,8 кбит/с). Допустимым временем отклика при использовании модема считается 15 секунд, тогда как для линии DSL оно будет значительно меньше, около 5 секунд. Параметры допустимого времени отклика полезны при анализе сетевых параметров приложения, который подробно рассматривается в главе 5. Задача такого анализа — получение прогнозов времени отклика при различных скоростях соединения и задержках, определение объемов данных, проходящих через каждый из уровней приложения, а также числа сетевых обменов на каждом этапе сценария активности пользователя. В отсутствие накопленных данных или предположений о скоростях соединения, которые будут доступны потенциальным пользователям, мы рекомендуем ориентироваться на наихудший случай. В табл. 2-1 показаны возможные скорости связи с Интернетом конечных пользователей в наихудшем, среднем и лучшем случаях. Табл. 2-1.

Ожидаемые скорости соединения

Пользователь Худший случай Скорость Задержка

Средний случай

Лучший случай

Модем (28,!1 кбит/с) DSL (256 кбит/с) 1 00 мс 1 000 мс

Т1 (1,5 Мбит/с) 50 мс

Пропускная способность и число одновременных пользователей Чтобы определить параметры пропускной способности и число одновременно обслуживаемых пользователей, ответьте на следующие вопросы: • каково текущее или ожидаемое число одновременно обслуживаемых пользователей в заданный период времени; •

какие действия выполняет типичный пользователь вашего приложения и к каким страницам пользователи обращаются чаще всего в заданный период времени;

•

сколько сценариев активности пользователей обработает Web-приложение за указанный интервал времени?

Глава 2

Наилучший источник такой информации — данные, которые хранятся в файлах журналов Web-сервера, данные System Monitor и те, которые удается определить при мониторинге активности БД. При создании совершенно нового Web-приложения для определения ожидаемых требований пропускной способности и числа одновременных пользователей могут понадобиться маркетинговые исследования. Показатели, полученные двумя этими способами, гарантируют надлежащие уровни параллельной нагрузки при проведении тестов. Если в результате тестов оказывается, что Web-приложение удовлетворяет вашим требованиям по производительности и числу одновременных пользователей, зы можете увеличивать нагрузку до тех пор, пока либо не наткнетесь на «узкое» место, либо не будет достигнута максимально возможная пропускная способность. В табл. 2-2 показаны прогнозируемые параметры производительности и профили одновременно обслуживаемых пользовательских сценариев для примера Web-приложения IBuySpy. На основании данных таблицы можно создать тестовый сценарий, моделирующий предполагаемую загрузку данного Web-приложения. В столбце «Доля» показан процент частоты выполнения данной пользовательской операции по отношению ко всем операциям. Предполагаемое количество за час вычислено на основе данных за определенный период времени, взятых из журналов (они приведены в следующем разделе), оно показывает, сколько раз данная операция выполняется а среднем в течение часа. Табл. 2-2. Целевые параметры пропускной способности и числа одновременных пользователей Действия пользователя

Доля, %

Поиск Выбор товара Добавление в корзину Bxoq в систему Регистрация Всего

6 •

Предполагаемое количество за час 1 400 6 200 1 000 i

7 100

10 000

Подготовка и планирование тестирования

Анализ потенциального роста производительности Анализ роста производительности необходим, если в будущем вы ожидаете увеличение числа пользователей вашего приложения. При тестировании производительности необходимо учитывать рост числа пользователей. Тестирование производительности и устранение связанных с ней проблем на этапе, когда разработка приложения уже завершена, потребует больше времени и средств, чем во время цикла разработки (ЦР). В реальном примере из главы 1 расходы на поиск и устранение проблем Webприложения по окончании ЦР состоят из: упущенной прибыли изза плохих отзывов в прессе, упущенных пользователей, которые не захотели ждать медленной загрузки страниц, а также трудозатрат на тестирование и разработку, связанных с поиском ошибки и ее исправлением. Требуется немного времени на загрузку в базу дополнительных данных при тестировании производительности, однако это позволит убедиться в работоспособности системы при больших нагрузках и сэкономит ваши деньги в будущем, Кроме того, для прогнозирования будущих «узких» мест следует провести тест с уровнями загрузки и количеством одновременных пользователей, превышающими ожидаемые. Если вы выявите проблемы на ранних этапах жизни своего приложения, вам не придется тестировать и настраивать его производительность в ближайшем будущем, кроме того, впечатление пользователей о нем окажется значительно лучше.

СОВЕТ Создав тестовую БД, содержащую дополнительные заказы, корзины и пр., перед выполнением собственно тестов производительности необходимо «погонять» ваши тестовые сценарии некоторое время (возможно, несколько дней}. Пользовательский интерфейс вашего Web-приложения гарантирует правильный ввод данных в систему. Самым быстрым способом генерации тестовой базы считается использование для этой цели SQL-сценариев, написанных разработчиком. В этом случае можно по ошибке забыть некоторые таблицы, обновляемые через пользовательский интерфейс Web-приложения. Однако главное — убедиться в том, что тесто-

Глава 2

зал база сгенерирована правильно, в противном случае вы получите неточные результаты тестов. Проще всего определить требуемый рост производительности вашего Web-приложения, рассчитав прирост загрузки за заданный период времени. Допустим, количество ваших пользователей растет на 10% в месяц. В табл. 2-3 показан планируемый рост, который можно использовать при проведении нагрузочного тестирования. Здесь предполагается, что в настоящий момент с Web-приложением работает 10 000 пользователей в день и ожидаемый прирост составляет 10% в месяц. При расчете прироста не забудьте учесть последствия рекламных акций, в результате которых трафик вашего приложения может увеличиться. Табл. 2-3. Ожидаемый прирост нагрузки Период времени

Пользователей в день

Сейчас

10 000

Через 3 месяца

13 310

Через 6 месяцев

16 104

Через 9 месяцев

21 434

Через 12 месяцев

28 529

Профиль активности пользователей Для создания профилей активности пользователей мы обратились к журналам IIS. Это текстовые файлы, содержащие информацию о каждом запросе; их можно просмотреть обычным текстовым редактором или импортировать в программу анализа журналов. Для получения адекватных средних результатов мы рекомендуем использовать набор журналов по крайней мере за неделю. Чем больше журналов задействовано, тем более реальные профили пользователей вы получите. Для иллюстрации процесса создания профиля активности пользователя мы импортировали данные журналов IIS за месяц, полученные в процессе недавнего анализа типичного Web-приложения электронной коммерции, в одну из программ анализа журналов. Эти журналы содержат информацию о просмотрах пользователями страниц, связанных с операциями «Вход на начальную страницу», «Поиск», «Выбор товара», «Добавление в корзину» и «Заказ». Табл. 2-4 мы

Подготовка и планирование тестирования

создали с помощью анализатора журнала. В настоящий момент доступно множество коммерческих анализаторов журналов — для любого бюджета. Эти анализаторы способны импортировать, выделить и отобразить типовые образцы трафика Web-приложенгия. Табл. 2-4. Профиль активности пользователей Операция/ название страницы

Число просмотров страницы

Доля, %

Начальная страница default.aspx Поиск search. aspx Выбор товара productfeatures.aspx productoverview.aspx Добавление в корзину basket, aspx Заказ checkout, aspx checkoutsubmit.aspx confirmation. aspx

720 000

Всего

720 000

90 000 90 000

450 000 216 000 234 000

360 000

'(]

360 000 180 000 90 000

. 12 13 !0

54 000 36 000

1 800 000

100

Необходимо понимать различие между обращением и просмотром страницы. Обращение (hit) определяется как запрос к любому отдельному объекту или файлу Web-приложения, тогда как просмотр страницы — запрос на выборку и пересылку страницы HTML, ASP или ASP.NET, содержащей ссылки на дополнительные элементы. Страница — это то, что вы видите по окончании пересылки, она может содержать много других файлов. Просмотры страницы не включают обращения к картинкам, страницамкомпонентам фрейма или к файлам формата, отличного от HTML.

СОВЕТ Для простоты не учитывайте при создании профиля активности пользователей пересылку картинок и другие подобные запросы. Кроме того, не учитывайте действия инструментов мониторинга,

Глава 2

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

Профиль активности сервера Профиль активности сервера fbackend activity profile) требуется для учета пользовательской активности и «узких» мест в Webприложении на уровне базы данных. Такая информация позволяет убедиться в том, что ваши тесты производительности точны.

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

Выявление «узких» мест в серверной части приложения При тестировании производительности существующего Webприложения удается выявить текущие «узкие» места, инициируя такие запросы к серверу БД, которые долго обрабатываются, вызывают взаимоблокировки (deadlock) и занимают много ресурсов сервера. Процесс сбора этих данных выполняется на этапе планирования и подразумевает сбор трассировочных данных SQL с помощью SQL Profiler и журналов Performance Monitor, cogep-

Подготовка и планирование тестирования

жащих в случае типичного Web-приложения информацию об объектах Windows и SQL Server. Иными словами, время трассировки SQL должно приходится на тот период, когда производительность приложения из приемлемой становится плохой. Собранная информация даст вам более ясную картину причин возникновения «узких» мест. Процесс поиска источников проблем производительности на уровне БД рассматривается в главе 8. Это могут быть блокировки, взаимоблокировки, плохо составленные запросы или медленно работающие хранимые процедуры.

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

СОВЕТ Критическую точку в Web-приложении можно определять no-разному. Это может быть использование сервером ресурсов на уровнях, превосходящих заданные, слишком большое число ошибок сервера или неприемлемые времена отклика из-за задержек обработки. Ключевых метрик для теста производительности несколько. •

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

Глава 2

возрастает очень сильно и очень быстро, а также из-за незавершенных обращений к страницам. Такие ошибки вызваны самим тестом, поэтому их можно игнорировать, так как при реальной эксплуатации они вряд ли возникнут. • Допустимая загрузка сервера Это важный параметр тестирования производительности. Установив его с самого начала, вы сможете определить максимально допустимые уровни нагрузки, с которыми справятся ваши серверы. Данный параметр — основной для определения максимальной нагрузки на ваше Web-приложение во время тестов. Его величина различается для разных Web-приложений, ее следует описать и согласовать с группами сопровождения, разработки, тестирования и управления. Например, мы нагружаем Web-уровень до тех пор, пока не достигнем 75-процентной загрузки процессора. При этом каждый сервер обслуживает примерно 2 000 пользователей, что соответствует нашим требованиям по количеству одновременных пользователей. Если эти показатели задокументированы, то группа сопровождения сможет выполнять мониторинг Web-серверов, отслеживая пики, когда эта метрика производительности достигается или перекрывается. Тогда для поддержки увеличивающегося трафика группа сопровождения может принять меры по масштабированию Web-приложения. • Утечки памяти и другие проблемы стабильности Часто эти проблемы возникают при проведении усиленных тестов производительности. Например, при исполнении нагрузочного теста в течение краткого периода времени не удается выявить утечку памяти или другую проблему стабильности, так как она проявляется только после длительного периода больших нагрузок. Для решения разных задач тесты выполняются многократно. Например, для определения максимальной пропускной способности Web-приложения проводят короткий одночасовой тест, а затем запускают тест, работающий все выходные, чтобы определить, способно ли приложение выдерживать максимальную нагрузку длительное время. • Задержки обработки Они происходят практически в любом Web-приложении, где требуется программирование сложных бизнес-правил. Ваша задача — свести эти задержки к допус-

Подготовка и планирование тестирования

тимым значениям. Прежде чем начать тестирование, неплохо определиться с тем, какие значения допустимы, чтобы не тратить время на сообщение разработчикам о проблеме, которая таковой не является, так как соответствует целевым параметрам производительности. Примеры допустимых задержек обработки показаны в табл. 2-5. Это 500 миллисекунд на исполнение хранимой процедуры, а также не более чем секундные задержки при обработке Web-страницы (их значения получены по журналам работы Web-уровня). В табл. 2-5 показаны приемлемые метрики производительности. Ваши требования могут быть иными; основная задача — сформулировать набор требований, соответствующий вашему приложению. Табл. 2-5. Допустимые уровни метрик производительности Метрика

Откуда берется

Загрузка ЦП Свободная память Память (страниц в секунду) Время исполнения ASP Задержки в базе данных Задержки на Web-уровне

Performance Monitor Performance Monitor Performance Monitor Performance Monitor SQL Profiler Из журналов IIS

Допустимый уровень < 75%

> 1 28 Мбайт • 2

<1с < 500 мс <1с

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

СОВЕТ Многие «.узкие» места кода и архитектуры приложения удается выявить, даже когда использование при тестировании аппаратных средств, кото-

Глава 2

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

Составление плана тестирования производительности План тестирования производительности — это стратегия, или формальный прием, позволяющий всем, участвующим в создании Web-приложения, от разработчиков до тестеров и менеджеров, ясно представить себе, как, почему и какая часть приложения проходит тест на производительность. В плане тестирования выделяют следующие разделы. • Обзор приложения Здесь дается краткое описание назначения Web-приложения. Также иногда приводятся некоторые маркетинговые прогнозы или результаты анализа накопленных данных. • Обзор архитектуры Здесь описываются программные и аппаратные средства, используемые при тестировании производительности, в том числе указывается их отличия от реальной среды эксплуатации приложения. Например, следует пометить, что при реальной эксплуатации применяется Web-кластер из четырех серверов, тогда как при тестировании используются лишь два сервера. • Основные параметры В этом разделе описываются объекты тестирования Web-приложения. Примерами служат уровни пропускной способности и количество одновременных пользователей, а также максимально допустимые времена отклика. • Процесс тестирования производительности Здесь приводятся сценарии активности пользователей, перечисляются инструменты, необходимые для нагрузочного тестирования, а также все неочевидные моменты при реализации нагрузочных сценариев. Также поясняется, какие времена простоя или интервалы «раздумий пользователя» заложены в тестовые сценарии.

Подготовка и планирование тестирования

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

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

Глава 3

Задача нагрузочного тестирования — выявить и изолировать «узкие» места в Web-приложении в условиях нагрузки. Уменьшение числа «узких» мест или их устранение позволит вам добиться соответствия установленным требования по трафику или превзойти их. После выявления «узких» мест вы можете настроить Web-приложение и сервер таким образом, чтобы минимизировать время ожидания конечных пользователей и, значит, улучшить их впечатление от вашего приложения. Нагрузочное тестирование (stress testing) состоит в тестировании приложения под нагрузкой для определения максимальной пропускной способности. Пропускная способность (throughput) — это количество клиентских запросов, обрабатываемых за некий интервал времени. Нагрузочное тестирование часто также называют тестированием производительности, пиковым тестированием или тестированием Web-сервера. Важно отметить, что у каждого приложения свои требования к производительности.

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

Нагрузочное тестирование с помощью ACT

дорогостоящим, кроме того, придется затратить массу времени на организацию теста. Аппаратный метод не считается ни самым точным, ни самым эффективным способом нагрузочного тестирования, но для некоторых приложений он оказывается единственно возможным. При программном методе действия пользователя обычно записываются (перехватываются) некой программой, после чего преобразуются в тестовые сценарии. При воспроизведении или исполнении тестового сценария один компьютер обычно выступает в качестве контроллера, распространяющего тестовый сценарий по нескольким клиентским машинам. Во время исполнения теста контроллер синхронизирует действия клиентов для моделирования множества виртуальных пользователей, а по окончании теста собирает результаты от всех клиентов. Виртуальные пользователи создают нагрузку на серверную часть приложения, что позволяет определить степень стабильности и времена отклика Web-приложения. В настоящее время разработано множество программных средств нагрузочного тестирования. Хотя назначение каждого из них — генерировать нагрузку, моделирующую работу многих клиентов, в них используются разные синтаксисы сценариев и механизмы моделирования нагрузки. В этой книге рассматривается такой инструмент нагрузочного тестирования, как Microsoft Application Center Test (ACT). Прочитав эту главу, вы, конечно же, не станете экспертом no ACT, однако узнаете об особенностях этого продукта и о ключевых концепциях и возможностях, которые мы используем наиболее часто. Мы также покажем, как с помощью ACT создать и проверить сценарии динамического тестирования для точного моделирования нагрузки на Web-приложение на базе .NET.

Что такое ACT ACT (Microsoft Application Center Test) — это программное средство нагрузочного тестирования, позволяющее моделировать загрузку Web-серверов, чтобы получить значения метрик производительности, проанализировать и выявить проблемы производительности, а также определить предельные возможности вашего Web-приложения. Для моделирования нагрузки с помощью ACT необходимо записать или создать вручную тестовый сценарий, моделирующий множественные одновременные соедине-

Глава 3

ния, запрашивающие страницы в соответствии со сценарием активности пользователя.

Установка Microsoft ACT на компьютер ACT входит в состав Visual Studio .NET з редакции Enterprise и Architect. В Visual Studio .NET входит много различных компонентов, но для данной книги мы выберем только те из них, которые необходимы для работы ACT. Процесс установки разбит на три основных этапа. Первый этап показан на рис. 3-1. Vbunt Slttrtlii .NfrSeiup

Visual Studio .NET Setup

Рис. 3-1. Диалоговое окно Install Windows Component Update Выберите «Step 1: The Install Windows Component Update» для обновления системных компонентов. Эта опция доступна в диалоговом окне Installation, если зашей системе требуется обновление. Если в обновлении компонентов нет необходимости, данная опция недоступна.

ПРИМЕЧЕНИЕ Если во время работы программы установки запущена антивирусная программа, то она может выдавать предупреждения при исполнении сценариев установки, обращающихся к объектам файловой системы.

Нагрузочное тестирование с помощью ACT

После обновления системных компонентов в диалоговом окне Installation становится доступным пункт «Step 2: Install Visual Studio .NET». Выберите его для установки Visual Studio .NET. Мы выбрали минимальную конфигурацию, так как нам потребуются только компоненты необходимые для работы ACT. Если вы хотите создавать и исполнять проекты и тестовые сценарии непосредственно из интегрированной среды Visual Studio, то позаботьтесь об установке дополнительных компонентов. Application Center Test расположен в списке Select Items to Install раздела Enterprise Development Tools, как показано на рис. 3-2, он выбран по умолчанию.

Microsoft1

Visual audio .NET

•9isuaE Studio .net

teM items tn "ДГ.Ы1 [g*J«su,imiidip.Nn EnterarrseDiwIopei В П X Language laols g-HifeeilrrpHie Development Tcnll О X •*>* 5b>fc Enterprise fi^plelrs '

3 D X -i*J* а-Л- .ii*s S O X Ert3'pfis3-Mn(ilM 0 Л? Appfication Center T«f L П X Visual Siijdio Anabser

rilDX^EI(ram™«'(iSDK 7 D X [>*stal ПсввВ iM Visual Studip .PiEf 7 П X TuoKh" Hid.5bbi«ir»] AnpllcatioiB E П X Strvn Components П X SIJI Server Desktop Frtqun8 П X Documentation

Рис. 3-2. Выбор параметров установки Последний шаг «Step 3: Service Releases Check» выполнять не обязательно, но настоятельно рекомендуется: в этом случае на вашем компьютере будут установлены все последние исправления.

Базовые понятия ACT В данном разделе описаны базовые понятия ACT и приведены некоторые советы, которые помогут вам сократить время обучения, воспользовавшись нашим опытом.

Глава 3

Динамические тесты Аинамический тест считается очень мощным средством ACT, которое дает возможность записать или создать вручную список HTTP-запросов, посылаемых Web-серверу параллельно. Вы также вправе изменить информацию заголовков, например «referrer», «user-agent», и строку запроса. Сценарии динамических тестов можно писать на Visual Basic Script (VBScript), Jscript, PERL или любом другом языке сценариев, поддерживающем СОМ. При автоматической записи тестового сценария ACT поддерживает только VBScript. Параллельные пользователи и параллельные браузерные сессии ACT Параллельное соединение с Web-приложением, которое выполняет запрос или серию запросов, содержащихся в тестовом сценарии ACT, называется параллельной браузерной сессией (simultaneous browser connection, SBC). Другие инструменты нагрузочного тестирования используют такие термины, как «нагрузочный поток» (stress thread) или «виртуальный пользователь» (virtual user}, которые являются синонимами ACT SBC (уровень нагрузки). Нас часто спрашивают: «Каково соотношение между SBC и числом параллельных пользователей?» Сопоставление SBC с одновременно работающими пользователями затруднительно, так как не всегда известно, сколь часто пользователи будут запрашивать страницы Web-приложения. Тестовые сценарии, исполняемые без интервалов простоя (sleep time) (времени, которое уходит на раздумья пользователя), часто вызывают более высокие нагрузки на приложение, чем при просмотре страниц приложения реальным пользователем с помощью Web-браузера. Следовательно, стоит включить в сценарии случайные задержки, сравнимые со временим раздумья реальных пользователей, для снижения интенсивности запросов к Web-серверу, что позволит более точно сопоставить один SBC с одной пользовательской сессией и лучше смоделировать реальный Web-трафик. Пользовательские интервалы простоя При создании тестовых сценариев стоит добавить в них пользовательские интервалы простоя. Эти позволит моделировать реальное использование приложения, вводя задержки на раздумья

Нагрузочное тестирование с помощью ACT

пользователя. Например, вставив 5-секундный интервал простоя в сценарий, моделирующий заполнение пользователем Web-формы, вы точнее смоделируете типичные действия пользователя, та как учтете время, требующееся ему для заполнения формы. В ACT Sleep является методом объекта Test. При автоматической записи в тестовый сценарий ACT вставляется следующий код: fEnableDelays = False If fEnableDelays = True then Test.Sleep (0) По умолчанию переменная fEnableDelays в начале записанного файла сценария установлена в false. Для организации задержки на 5 секунд, или на 5 000 миллисекунд, этот код нужно изменить так; fEnableDelays = True If fEnableDelays = True then Test.Sleep (5000) При необходимости можно использовать функцию случайного ожидания, вставив в тестовый сценарий следующий фрагмент кода и вызывая данную функцию перед каждым запросом: Function RandomSleepO Dim IMinSleep, IMaxSleep, ISleep IMaxSleep = 5000 ' 5 seconds IMinSleep = 1000 ' 1 second ' Сгенерировать случайное целое в указанном диапазоне. Call RandomizeO ISleep = Int((lMaxSleep - IMinSleep + 1) * Rnd(1) + IMinSleep) Call Test.Sleep(lSleep) 1 Возвратить величину задержки. RandomSleep = ISleep End Function Один из «минусов» использования интервалов задержки — то, что таким образом снижается нагрузка со стороны данного клиента. Это может помешать вам определить истинную параллельную нагрузку. Аналогично, при недостаточной мощности клиента, задача обнаружения «узких» мест значительно усложняется, так как они проявляются при максимальных нагрузках на систему. Тестовый сценарий без интервалов ожидания моделирует транзакцию, в которой у пользователя имеется предварительно заполненная форма, отправляемая немедленно. Задание интервалов ожидания моделирует реальный трафик и позволяет точнее оценить максимальное число параллельных пользователей.

Глава 3

При задании случайных интервалов ожидания можно считать, что один SBC равен одному реальному пользователю.

Пользователи и группы Пользователи моделируются ACT динамически путем задания для всех элементов группы пользователей по умолчанию одного имени пользователя и пароля. Между SBC и пользователями существует соотношение один к одному. Например, если установить уровень SBC в 25, то для выполнения теста вам потребуется как минимум 25 пользователей. Если ваше Web-приложение использует анонимную аутентификацию, то ACT генерирует нужных пользователей по умолчанию. Если же Web-приложение требует базовой аутентификации или аутентификации Windows NT LAN Manager (NTLM), вам придется заранее создать имена пользователей и пароли. ACT позволяет настроить пользователей либо вводя их данные вручную (посредством пользовательского интерфейса), либо импортируя данные из файла. При исполнении теста у каждого SBC будет уникальное имя пользователя и пароль. Эти данные доступны сценарию тестирования посредством объекта Test. В следующем примере используется метод Test.CetCurrentUser, позволяющий получить имя текущего пользователя и пароль: Dim oUser, sUserName, sPassword Set oUser = Test.GetCurrentUser sUserName = oUser.Name sPassword = oUser.Password

«Cookie» В большинстве случаев оптимальным вариантом работы с HTTP «cookie» является передача управления ими ACT. «Cookie» можно установить вручную при запуске теста, a ACT будет обрабатываться автоматически. Для любого запроса, содержащего HTTP-заголовок «Cookie», ACT покажет реальный ответ, сгенерированный Web-сервером, и по умолчанию при автоматической записи теста он будет закомментирован. Следующая строка кода сценария будет содержать тот же запрос со значением «(Automatic)». Файл справки no ACT содержит более подробное описание синтаксиса для работы с «-cookie».

Нагрузочное тестирование с помощью ACT

Заголовки Заголовки обрабатываются автоматически, но в тексте тестового сценария вы можете изменить такие заголовки, как «referrer»,«user-agent», «host», версию HTTP и др.

ПРИМЕЧАНИЕ Если в вашем тестовом сценарии содержится строка, несущая только следующую информацию; "Test.SendRequest("http://Localri cist/samples/browse r.asp")" то ACT добавит набор заголовков по умолчанию, использул «Mozilia/4.0 (compatible; MSIE 5.01; Windows NT 5.0)» в качестве заголовка «user-agent». Например, если поведение вашего приложения зависит от значения заголовка «user-agent» (для разных Web-браузеров), то вы можете изменять заголовок HTTP в запросе, динамически моделируя использование разных браузеров: Dim sUserAgent, зАггау(З), sSeed sArrayd) = "Mozilla/4.0 (compatible; MSIE 6 . 0 ; Windows NT 5.1)" sArray(2) = "Mozilla/4.0(compatible;MSIE 4.0;Mac PowerPC)" sArray(3) = "Mozilla/5.0 {Windows; U; Win98; en-US; m18) Gecko/ 20001108 Netscape6/6.0" RandomizeO sSeed = Int((3 * find ) + 1) sUserAgent = sArray(mySeed)

Аутентификация и шифрование ACT поддерживает большинство распространенных моделей аутентификации и методов шифрования: интегрированную аутентификацию Windows NT LAN Manager (NTLM), базовую аутентификацию, анонимный доступ, дайджест-аутентификацию и аутентификацию Microsoft Passport. Однако при автоматической записи сценария поддерживаются не все из перечисленных методов. Для случаев интегрированной аутентификации и Microsoft Passport разработаны способы, позволяющие обойти это ограничение (они обсуждаются далее). В следующей таблице описана поддержка методов аутентификации при записи и при исполнении сценария:

Глава 3

40 Табл. 3-1. Поддерживаемые методы аутентификации Метод

Запись теста

Исполнение теста

Анонимный Базовый

Да

Windows-интегрированный Passport Дайджест

Нет

Да

Нет

Да

Интегрированная Windows-аутентификация ACT поддерживает воспроизведение интегрированной Windowsаутентификации; однако невозможно записывать сценарий работы с Web-приложением, если в конфигурации N5 выбрана опция интегрированной аутентификации. Некоторые Web-приложения no-прежнему смогут работать, если выбрана анонимная или базовая аутентификация. Для таких приложений стоит использовать следующий прием для записи тестового сценария с помощью ACT. 1. В дополнение к интегрированной включите и базовую аутентификацию. Это позволит ACT вести запись в то время, пока другие пользователи вашего Web-приложения автоматически применяют интегрированную аутентификацию. 2. Запишите тестовый сценарий ACT. Вам будет предложено ввести домен, имя пользователя и пароль для доступа к Webприложению. 3. Снова измените конфигурационный файл Web-приложения для запуска только интегрированной аутентификации. 4. Измените тестовый сценарий ACT, закомментировав следующую строку в каждом запросе: oHeaders.Add "Authorization", "Basic XXXXX" 5. Создайте пользователей ACT с надлежащими именами и паролями. 6. Выполните тестовый сценарий. Базовая и дайджест-аутентификация ACT поддерживает запись и исполнение сценария для приложений, использующих как базовую, так и дайджест-аутентифика-

Нагрузочное тестирование с помошью ACT

цию. Для использования базовой или дайджест-аутентификации ACT автоматически добавит в ваш сценарий следующий код: Basic and Digest Authentication.es 'Basic Authentication Code oHeaders.Add "Authorization", "Basic xxxxx=" 'Digest Authentication Code oHeaders.Add "Authorization", "Digest username="+chr(34)+_ "domain\username"+chr(34)+", realm="+chr(34)+"IBUYSPY"+_ chr(34)+", qop="+chr(34)4"auth"+chr(34}+", algorithm='4_ chr(34)+"MD5"+chr(34)+", uri="+chr(34)+"/storevbvs/"+_ chr(34)+", nonce="+chr(34)+"xxxxxxxx"+chr(34)+",_ nc=00000001, cnonce="+chr(34)+"xxxxxxx"+chr(34}i-",_ response="+chr(34)-t-"xxxxxx"+cnr(34) Анонимная аутентификация Анонимный метод аутентификации наиболее распространен в Web-приложениях. ACT полностью и автоматически поддерживает анонимную аутентификацию как при записи сценариев, так и при их исполнении. Аутентификация Microsoft Passport Microsoft .NET Passport — это группа Web-сервисов, которые облегчают пользование Интернетом и совершение покупок в Интернет-магазинах, предоставляя пользователям единую точку регистрации (sign-in) и возможность быстрых покупок. Сервис единого имени пользователя или единой регистрации предназначен для предоставления централизованного, защищенного и удобного сервиса, с помощью которого конечные пользователи осуществляют транзакции. Так как Web-приложения Passport используют SSL, средство записи сценариев ACT не может работать при задании такой схемы аутентификации. Вам придется вручную написать часть тестового сценария ACT, выполняющего регистрацию пользователя, или не использовать Passport во время тестирования. Кроме того, реализация приложений Passport различается, так что тестовые сценарии для них могут не совпадать. Для новых версий Passport тестовые сценарии, вероятно, придется исправлять. Простой сценарий аутентификации Passport, написанный ACT Development Team, находится на прилагаемом к книге компакт диске.

Глава 3

SSL ACT полностью поддерживает исполнение тестовых сценариев, запрашивающих элементы, зашифрованные с помощью 40-битного или 128-битного SSL Однако запись тестовых сценариев для Web-приложения, поддерживающего SSL, в ACT не поддерживается, так как ACT выполняет запись с помощью прокси, а при поступлении к нему данные уже зашифрованы. Для обхода этого ограничения следует отключить SSL на время записи сценария. Изменение номера порта с 80 на 443 в вызовах Test.CreateConnection снова активизирует использование 5SL. Ниже показан синтаксис вызова Test.CreateConnection, а также варианты вызова с портами 80 и 443: Синтаксис Без SSL С SSL

oConnect = Test.CreateConnectlon(strServer, _ IPort, bUseSSL) oConnect = Test.CreateConnection{"YourServerNaine", 60, False) oConnect = Test.CreateConnection("YourServerNarae", 443, True)

Если отключить SSL для вашего Web-приложения нельзя, придется вручную добавить ссылки на зашифрованные страницы, используя показанный выше синтаксис.

Использование SOAP с ACT SOAP — это простой протокол на основе XML для обмена информацией в децентрализованной распределенной среде. Более подробная информация о SOAP опубликована на http://msdn.microeoft.com/vstudio/. ACT не содержит встроенной поддержки запросов SOAP, однако это ограничение можно обойти, сформировав тело SOAP-запроса вручную конкатенацией строк. Пример кодирования SOAP-запроса set con = Test,CreateConnection(YourServerName, 80, false) set req = Test.CreateRequest set headers = req.Headers req.Path = "/Logon.asmx" req.Verb = "POST" req.HTTPVersion = "HTTP/1.Г headers.RemoveAll

Нагрузочное тестирование с помощью ACT

headers.Add "Host", "(automatic)" headers.Add "SOAPAction", chr(QUOTE) & _ "http://YourServerName/LogonUser" & chr(QUOTE) headers.Add "Content-Type", "text/xml; charset=utf-8" headers.Add "Content-Length", "(automatic)" body = "<?xml version="& chr(QUOTE) & "1.0" & chr(QUOTE) & "_ encoding="& chr(QUOTE) & "utf-8" & chr(QUOTE) &"?>" body = body & "<soap:Envelope xmlns:xsi="&chr(QUQTE)&_ "http://www.w3.org/2001/XMLSchenia-instance" &chr(QUOTE)& "_ xmlns:xsd=" &chr(QUOTE)& "http://www.w3.org/2001/_ XMLSchema" &chr(QUOTE)& "_ xmlns:soap=" &chr(QUOTE)& "http://schemas.xmlsoap.org/soap/_ envelope/"4chr(QuOTE)&">" body = body & "<soap:Header>" body = body & "<CorrelationHeader xmlns="&chr(QUOTE)&"http:// YourServerName/"_ &chr(QUOTE)&">" body = body & "<Contents>string</Contents>" body = body & " </CorrelationHeader>" body = body & " </soap:Header>" body ~ body & " <soap:Body>" body = body & " <LogonUser xmlns="&chr(QUOTE)&"_ http://YourServerName/"&_ chr{QUOTE)&">" body = body & " <licenseeAccotint>Microsoft</licenseeAccount>" body = body & " <userName>testact</userNanie>" body = body & " <userPassword>testact123</userPassword>" body = body & " </LogonUser>" body = body & " </soap:Body>" body = body & "</soap:Envelope>" req.Body = body set res = con.Send(req) Обработка состояния отображения Состояние отображения (viewstate) — это средство, применяемое ASP.NET для поддержки состояния сессии и использующее скрытые элементы формы на Web-страницах. В ACT нет встроенной поддержки состояния отображения. Однако в следующем примере показано, как вручную выделить состояния отображения и закодировать его: Viewstate. cs 'Разбор VIEWSTATE. If InStr(oResponse.Body, "__VIEWSTATE") Then

Глава 3 Post = InStr(InStr(oResponse.Body, "__VIEWSTATE"),_ oResponse.Body, "value=")

Pos2 = InStr(Pos1, oResponse.Body, ">")

res = Mid(oResponse.Body, Pos1 + 7, Pos2 - Pos1 - 8)

viewst = res End If

' Формирование VIEWSTATE вручную: 1 Заменить все вхождения "+" на "%2В". viewst = Replace(viewst, "+", "Я2В") 1 Заменить все вхождения " = " на "ПО".

viewst = fleplacefviewst, "=", "X3D")

Можно обойтись без кодирования VIEWSTATE (и всех данных Post) вручную, установив следующее свойство: oRequest. EncodeBody = True.

Защита Web-сайта от ошибочного нагрузочного тестирования ACT поддерживает Robots Exclusion Standard, используемый разработчиками автоматизированных пользовательских агентов («роботов») и администраторами Web-сайтов для определения областей Web-приложения, доступных определенным пользовательским агентам. Чтобы запретить ACT отправлять запросы Web-серверу, вы можете создать файл «robots.txt» в корневом каталоге сервера и добавить в него следующие строки: ft Stress Agent это строка user-agent посылаемая ACT для собственной идентификации.

User-agent: Stress-Agent # / Запрещает работу ACT со всеми частями Web-сайта Disallow; /

При исполнении теста с Web-сайтом, защищенным файлом robots.txt, ACT будет исполняться, не генерируя никаких запросов. При этом на панели состояния отображается строка: «Robots.txt denied access to Web serven*.

ПРИМЕЧАНИЕ В некоторых случаях применение протокола исключения пользовательских агентов не позволит вам выполнить тест, например при тестировании Passport. Поэтому ACT позволяет отключить эту проверку в диалоге Properties проекта (щелкните имя проекта правой кнопкой и выберите Properties).

Нагрузочное тестирование с помощью ACT

Запуск ACT Этот раздел можно считать отправной точкой в освоении утилиты нагрузочного тестирования ACT. Мы кратко опишем пользовательский интерфейс, а также рассмотрим процесс создания сценариев тестирования. Здесь приведены примеры записи сценариев тестирования с нуля и использования ACT для непосредственного нагрузочного тестирования SQL-уровня и рекомендации по исполнению нагрузочных сценариев с помощью ACT. Кроме того, мы коснемся таких тем, как оптимальное число сценариев тестирования, выбор подходящего числа тестовых клиентов, а также оптимальный уровень нагрузки (измеряемый в SBC).

Обзор пользовательского интерфейса ACT Пользовательский интерфейс ACT весьма прост. После запуска программы вы увидите окно, показанное на рис. 3-3.

НФФШданмкВф .,...,,- .,;=!•. ..--с ,, -• . .i ,•(• , и.' .1 .

application Center Test provides several mefriods of сэвИтчд ** mi* •ttfonafA paja in your Web application Use Die meiriod ttiat best meets ycur accuracy reeds. Appl'cation lemer ~est jrfers rt.fferem ie:t lyp<!5, еэ± prQvldmg unique benefiG that might Be more appropriate fty s'mulalnrj |че traffic against «"jr aapl^aton Configuring Test Properties Test propabas can be modified to suit you

Application Center Ti?st Nev How in gel support OrJine

Рис. 3-3t Начальное окно ACT Окно разделено на две секции — левую и правую. Левая используется для навигации, а правая — для отображения информации.

Глава 3

Дерево на левой панели содержит корневой узел ACTSamples, представляющий проект ACT. Одновременно может быть открыт только один проект. По умолчанию проект хранится в папке с тем же именем внутри папки C:\Documents and Sett ings\< пользователь >\Му Documents\ACT Projects. Файл проекта с расширением .act находится в этой папке и содержит указатели на все элементы проекта, такие, как тесты и отчеты.

ПРИМЕЧАНИЕ Если для размещения папки My Documents вы используете сетевой каталог, то пользовательской записи ACTUser необходимо предоставить права на чтение и запись в него, в противном случае ACT не сможет исполнять тесты. На панели состояния при этом появится сообщение «ACTUser does not have permissions to the folder». На следующем уровне дерева расположены три.узла: Tests, Results и Users, подробно о них рассказано в следующих разделах. Tests В этом узле перечислены все созданные пользователем сценарии тестирования. При выборе тестового сценария его код отображается в правой панели, где его можно корректировать. У каждого тестового сценария имеются параметры, управляющие его исполнением, например длительность. Для просмотра параметров теста щелкните его правой кнопкой и выберите Properties. На экране появится страница свойств, показанная на рис. 3-4. Для создания новых сценариев тестирования щелкните узел Tests правой кнопкой и выберите New Test из контекстного меню. В контекстном меню для данного теста имеются команды на его запуск и остановку. Один клиент ACT может одновременно исполнять только один тест. Results

Этот узел отображает в правой панели результаты исполнения всех прогонов каждого тестового сценария. Изображение на экране после щелчка узла Results показано на рис. 3-5.

Нагрузочное тестирование с помощью ACT

Рис. 3-4. Параметры теста fa ACTSamnles

Micriwoll ApBMraifon Cen)e[ Test

r Type [E.mple 3) г Турв (Example 2) г Туи (Eismple 1)

reprf t-TMcFil

Test Maine ; Test Run Name: Tert Started: Test Duration: Test Iterations: Test Notes:

iCTSamples: Browser Type repcrt-Browser Type (Exampls 4; 06/14/2001 6:36:32 PM 30:00:01:00 3,470

View:

Averages

Per

Sort By:

General Ccr'er: Length: Ti-rie to First Byte: Time to Last Byte:

Ailili A

н j rr.b si HtJJaqygs t Б

3th Pe

Рис. 3-5. Просмотр результатов теста Правая сторона экрана разделена на три части. Вверху перечислены все исполнявшиеся ранее тесты. Для каждого в порядке

Глава 3

убывания времени показаны результаты прогонов. Для просмотра результатов теста нужно выбрать соответствующий прогон, тип отчета из раскрывающегося списка Report и затем — категорию из списка. Все детали отчета отобразятся в нижней части правой панели экрана. ACT поддерживает различные категории отчетов — Overview, Graphs и Requests. Вы можете просматривать такую информацию, как число запросов в секунду (requests per second, RPS), время до последнего байта (Time To Last .Byte, TTLB), статистику просмотра страниц и даже счетчики производительности. Вся эта информация хранится в файловой системе в виде XML-документов. Подробности см. в справочной системе ACT. Users

В этом узле перечислены группы пользователей, которые могут использоваться тестами. Шелкнув группу, вы отобразите в правой панели список ее пользователей. Чтобы добавить нового пользователя и пароль, просто выберите на правой панели пустую строку и введите нужные значения. Для удаления пользователя выделите нужную строку и нажмите клавишу Del. Полезной является поддерживаемая ACT возможность импорта имен пользователей и паролей из текстового файла в формате с разделителем-запятой. Для этого выделите группу пользователей и затем выберите Import Users из меню Actions. Каждой браузерной сессии, устанавливаемой ACT, требуется имя пользователя и пароль для подключения к Web-приложению. Именно здесь задаются пользователи для тестирования приложения, использующего базовый или интегрированный методы аутентификации.

ПРИМЕЧАНИЕ Чтобы не вводить пользователей перед каждым прогоном теста, вам следует создать группу и затем завести в ней нужное число пользователей. Количество пользователей в группе должно быть больше или равно количеству SBC. Кроме того, если Web-приложение настроено на анонимные подключения, вы можете включить автоматическую генерацию пользователей (на вкладке Users).

Нагрузочное тестирование с помощью ACT

Создание тестового сценария Для демонстрации работы ACT в качестве инструмента нагрузочного тестирования мы создали несколько тестовых сценариев, использующих средства поиска и просмотра сайта-примера IBuySpy. IBuySpy — это электронный магазин, предназначенный для демонстрации возможностей платформы и технологий .NET. Мы используем приложение IBuySpy повсюду в этой книге. Просмотреть работу приложения можно по адресу http://www.ibuyspystore.com/. Со страницы http://www.ibuyspy.com/downloads.htm вы также можете загрузить его для установки у себя. Для простоты сопровождения тестовых сценариев мы рекомендуем вам создавать для каждого нового тестового проекта отдельный проект ACT в собственной папке. Тогда по окончании цикла тестирования вы сможете заархивировать всю папку, чтобы сохранить все тестовые сценарии и данные. Для создания проекта выберите New Project из меню File. В диалоговом окне New Project укажите имя проекта. Для простоты мы назвали проект IBuySpy, а место его размещения изменили на C:\ProjectV В результате в папке C:\Project\ будет создана папка IBuySpy. Последняя останется пустой до тех пор, пока вы не сохраните проект при этом будет создан файл IBuySpy.act вместе с некоторыми другими файлами, составляющими проект. Для каждого тестового прогона ACT создает отдельные файлы отчетов в формате XML, содержащие свойства теста, свойства проекта, группы пользователей и клиентов. Запись сценария тестирования Проще всего создать сценарий тестирования путем записи действий пользователя Web-приложения. Для того чтобы начать сессию записи, щелкните узел Tests правой кнопкой и выберите из контекстного меню New Test — на экране появится мастер New Test. Щелкните Next и затем выберите Record A New Test. Щелкните кнопку Next и затем — кнопку Start Recording. В этот момент запустится браузер, используемый вами по умолчанию, и вы сможете выполнить следующий пользовательский сценарий поиска. 1. Направьте браузер по адресу \М1р://<ИмяВашегоСервера >/. 2. Введите boat в поле Search, расположенное в правом верхнем углу Web-страницы.

Глава 3

3. Щелкните Go для выполнения поиска. Закончив исполнение пользовательского сценария, щелкните кнопку Stop Recording. Все запросы, выданные во время сессии, отобразятся в окне списка, но пока их нельзя изменить. Щелкните Next и укажите имя сценария. Щелкните Next еще раз и затем — Finish. Вновь записанный тест должен появиться в дереве левой панели окна. Ниже приведена выдержка из сценария, использующего средство поиска IBuySpy. Search, vbs Option Explicit Dim fEnableDelays fEnableDelays = False Sub SendRequest1() Dim oConnection, oRequest, oResponse, oHeaders, strStatusCode If fEnableDelays = True then Test.Sleep (0) Set oConnection = Test.CreateConnection("YourServerName", 80, false) If (oConnectton is Nothing) Then Test.Trace "Error: Unable to create connection to YourServerName" Else Set oRequest = Test.CreateRequest oRequest.Path = "/StoreVBVS/default.aspx" oRequest.Verb = "GET" oRequest.HTTPVersion = "HTTP/1.0" set oHeaders = oRequest.Headers oHeaders.RemoveAll oHeaders.Add "Accept", "image/gif, image/x-xbitmap, image/jpeg,_ image/pjpeg, application/vnd.ms-excel, _ application/vnd.ms-powerpoint, application/msword, */*" oHeaders.Add "Accept-Language", "en-us" oHeaders.Add "User-Agent", "Hozilla/4.0 (compatible; MSIE 6.0;_ Windows NT 5.1)" 'oHeaders.Add "Host", "YourServerNane" oHeaders.Add "Host", "(automatic)" oHeaders.Add "Cookie", "(automatic)" Set oHesponse = oConnection.Send(oRequest)

Нагрузочное тестирование с помощью ACT

If (oResponse is Nothing) Then Test.Trace "Error: Failed to receive response for URL to " + "/StoreVBVS/default.aspx" Else strStatusCode = oResponse.ResultCode End If oConnection.Close End If End Sub Sub SendRequest2() Dim oConnection, oRequest, oResponse, oHeaders, strStatusCode If fEnableDelays = True then Test.Sleep (130) Set oConnection = Test. CreateConnection("YourServerName", 80, false) If (oConnection is Nothing) Then Test.Trace "Error: Unable to create connection to YourServerName" Else Set oRequest = Test.CreateRequest oRequest,Path = "/StoreVBVS/IBuySpy.ess" oRequest,Verb = "GET" oRequest.HTTPVersion = "HTTP/1.0" set oHeaders = oRequest.Headers oHeaders.RemoveAll oHeaders.Add "Accept", "*/*" oHeaders.Add "Referer", "http://YourServerNarne/StoreVBV$/default.aspx" oHeaders.Add "Accept-Language", "en-us" oHeaders.Add "User-Agent", "Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)' 1 oHeaders.Add "Host", "YourServerName" oHeaders.Add "Host", "(automatic)" oHeaders.Add "Cookie", "(automatic)" Set oResponse = oConnection.Send(oRequest) If (oResponse is Nothing) Then Test.Trace "Error: Failed to receive response for URL to " + "/StoreVBVS/IBuySpy.css" Else strStatusCode = oResponse.ResultCode End If oConnection.Close End If End Sub

Глава 3

Sub SendRequest3() Dim oConnection, oRequest, ofiesponse, oHeaders, strStatusCode If fEnableDelays = True then Test.Sleep (20) Set oConnection = Test.CreateConnectionC'YourServerName", 80, false) If (oConnection is Nothing) Then Test.Trace "Error: Unable to create connection _ to YourServerName" Else Set oRequest = Test.CreateRequest oRequest.Path = "/StoreVBVS/images/sitebkgrdnogray.gif" oRequest.Verb = "GET" oRequest.HTTPVersion = "HTTP/1.0" set oHeaders = oRequest.Headers oHeaders. RemoveAll oHeaders.Add "Accept", "*/*" oHeaders.Add "Referer", "Http://YourServerName/StoreVBVS/default.aspx" oHeaders.Add "Accept-Language", "en-us" oHeaders.Add "User-Agent", "Mo2illa/4.0 (compatible; MSIE 6.0;^ Windows NT 5.1)" 'oHeaders.Add "Host", "YourServerName" oHeaders.Add "Host", "(automatic)" oHeaders.Add "Cookie", "(automatic)" Set oResponse = oConnection.Send(oRequest) If (oResponse is Nothing) Then Test,Trace "Error: Failed to receive response for URL to " + "/StoreVBVS/images/sitebkgrdnogray.gif" Else strStatusCode = oResponse,ResultCode End If oConnection.Close End If End Sub

Sub SendRequest17() Din oConnection, oRequest, oResponse, oHeaders, strStatusCode If fEnableDelays = True then Test.Sleep (6910) Set oConnection = Test.CreateConnection("YourServerName", 80, false) If (oConnection is Nothing) Then

Нагрузочное тестирование с помощью ACT

Else

Test.Trace "Error: Unable to create connection to YourServerName"

Set oRequest = Test.CreateRequest oRequest.Path = "/StoreVBVS/SearchResults.aspx" oRequest.Verb = "POST" oRequest.KTTPVersion = "HTTP/1.0" oRequest.EncodeBody = False set oHeaders * oRequest.Headers oHeaders.RemoveAll oHeaders.Add "Accept", "image/gif, image/x-xbitmap, image/jpeg, image/pi peg, application/vnd.ms-excel,_ application/vnd.ras-powerpoint, application/msword, */*" oHeaders.Add "Referer", "http://YourServerName/StoreVBVS/default.aspx" oHeaders.Add "Accept-Language", "en-us" oHeaders.Add "Content-Type", "application/x-www-form-urlencoded" oHeaders.Add "User-Agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 'oHeaders.Add "Host", "YourServerName" oHeaders.Add "Host", "(automatic)" oHeaders.Add "Pragma", "no-cache" oHeaders.Add "Cookie", "(automatic)" oHeaders.Add "Content-Length", "(automatic)" oRequest.Body = "txtSearch=boat&image1.x=13&image1.y=11" Set oResponse = oConnection.Send(oRequest) If (oResponse is Nothing) Then Test.Trace "Error: Failed to receive response for URL to " + "/StoreVBVS/SearchResults.aspx" Else strStatusCode = oResponse.ResultCode End If oConnection.Close End If End Sub Sub Main() call SendRequest1() call SendRequest2() call SendRequestSO call SendRequest17() End Sub Main

Глава 3

Анализ записанного сценария тестирования Как видите, каждый запрос инкапсулирован в подпрограмме с именем SendRequest#0, где # — порядковый номер. Все вызовы этих подпрограмм собраны в подпрограмме Mainf). Начальной точкой исполнения считается верхняя часть сценария тестирования, где объявляются и инициализируются переменные. Отсюда исполнение переходит к последней строке, где вызывается MainQ. Внутри Mainf) вызываются все запросы, после чего исполнение сценария завершается. При последующих прогонах цикла описанные выше шаги повторяются. Приведенный код использует объекты ACT, обеспечивающие подключение к Web-серверу и отправку запросов. Эти объекты составляют модель тестовых объектов. Корнем данной объектной модели является объект Test, В данном конкретном сценарии используются объекты Test, Headers и Request. ACT также поддерживает Application Model, которую можно использовать для программного запуска тестов. Более подробно об этих объектных моделях рассказано в электронной справке no ACT. Записанный нами тестовый сценарий поиска демонстрирует, как выдаются HTTP-запросы СЕТ (SendRequestT) и POST (SendRequestlT), Кроме того, здесь показано использование заголовков запроса. Например, чтобы заставить ACT обрабатывать «cookie» при исполнении сценария автоматически, вы можете добавить следующую строку кода, как показано в приведенном ранее сценарии тестирования: oHeaders,Add "Cookie", "(automatic)" При отправке содержимого тела запроса, как в случае HTTP-метода POST, ACT автоматически определит длину содержимого с использованием следующей строки кода, что также показано в приведенном ранее сценарии: oHeaders.Add "Content-Length", "(automatic)" Исследуя данный сценарий и сценарии тестирования из проекта ACTSamptes, поставляемого вместе с Visual Studio .Net, вы изучите объектную модель, что позволит вам самостоятельно эффективно создавать и модифицировать тесты.

Нагрузочное тестирование с помощью ACT

Создание сценария тестирования вручную Шаг 2 мастера New Test позсоляет создать пустой тест, содержащий одну строку: Test.SendRequest("http://localhost") Аргумент предыдущего вызова может быть изменен на обращение к начальной странице приложения IBuySpy, как показано ниже: Test.SendRequest("http://YourServerName/StoreVBVS") Левая сторона начальной страницы IBuySpy содержит ссылки на все категории товаров. При перемещении мыши по категориям товаров на панели состояния отображается URL Добавляя к сценарию тестирования другие строки, похожие на строку доступа к начальной странице, вы создадите сценарий, моделирующий просмотр категорий продуктов. Для организации случайного выбора ссылок на разных прогонах сценария потребуется дополнительный код. Пример такого сценария показан далее. Browse.vbs Option Explicit 7//////////////////////////////////////////////////////// ' Назначение: просмотр разных товаров в случайном порядке, ' Описание: это пример сценария ACT, моделирующий просмотр различных категорий товаров в произвольном порядке.

7//////////////////////////////////////////////////////// Dim i, sParams, sServerName, oUser

7//////////////////////////////////////////////////////// 1

СДЕЛАТЬ: -На закладке Security свойств IIS -включить только интегрированную аутентификацию, -Заменить значения из примера значениями для вашего сайта, -Установить имя пользователя (domain\username" и пароль. sServerName = "YourServerName" 'Получить ссылку на текущего пользователя, сгенерированного ACT, Set oUser = Test.GetCurrentUser oUser.Name = sServerName & "\USERNAME"

Глава 3

oUser.Password = "UserPasswordl" 7//////////////////////////////////////////////////////// 'Сгенерировать новое зерно для случайных чисел. RandomizeO 'Сгенерировать случайное число от 0 до 6. 1 = Cint(7 * Rnd(» 'Вывести случайное число в трассировочный файл. Test.Trace "i = " & cstr(i) Select Case i Case 0 sParams = "CategoryID=144selection=0"

Case 1

sParams = "CategoryID=154selection=1"

Case 2 sParams = "CategoryID=2D4selection=2" Case 3 sParams = "CategoryID=18&selection=3" Case 4 sParams = "CategoryID=174selection=4" Case 5 sParams = "CategoryID=194selection=5" Case 6 sParams = "CategoryID=164selection=6" End Select 'Запросить начальную страницу. Test.SendRequest("nttp://" 4 sServerName 4 "/storevbvs/Default.aspx") 'Запросить категорию товара. Test.SendRequestfhttp://" & sServerName & YStoreVBVS/productslist.aspx?" & sParams) 'Данный запрос отмечает конец пользовательского сценария. Test.SendRequest("http;//" 4 sServerName 4 "/storevbvs/Default.aspx?test=count")

Нагрузочное тестирование с помощью ACT

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

ПРИМЕЧАНИЕ Последний запрос в сценарии тестирования показывает, как добавить маркер в журнал IIS {формат W3SVC). В нашем примере мы выбрали «test=count», так как эта строка данных не интерпретируется Web-прилжением. Таким образом, вы можете подсчитать количество выполненных пользовательских сценариев (транзакций) по окончании тестового прогона. Этот прием применяется и в другом случае: при определении пропускной способности Web-приложений, когда разные параметры используются для обозначения разных транзакций, выполняемых на одной и той же Web-странице. Создание нагрузочных сценариев для SQL-уровня ACT позволяет выполнять SQL-вызовы посредством ADO (ActiveX Data Objects). Кроме того, ACT поддерживает создание нескольких потоков, благодаря чему удается моделировать несколько одновременных подключений к базе данных. Эта возможность также удобна, если на текущем этапе цикла разработки уровень Web и уровень данных еще не готовы к совместной работе.

ПРИМЕЧАНИЕ Необходимо убедиться в том, что пользовательские опции SQL Server (то есть, уровень изоляции транзакций) для сессии SQL, создаваемой сценарием тестирования, и сессии, используемой приложением, — идентичны. Начав с пустого сценария тестирования, подключитесь к SQL Server и выполните хранимую процедуру или любой динамичес-

Глава 3

ки сгенерированный SQL-оператор. Например, алгоритм поиска G приложении IBuySpy вызывает следующую хранимую процедуру: ProductSearcfi ©Search = N'search string' Следующий сценарий тестирования демонстрирует подключение к SQL Server напрямую с использованием Scripting Library и ADO и вызов реализации средства поиска приложения IBuySpy на уровне базы данных. Кроме того, он содержит пример выборки данных из внешнего файла. Search_SQL.vbs

Option Explicit ' Назначение: прямое тестирование SQL-уровня посредством ADO. 1 Описание: Данный пример сценария тестирования AST выполняет SQL-вызовы посредством ADO. Параметры для хранимой процедуры поиска этот сценарий берет из внешнего файла.

7//////////////////////////////////////////////////////// Dim oFso, oCsvFile, oSQLConn, sConnStr, sSearchStr, sServerName Dim sUserName, sPassword, sPath

7//////////////////////////////////////////////////////// ' СДЕЛАТЬ: - Установить sServerName. - Создать пользователя SQL Server с привилегиями dbo на базу данных Store. - Проверить путь к файлу search.txt. sServerName = "juaceevalS" sUserName = "USERNAME" sPassword = "UserPasswordl" sPath = "D:\Chapter_3\ACT_Project\search.txt" 7//////////////////////////////////////////////////////// 'Create an ADO Connection object Set oSQLConn = CreateObject("ADODB. Connection") sConnStr = "driver={SQL Server} ; Server=" & sServerName & "_ ; Database=Store; uid=" & sUserName & ";pwd=" & sPassword oSQLConn. Open sConnStr 7//////////////////////////////////////////////////////// ' Открыть текстовый файл со строками поиска.

Нагрузочное тестирование с помощью ACT

Set oFso = CreateObject("Scripting. FileSystemObject") Set oCsvFile = oFso.OpenTextFilefsPath ,1) 7//////////////////////////////////////////////////////// 'Цикл до достижения конца файла. Do While oCsvFile. AtEndOf Stream <> True 'Считать строку поиска из файла, sSearchStr = oCsvFile. ReadLine 'Вывести строку поиска в журнал ACT. Test. Trace sSearchStr

' Выполнить хранимую процедуру ProductSearch. T

oSQLConn. execute "exec ProductSearch ©Search = N" &_ trim(sSearchStr) & .....

Loop 'Закрыть текстовый файл. uCsvFile.Close Set oCsvFile = Nothing Set oFso = Nothing 'Закрыть соединение с базой данных. oSQLConn.Close Set oSQLConn = Nothing

Установка параметров теста перед исполнением сценария Перед исполнением теста необходимо установить значения некоторых его параметров. Для этого используют страницу свойств теста. Можно задать следующие параметры. • Test Load Level — уровень нагрузки (вкладка General). Для этого необходимо установить количество параллельных браузерных сессий. Одну такую сессию можно считать виртуальным пользователем, работающим с приложением. Например, если вы хотите смоделировать десять параллельных подключений к Web-приложению, установите данное значение о 10. ACT запустит 10 SBC, каждая из которых будет исполнять тестовый сценарий.

Глава 3

• Test Duration — длительность теста (вкладка General). Здесь возможно два варианта: задать либо время, либо число повторений для всех сессий. Если количество параллельных браузерных сессий равно 10, а число повторений — 100, то каждая из этих сессий выполнит столько итераций, чтобы их общее количество не превысило 100. При нагрузочном тестировании мы обычно задаем длительность, указывая временное значение, достаточное для «прогрева» и выхода на стабильные режимы работы. Необходимый интервал времени можно определить, наблюдая за степенью загрузки процессора или количеством запросов в секунду во время предварительных прогонов тестового сценария. ACT позволяет устранить влияние на отчеты начальных переходных процессов — для этого достаточно указать начальное «прогревочное» время. • Detailed Reporting — детализация отчетов (вкладка General). ACT может вывести сводную статистику запросов для каждой страницы или просто общую статистику по всем запросам. Для получения подробных отчетов необходимо установить флажок з поле «Generate detailed test results» диалога «Advanced Settings». Данный диалог вызывается щелчком кнопки «Advanced», которая расположена на закладке General.

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

Users — пользователи (вкладка Users). ACT может генерировать пользователей автоматически, либо вы можете задать группу, содержащую указанных пользователей. Когда это необходимо, группу, в которую вы добавили пользователей, можно выбрать на данной закладке диалога свойств. Количество пользователей з группе задается не меньше, чем число параллельных браузерных сессий. Обратите внимание, что на каждом прогоне в сценарии действует один и тот же пользователь, если только сценарий не вызывает метод GetNextUser

Нагрузочное тестирование с помощью ACT

объекта Test. Подробно методы объекта Test описаны в интерактивной справочной системе ACT. • ACT способно автоматически сгенерировать пользователей для теста. Чтобы воспользоваться данной возможностью, вам сначала необходимо создать группу пользователей. Затем, выделите ее и выберите Generate Users из меню Action. На экране появится диалоговое окно Generate Users, где задаются количество пользователей, префикс для идентификаторов пользователей и пароль. Чтоб задействовать вновь созданную группу, ее следует явно назначить некоторому тесту. • Counters — счетчики (вкладка Counters). Вкладка Counters отображает те же счетчики, значения которых собираются Performance Monitor. Вы можете установить длительность интервала сбора данных, задав значение в поле «Collection interval». Для добавления счетчиков щелкните кнопку Add и затем выберите в диалоге Browse Performance Counters целевой компьютер и нужные счетчики. Они отобразятся о списке Performance Counters вкладки Counters. Изменение сценария для устранения повторов входных данных Обычно содержимое, возвращаемое Web-приложениями, генерируется динамически в зависимости от вводимых пользователем данных. Часто слой данных в таких приложениях реализован с помощью системы управления базой данных, подобной SQL Server. По этой причине простая запись действий с последующим их воспроизведением не всегда точно соответствует поведению приложения в реальности. Например, в сценарий пользовательской активности включено применеие поисковых возможностей приложения. При записи сценария фиксируется только одна строка поиска. Многократное воспроизведение такого сценария не станет моделью реального трафика, так как поисковый запрос и его результаты могут быть кэшированы. Результаты теста окажутся неадекватными, так как не соответствовуют действиям реальных пользователей, вводящих разные строки поиска. Автоматическая запись — это быстрый и простой способ создать начальный сценарий, который можно использовать для фиксации большинства, хотя и не всех Web-запросов, таких, как методы СЕ Т и POST. Записанный начальный сценарий иногда требу-

Глава 3

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

ПРИМЕЧАНИЕ Чтобы при каждом следующем прогоне не создавать тестовые данные большого объема заново, перед первым выполнением теста SQL базы данных приложения следует заархивировать и потом восстанавливать из архива перед последующими прогонами. Тогда вы сможете многократно использовать те же самые тестовые данные. Иногда данные, сгенерированные на одном шаге, например CUID, ссылающийся на адрес, необходимо использовать на следующих шагах. В таких случаях тестовый сценарий должен выполнять разбор результатов выданного запроса, чтобы извлечь из них данные для последующего использования. Для этих целей ACT предоставляет объект Response, позволяющий работать с результатами клиентского Web-запроса. Пример использования объекта Response см. в разделе «Обработка состояния отображения». Отладка сценариев тестирования в ACT Для помощи при отладке сценариев тестирования ACT предоставляет файл журнала, в который сообщения записываются во время прогона теста. По умолчанию журнал называется АСТТгаce.log и хранится в папке «Program FiIes\Microsoft ACT». На вкладке Debugging в свойствах проекта вы можете изменить расположение этого файла, ограничить его максимальный размер (по

Нагрузочное тестирование с помощью ACT

достижении которого он удаляется и начинается заново), а также включать или отключать ведение журнала. Средства программного управления трассировкой предоставляет объект Test. Свойство TraceLevel позволяет задавать уровни трассировки, а пользовательские сообщения могут выводиться в журнала вызовом метода Trace. Журнал трассировки также используют для обнаружения ошибок во время исполнения -геста. Следующий пример устанавливает уровень трассировки, при котором в журнале фиксируются все сообщения, и выводит одно сообщение: Test,TraceLevel = -1 ' Свойство tracelevel может иметь одно из следующих значений; ' -1: регистрировать всю информацию; ' 0; отключить журнал; 1 V. регистрировать только внутреннюю информацию программы; ' 2: генерировать только внешнюю информацию,

выводимую методом Test.Trace. Это установка по умолчанию-

Test. Тгасе("Тгасе level is set to " & CStr(Test.TraceLevel))

ПРИМЕЧАНИЕ Обратите внимание, что при значении TraceLevel no умолчанию, в ACTTrace.log не выводится ничего, кроме сообщений, явно выводимых вызовами Test.Trace. Верификация сценариев тестирования Перед выполнением реального теста сценарии тестирования необходимо проверять. Некоторые сценарии способны только считывать данные из базы, тогда как другие могут вставлять, обновлять или удалять данные. Следует проверить, например, правильность производимых им изменений данных. Так, если сценарий выполняет вставки, можно подсчитать количество строк в базе до и после прогона теста и сравнить их с ожидаемыми результатами. Количество строк, вставляемых при исполнении сценария активности пользователя человеком, должно совпадать с количеством строк, вставляемых за один прогон сценария тестирования, Другой полезный прием верификации функциональности сценария тестирования — просмотр журналов IIS. Сравнивая журнал

Глава 3

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

ПРИМЕЧАНИЕ Хотя в этой глазе упоминается Microsoft Internet Information Server, ACT можно использовать для тестирования производительности любого Web-cepsepa. Для верификации сценария тестирования также фиксируют с помощью SQL Profiler выполняемые SQL-операторы и сравнивают их с ожидаемой последовательностью вызовов. Подробнее настройка SQL Profiler обсуждается в глаее 8. Сценарии и тестовые клиенты ACT Developer Edition не предназначен для исполнения на нескольких компьютерах. Его лицензионное соглашение допускает одновременно работу не более одного клиента. В зависимости от тестируемого приложения одна клиентская машина не всегда способна сгенерировать достаточную тестовую нагрузку для вашего Web-приложения, сама не став при этом источником проблем.

ПРИМЕЧАНИЕ Признак того, что клиентская машина стала «узким» местом, — полная загрузка на ней таких ресурсов, как процессор, память и сетевая плата. Можно также определить производительность, прогнав тест, а затем повторить его, разделив SBC между несколькими клиентами. Если с дополнительными клиентами производительность значительно возрастает, то можно с уверенностью полагать, что клиент стал «узким» местом. Для генерации достаточной нагрузки на большинство Web-приложении, которые нам приходилось тестировать, требовалось несколько клиентских машин. Единственный способ сделать это

Нагрузочное тестирование с помощью ACT

с помощью ACT — приобрести дополнительные копии Visual Studio .NET для каждого дополнительного компьютера. Затем вам придется создать тесты вновь, задав параметры и пользователей на каждой машине. Для простоты просто скопируйте папку проекта целиком на каждую клиентскую машину, измените файлы входных данных, если это необходимо, откройте проект и запустите тест.

ПРИМЕЧАНИЕ Максимальное количество браузерных сессий в ACT разно 2000. Для одной клиентской машины этого должно хватить. Если по какойто причине вам понадобится больше 2000 соединений для одного компьютера, вы можете изменить значения параметров проекта напрямую в XML, но после этого страницы свойств проекта нельзя открывать в пользовательском интерфейсе ACT. Кроме того, с помощью дополнительного вызова CreateConnection в сценарии тестирования удается удвоить число соединений на поток управления. Несколько тестовых клиентов необходимо также использовать, если ACT в любой момент времени для данного клиента способно исполнять только один тест. Обычно в приложении имеется больше одного сценария, и для исполнения нескольких сценариев параллельно (смешанный тест) вам потребуется по крайней мере по одной клиентской машине на каждый. Здесь встает вопрос о необходимом числе сценариев тестирования. Следует применить один большой сценарий тестирования, исполняющий все сценарии активности пользователя, или же много сценариев тестирования — по одному на каждую активность? Мы предпочитаем создавать отдельные сценарии, так как это позволяет прогонять их по отдельности и определять «узкие» места в каждом из них. В качестве альтернативы предлагается следующий прием для исполнения нескольких пользовательских сценариев с помощью одного большого сценария тестирования; Sub main()

WhichScenarioToRun = int(Rnd * 100) Randomize

Глава 3

Select Case WhichScenarioToRun Case 0 To 75 Call myTestl Case 76 To 87 Call myTest2 Case 87 To 100 Call myTest3 End Select End Sub Для приложения IBuySpy мы создали отдельные тестовые сценарии «Просмотр», «Поиск», «Регистрация» и «Заказ», которые вы найдете на прилагаемом к книге компакт-диске.

Исполнение нагрузочного теста Требуемые объемы нагрузочного тестирования зависят от целей, поставленных G начале тестирования. Вам необходимо определить критерий, который укажет на достижение необходимых объемов нагрузки. Чтобы помочь вам, приведем некоторые примеры таких критериев: • прекратить увеличение нагрузки при очень большом количестве ошибок в системном журнале событий или журналах Web-сервера; • довести нагрузку до точки, в которой пропускная способность упадет очень сильно; • установить порог использования процессора (например, свыше 75%); •

установить порог использования памяти;

• установить порог времени отклика на запрос страницы; • достичь рассчитанного на основании бизнес-правил числа запросов в секунду или количества параллельных сессий. После определения тестовых критериев необходимо выполнить несколько прогонов теста с разными уровнями нагрузки (разным числом браузерных сессий}. Начав с небольших нагрузок и дав тесту поработать достаточное время для исполнения достаточного количества пользовательских сценариев, вы сможете определить пропускную способность для конкретных сценариев. Увеличивая нагрузку, необходимо следить за загруженностью кли-

Нагрузочное тестирование с помощью ACT

ентской машиной, не допуская ее перегрузки. Дополнительные клиенты могут потребоваться для гарантии того, что клиентская машина во время теста не становится «узким» местом или источником ошибок. Во время этих предварительных тестов, которые мы называем «тестами на задымление», следите за тем, чтобы серверы приложения выполняли все критерии производительности. Вы также можете построить графики пропускной способности приложения. Повторяя эти тесты, вы в конце концов достигнете одного или нескольких пороговых критериев. Они указывают, что получены подходящие уровни нагрузки. Теперь вы готовы провести более длительный по времени тест с соответствующей нагрузкой, используя лишь необходимые средства мониторинга, чтобы минимизировать обращение к серверным ресурсам. В зависимости от масштабов проводимого тестирования вы можете применить один или несколько сценариев. Мы рекомендуем для каждого сценария выполнять отдельные тесты в дополнение к исполнению всех сценариев параллельно с определенной долей каждого в общей нагрузке. Исполнение сценариев по отдельности позволяет обнаруживать «узкие» места, влияющие только на отдельные части приложения. Обнаружив изолированные «узкие» места, вам при проведении смешанного теста будет проще выявить «узкие» места, возникающие в результате взаимодействия разных модулей. Прогон смешанного сценария тестирования (когда все сценарии исполняются параллельно) позволит нагрузить приложение, смоделировав условия, более приближенные к реальным. В результате вы определите «узкие» места, возникающие при взаимодействии разных сценариев, такие, как блокировки и тайм-ауты, Другая важная переменная — общая продолжительность теста. Ее значение зависит от того, как быстро приложение способно обрабатывать запросы и выполнять пользовательские транзакции (сценарии). Другими факторами, влияющими на длительность теста, является время, требуемое для достижения устойчивого состояния, а также имеющиеся объемы тестовых данных. Минимальная длительность исполнения тестов, используемых для определения пропускной способности под нагрузкой, обычно составляет от 5 до 30 минут.

Глава 3

ПРИМЕЧАНИЕ Общее число транзакций = Общее число успешных просмотров страниц или число строк SQL, указывающих на завершенный сценарии Количество транзакций в минуту = Общее число транзакций / Время тестового прогона Количество транзакций в секунду — Количество транзакций в минуту/ 60 секунд. Расширенные тесть! исполняются под нагрузкой не менее восьми часов и могут длиться до недели. Однако точное значение необходимой продолжительности теста зависит от тестируемого приложения. Такие тесты полезны для определения степени стабильности приложения, выявления утечек памяти и мониторинга пропускной способности приложения в условиях продолжительных по времени нагрузок. Контролируемая среда тестирования Помимо определения адекватного числа браузерных сессий и оптимального количества клиентских машин, мы рекомендуем вам выполнять тесты в контролируемой среде. Слово контролируемая подразумевает, что выделены компьютеры, функциони рующие как нагрузочные клиенты, и компьютеры, являющиеся серверами, на которых установлено приложение. Аппаратные средства этих компьютеров должны максимально соответствовать тем, которые предполагается применять при эксплуатации приложения. Все компьютеры следует объединить в закрытую сеть надлежащей пропускной способности. От результатов тестирования мало пользы, если параметры производительности не удается воспроизвести. Контролируемая среда гарантирует надежность тестовых результатов, устраняя не относящиеся к тесту сетевые помехи. Из-за отсутствия управляемой среды результаты тестирования иногда получаются искаженными, так как они зависят от производительности внешних серверов, выполняющих поиски в DNS, аутентификацию и т. п. Задержки в сети колеблются при изменении ее загруженности в зависимости от времени суток, что в некоторых случаях также влияет на пропускную способность приложения. Существование зависимостей от внешних серверов

Нагрузочное тестирование с помощью ACT

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

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

Глава 4

Серверы семейства Microsoft Windows 2000 предоставляют графический инструмент мониторинга производительности System Monitor (Системный монитор), реализованный в виде оснастки (snap-in) Microsoft Management Console (MMC). (В предыдущих версиях Windows NT он назывался Performance Monitor или Perfmon.) Эта оснастка позволяет наблюдать за производительностью Web-приложений, систем управления базами данных и аппаратных ресурсов Windows-серверов. Оснасток ММС предусмотрено две: System Monitor (Системный монитор) для наблюдение за системой в реальном времени и Performance Logs and Alerts (Оповещения и журналы производительности) для ведения журналов производительности. В этой главе мы расскажем о том, как работать с системным монитором, мониторинг каких ресурсов целесообразен и как интерпретировать значения наиболее часто используемых системных счетчиков производительности. Объекты и счетчики производительности для .NET Framework обсуждаются в главе 7, счетчики и объекты ASP.NET и IIS — в главе 6, а счетчики и объекты SQL Server— в главе 8. Обратите внимание, что в этой главе речь пойдет о семействе серверов Windows 2000, а не о Windows .NET Server, так как на момент написания книги готова была лишь бетаверсия последнего.

Мониторинг производительности приложения

Использование системного монитора Единицы измерения, используемые для мониторинга аппаратных и программные ресурсов посредством системного монитора, называются счетчиками. Счетчики объединяются в группы, именуемые объектами. В некоторых случаях у счетчиков также имеются экземпляры. Например, при мониторинге работы процессора Web-сервера следует наблюдать за значением счетчика % Processor Time (% загруженности процессора), входящего в состав объекта Processor (Процессор). Если на сервере имеется несколько процессоров, то можно контролировать либо их общую загрузку, либо значения экземпляров счетчиков для каждого процессора в отдельности. Стандартный набор объектов и счетчиков системного монитора становится доступным сразу же после установки Windows 2000 Server. Если на сервере установлены определенные приложения, например SQL Server, то также доступны объекты и счетчики, предусмотренные для SQL Server. В этом случае системный монитор для сбора информации о работе SQL Server использует удаленные вызовы процедур. Системный монитор потребляет небольшой объем ресурсов процессора и диска наблюдаемой с его помощью системы, что нужно иметь в виду при измерении и расчете производительности систем и приложений. Если мониторинг компьютера выполняется удаленно, то системный монитор также потребляет ресурсы сетевой платы. Для очень сильно загруженных систем и приложений эти накладные расходы могут иметь значение, особенно при реальной эксплуатации системы. Однако если речь идет о среде, специально организованной для тестирования, то эти накладные расходы обычно незаметны. Помимо наблюдения за значениями счетчиков производительности системный монитор позволяет также: • наблюдать за выбранными объектами и счетчиками в реальном времени; • сохранять показания счетчиков производительности в журналах для последующего анализа; •

выполнять мониторинг нескольких серверов Windows 2000 с помощью одного экземпляра системного монитора;

Глава 4

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

использовать трассировочные события для регистрации определенных действий, связанных с процессорами, потоками управления, дисковым вводом-выводом, сетевым вводом-выводом, работой с файлами или страничными ошибками (в виртуальной памяти). Для интерпретации содержимого журналов трассировки требуются специальные программы. Вы можете создать такую программу, используя API (описанние вы найдете на http://msdn.microsoft.com/msdn-files). Трассировка применяется редко, обычно только службами поддержки Microsoft.

В этой главе подробно рассматриваются первые два метода и кратко —четвертый (создание оповещений).

Наблюдение за производительностью в реальном времени При наблюдении за производительностью в реальном времени вы можете использовать три формы представления: график, гистограмму или отчет. Мониторинг производительности в реальном времени полезен тогда, когда вы знаете, что ищете либо хотите убедиться в наличии некоторого «узкого» места. Если для возникновения «узкого» места нагрузочный тест должен выполняться всю ночь, лучше воспользоваться журналами показателей производительности. Подробнее об этом — в разделе «Генерация и просмотр журналов». Диаграмма Отображаемые в реальном времени диаграммы производительности являются отличным способом выявления тенденций и сравнения нескольких экземпляров одного счетчика, например % Processor Time (% загруженности процессора). Представление в виде диаграммы наиболее популярно, поэтому вам необходи-

Мониторинг производительности приложения

7:s

мо хорошо изучить этот способ, с тем чтобы впоследствии использовать его возможности в полной мере. Диаграмма может иметь вид графика или гистограммы. Пример графика производительности показан на рис. 4-1.

Рис. 4-1. Системный монитор в режиме графика Режим графика 1 . Щелкните Start (Пуск), укажите на Programs (Программы), затем Administrative Tools (Администрирование) и потом щелкните Performance (Системный монитор). 2. Щелкните в дереве на левой панели узел System Monitor (Системный монитор) — системный монитор отобразится в правой панели. Возможности мониторинга производительности с помощью диаграмм мы поясним на примере. Итак, допустим, необходимо вести мониторинг использования процессорного времени в многопроцессорной системе. Сначала запускаем системный монитор. Системная консоль с открытым системным монитором показана на рис. 4-2.

СОВЕТ Для запуска системного монитора также достаточно ввести perfmon из Start (Пуск)/Кип (Выполнить).

Глава 4

Рис. 4-2. Системный монитор на системной консоли 3. Если монитор находится не в режиме диаграммы, щелкните кнопку View Chart (Просмотр диаграммы) в верхней части правой панели. Цвет графика

Теперь, когда вы узнали, как отображать график работы процессора, мы познакомим вас с некоторыми возможностями системного монитора, полезными при сборе данных о производительности. Некоторые из них характерны только для диаграмм, gpvгие же применяются также в режиме отчетов и гистограмм. Чтобы различать графики одновременно наблюдаемых параметров, применяйте цвета. Цвет можно выбрать из палитры [в раскрывающемся списке Property Name (Имя свойства) диалогового окна System Monitor Properties (Свойства: Системный монитор)], либо выбор осуществляется автоматически из системных цветов, определенных с помощью инструмента Display (Экран) в Панели управления. При работе с палитрой имейте в виду следующее: •

BackColorCtl — это область, окружающая диаграмму;

•

BackColor — область отображения данных диаграммы;

• ForeColor — цвет текста и легенды. Масштаб счетчика Для некоторых счетчиков требуется настройка масштаба. Например, приходится увеличивать масштаб, выраженный в байтах,

Мониторинг производительности приложения

счетчиков, связанных с памятью. Значение масштаба счетчика изменяется экспоненциально от 0,0000001 до 1000000, Характеристики счетчиков

Выбирая счетчики для сбора данных, учитывайте их характеристики. Некоторые счетчики показывают мгновенные значения, то есть самые последние результаты измерений, а другие — усредненные, то есть среднее значение двух последних измерений за интервал времени, который их разделяет. Для счетчиков объекта «процессор» на многопроцессорном сервере все процессоры перечислены в окне списка Instances (Экземпляры). Системный монитор отображает экземпляры, начиная с 0. Например, для четырехпроцессорного сервера доступны экземпляры с 0 по 3. Важно учитывать влияние характеристик счетчика на результаты. Например, при мониторинге показателя transaction/sec (транзакций/сек) результаты рассчитываются как число транзакций за выбранный интервал времени, Количество транзакций делится на количество секунд в выбранном интервале, Кроме того, особое внимание следует уделять пикам для усредненных счетчиков. Например, в начале наблюдения за счетчиком % Processor Time (% загруженности процессора) может наблюдаться пик загрузки процессора. Для получения точных показателей загрузки процессора подождите второго или третьего усредненного значения счетчика. Имя родительского экземпляра При мониторинге потоков управления процесса Microsoft Windows Explorer нужно выбрать родительский экземпляр Windows Explorer объекта Thread (Поток), а затем каждый из потоков исполняющих Windows Explorer (дочерние экземпляры). Дочерние экземпляры отличаются один от другого индексами экземпляра потока, которые принимают значения О, 1 и так далее для каждого потока, с префиксом #. По умолчанию операционная система устанавливает свойства системного монитора таким образом, чтобы отображать повторяющиеся экземпляры. Индекс экземпляра 0 скрыт, нумерация дополнительных экземпляров начинается с 1. Вы не можете наблюдать за несколькими экземплярами одного процесса, если не используются индексы экземпляров.

Глава 4

Имя компьютера

Каждый объект содержит счетчики, предназначенные для измерения различных параметров производительности, например скорости обмена данными для дисков или времени для процессора. Computer Name (Выбрать счетчики с компьютера) определяет имя компьютера, которое отображаться в нижней части графика. Будьте внимательны при наблюдении за одними и теми же объектами и счетчиками с разных серверов — применяйте цвета и шрифт, чтобы различать показания счетчиков разных компьютеров. Строка значений

Строка значений под диаграммой содержит статистическую информацию по выбранным счетчикам. Включить или выключить отображение строки значений можно, щелкнув правой кнопкой в любом месте диаграммы и выбрав Properties (Свойства), затем выбрав в диалоговом окне System Monitor Properties (Свойства; Системный монитор) вкладку General (Общие) и изменив на ней значение флажка в поле Value Bar (Строка значений). В строке значений отображается следующая информация: • Last (Последний) — последнее значение данного счетчика; • Average (Средний) — среднее значение данного счетчика; • Minimum (Минимум) — минимальное значение данного счетчика; • Maximum (Максимум) — максимальное значение данного счетчика; •

Duration (Длительность) — отображаемое на графике общее время, зависящее от выбранного интервала. Устанавливаемое вами значение интервала определяет, как часто должны замеряться значения счетчика. Подробнее об установке интервала — в разделе «Частота замеров».

Режим гистограммы Режим гистограммы удобен при наблюдении за несколькими экземплярами одного и того же счетчика. Например, сравнив значения счетчика % Disk Read Time (%активности диска при чтении) для всех дисков сервера, удается определить, какой из них перегружен запросами на чтение. Для переключения в режим гистог-

Мониторинг производительности приложения

раммы щелкните соответствующую кнопку панели инструментов или нажмите Ctrl+B. Кроме того, можно выбрать пункт Histogram (Гистограмма) на вкладке Genera! (Общие) в диалоговом окне System Monitor Properties (Свойства: Системный монитор).

Рис. 4-3. Режим гистограммы Режим отчета Режим отчета весьма удобен для счетчиков, связанных с логическим и физическим вводом-выводом: дисковым или сетевым. Например, использование режима диаграммы для мониторинга всех процессов, исполняющихся на вашем Web-сервере, неудобно, так как график или гистограмма будут очень перегружены. Режим отчета в данном случае обеспечит представление данных удобное для восприятия. Для отображения данных реального времени в виде отчета щелкните кнопку Report (Отчет) на панели инструментов или введите Ctrl + R. Вы также можете выбрать пункт Report (Отчет) на вкладке General (Общие) в диалоговом окне System Monitor Properties (Свойства: Системный монитор).

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

Глава 4

мере влияет на возможность выявления потенциальных «узких» мест. В большинстве случаев величина интервала зависит от типа исследуемого «узкого» места. Например, для выявления проблемы, проявляющейся медленно, такой, как утечка памяти, следует выбирать более длинный интервал. С другой стороны, если «узкое» место проявляется часто, задайте интервал покороче. Если тип «узкого» места и момент его возникновения не установлен, то для начала можно выбрать интервал в 15 минут. При выборе интервала следует также учитывать общее время наблюдения. Считывать значения каждые 15 секунд имеет смысл только тогда, когда общее время не превышает четырех часов. При наблюдении за системой в течение восьми часов и более интервал не следует выбирать короче 300 секунд (5 минут). При коротких интервалах обновления зачастую генерируются большие объемы данных, которые трудно анализировать, особенно если одновременно вы имеете дело с большим числом счетчиков. При мониторинге многих объектов и счетчиков также иногда генерируется большой объем данных, который занимает много места на диске. Следует поддерживать баланс между числом наблюдаемых объектов и частотой замеров, чтобы размер файла журнала оставался в разумных пределах. Используя при генерации журналов производительности длинные интервалы между замерами, вы no-прежнему сможете наблюдать флуктуации данных, происходящие между этими интервалами. Подробнее о работе с временными диапазонами в журналах в разделе «Генерация и просмотр журналов».

Генерация и просмотр журналов Одно из наиболее ценных свойств системного монитора — его способность вести журнал. Регулярная регистрация параметров производительности позволит вам сравнивать показатели до и после изменений оборудования, программ или приложения. Например, ваша компания решила начать новую маркетинговую программу, продавая наиболее популярные товары с 50-процентной скидкой. Распродажа вызвала грандиозный рост трафика на Web-сайте компании. Наличие журналов производительности позволит вам выявить рост числа пользовательских транзакций: достаточно сравнить параметры производительности до, во

Мониторинг производительности приложения

время и после распродажи. На основании этой информации удается определить, имеются ли на Web-сайте «узкие» места и в состоянии ли текущие аппаратные средства выдержать подобные маркетинговые акции. Вы можете зафиксировать данные системного монитора за определенный период времени с целью их последующего анализа и сравнения. Это позволит вам наблюдать за изменениями поведения системы во времени, и следовательно, выявить тенденции s ее работе, которые незаметны при наблюдении в реальном времени. Например, исследуя журналы производительности, вы установили, что загрузка диска наиболее велика с 20 до 22 часов и незначительна в остальное время. Возможно, данная тенденция связана с интенсивным вводом данных в это время или с выполнением резервного копирования.

ПРИМЕЧАНИЕ При использовании системного монитора лучше всего вести журнал локально на сервере, за которым ведется наблюдение. Затем содержимое журнала при необходимости можно проанализировать на другом компьютере. Если же вы вынуждены работать по сети, уменьшите число объектов и счетчиков, ограничившись только наиболее важными. Для создания журнала производительности на сервере Windows 2000 с использованием системного монитора выполните следующие действия. 1. Щелкните Start (Пуск), Programs (Программы), затем укажите на Administrative Tools (Администрирование) и щелкните Performance (Системный монитор). 2. Раскройте на левой панели узел Performance Logs And Alerts (Оповещения и журналы производительности). 3. Выберите в дереве консоли узел Counter Logs (Журналы счетчиков). 4. Щелкните правой кнопкой по правой панели и выберите из контекстного меню New Log Settings (Новые параметры журнала), как показано на рис. 4-4.

tin

Глава 4

j£ Svs: em Monitor ^В^уЯетО . This нтрЬ ч pm.ufcs e Й P«formano|LOM «ndAlertJ 5

BnaryRle

С \PeHtogs\5vsle

Lu.

Jif

Рис. 4-4. Создание журнала 5. Введите имя журнала з диалоговом окне New Log Settings (Новые параметры журнала), показанном на рис. 4-5, и щелкните ОК. Мы выбрали для этого журнала имя IBuyspy. ЩШщ1шш§ |Щ|||Щ

г ''- * ''''

Ймйяв

^«IB^J :H*

- • ЁШ "uvi rv ;•-

Рис. 4-5.

Новые параметры журнала

6. Имя, выбранное вами в качестве названия, появится в заголовке диалогового окна Performance Log (Журнал производительности). Щелкните кнопку Add (Добавить), чтобы открыть диалоговое окно Select Counters (Выбор счетчиков).

;; г

Мониторинг производительности приложения

7. Добавьте интересующие вас счетчики, выбирая их и щелкая кнопку Add (Добавить). Закончив, щелкните кнопку Close (Закрыть). На вкладке General (Общие) диалогового окна Performance Log (Журнал производительности) вы также можете установить интервал измерений. 8. Для установки параметров файла журнала, таких, как расположение, имя файла, тип файла и максимальный размер, щелкните вкладку Log Files (Файлы журналов). В качестве типа файлов используйте CSV, особенно если сбор данных вы предполагаете проводить в течение длительного времени. Как показано на рис. 4-6, в данном примере мы сохраняем файл локально.

ПРИМЕЧАНИЕ Если сбор данных предполагается вести в течение длительного времени, то следует выбирать длинные интервалы измерений. Особенно это важно, если данные сохраняются в двоичном файле: двоичные файлы всегда больше, чем файлы CSV. JC1I*

Рис. 4-6. Параметры файла журнала 9. Чтобы задать расписание ведения журнала, щелкните вкладку Schedule (Расписание). Если время остановки журнала не указано, то данные регистрируются до тех пор, пока вы не остановите его вручную.

Глава 4

10.Щелкните ОК. Имя журнала должно появиться на правой панели. Зеленый значок рядом с именем журнала указывает на то, что генерация журнала началась, как показано на рис. 4-7.

Рис. 4-7. Генерация журнала началась Когда сбор данных будет остановлен, значок станет красным. Вы можете запускать и останавливать генерацию журнала вручную, щелкнув имя журнала правой кнопкой и выбрав из контекстного меню Start (Пуск) или Stop. После того как информация собрана и генерация журнала прекращена, вы можете просмотреть записанные данные. 1. Щелкните узел System Monitor (Системный монитор) на левой панели, чтобы отобразить системный монитор на правой. 2. Наверху правой панели щелкните кнопку View Log File Data (Просмотр данных файла журнала), чтобы открыть диалоговое окно Select Log File (Выбор файла журнала), показанное на рис. 4-8. Перейдите в соответствующую папку, выберите файл журнала, который собираетесь просмотреть, и щелкните Open (Открыть). 3. Щелкнув кнопку Add (Добавить), выберите для просмотра интересующие вас счетчики из файла. Когда вы закроете окно Add Counters (Добавить счетчики), выбранные счетчики появятся в окне системного монитора, как показано на рис. 4-9.

Мониторинг производительности приложения

Вы сможете просмотреть только те счетчики, которые были указаны при создании журнала.

j?i™ i S"*^ J

Jp№

Рис. 4-8. Диалоговое окно Log File

Рис. 4-9. Выбор счетчиков Вам также предоставлено право ограничить просматриваемую часть журнала. 1. После загрузки файла журнала в системный монитор щелкните кнопку Properties (Свойства) наверху правой панели.

Глава 4 В диалоговом окне System Monitor Properties (Свойства: Системный монитор) щелкните вкладку Source (Источник). Внизу вкладки Source (Источник) переместите ограничители диапазона таким образом, чтобы в него попало только интересующее вас временное окно, как показано на рис. 4-10.

j Console Root ••••'I |g pwfoin№bgs< H Cnur*«Logs

Рис. 4-10. Информация о файле журнала 4. (Не обязательно.) Для задания иных параметров воспользуйтесь другими вкладками диалогового окна System Monitor Properties (Свойства: Системный монитор), 5. Щелкните ОК, чтобы вернуться в главное окно системного монитора и просмотреть выбранный диапазон данных.

Мониторинг удаленных компьютеров Системный монитор позволяет удаленно наблюдать за производительностью нескольких компьютеров. Этот способ наблюдения применяют, если, например, исследуемый сервер географически удален от вас. Для мониторинга производительности удаленного компьютера зам потребуется право на доступ к этом компьютеру по сети. Оно выдается следующим образом. 1. Из папки Administrative Tools (Администрирование) запустите Программу Local Security Policy (Локальные параметры безопасности).

Мониторинг производительности приложения

2. Дважды щелкните папку Local Policies (Локальные политики), чтобы раскрыть ее. 3. Дважды щелкните папку User Rights Assignment (Назначение прав пользователя). Появится список определенных в системе привилегий. 4. Найдите привилегию Access This Computer from the Network (Доступ к компьютеру из сети) и откройте ее двойным щелчком. Раскроется список пользователей и групп, обладающих данной привилегией. 5. Для добавления к списку новых пользователей или групп щелкните кнопку Add User or Group (Добавить). Для наблюдения за производительностью удаленного компьютера выполните следующие действия. 1. Запустите системный монитор и нажмите Ctrl + l, чтобы открыть диалог Add Counters (Добавить счетчики); 2. В списке Select Counters From Computer (Выберите счетчики с компьютера) выберите или введите имя нужного компьютера. При удаленном мониторинге производительности следует учитывать скорость линии связи. Если она невысока (128 кбит/с или медленнее), то следует переключиться из режима диаграммы, используемого по умолчанию, в режим отчета. Это позволит уменьшить объем передаваемых по сети данных и избежать задержек при отображении текущих значений параметров.

Объекты, счетчики и экземпляры, применяемые для выявления «узких» мест В этом разделе мы рассмотрим некоторые, наиболее часто используемые счетчики производительности (естественно же, не все имеющиеся в наличии, так как для этого потребовалась бы отдельная книга). Именно на основе их показаний удается отыскать «узкие» места, связанные с использованием процессора, памяти или диска. Мы приведем по несколько практических примеров поиска «узких» мест каждого типа.

Глава 4

ПРИМЕНЕНИЕ Описание каждого счетчика имеется в оперативной справочной системе. Обращайтесь к ней, если вам не удалось найти нужный счетчик. Длл этого следуйте алгоритму добавления счетчика, описанному ранее в этой главе. Когда появится диалоговое окно Add Counters (Добавить счетчики), щелкните счетчик, описание которого вы хотите получить, затем — кнопку Explain (Объяснение). «Узкие» места при использовании процессора При анализе производительности любого Web-приложения чаще всего контролируют загрузку процессора. Процессоры сервера выполняют сложные операции и поэтому логично, что источник проблем начинают искать с них. Общая информация об использовании процессора содержится в объекте Processor (Процессор), Основная цель мониторинга счетчиков, связанных с процессором, — выявление потенциальных «узких» мест на сервере. Как показывает практика, загрузку процессора следует ограничить значением в 75% для каждого из них, хотя в зависимости от природы приложения и типа его пользователей допустимы короткие всплески до 100%. Высокая загрузка процессора вызывает частые переключения контекста (обсуждаются далее), в результате чего растут накладные расходы. Поэтому, хотя система, возможно, и сможет работать при 90-процентной загрузке процессоров, пропускная способность при этом может быть неоптимальной по сравнению с загрузкой в 70-75%. Для многопроцессорных систем каждый процессор отображается з диалоговом окне Add Counters (Добавить счетчики) как отдельный экземпляр. Счетчик Total instance (Все экземпляры) позволяет также контролировать среднее значение для всех процессоров. В однопроцессорной системе системный монитор отображает обобщенный экземпляр и один экземпляр процессора — оба они соответствуют единственному процессору системы. Далее описаны счетчики, значения которых представляют интерес при поиске «узких» мест на уровне процессора. Мы также расскажем, как использовать счетчики объекта Processor (Процессор). •

% Processor Time (% загруженности процессора) —- доля времени, приходящаяся на исполнение процессором потоков,

Мониторинг производительности приложения

отличных от потока простоя. Для ее вычисления определяют время активности потока простоя на заданном интервале, которое затем вычитают из общей длительности интервала. (Поток простоя каждого процессора выполняется тогда, когда нет других готовых к исполнению потоков.) Этот счетчик считается основным индикатором активности процессора и отображает среднее значение времени занятости процессора на протяжении заданного интервала. Его значение вычисляют, вычитая значение, когда процессор неактивен, из ста процентов, • % Privileged Time {% работы в привилегированном режиме) — доля времени, приходящаяся на исполнение процессором кода в привилегированном режиме. При обращении к системному сервису Windows этот сервис часто исполняется в привилегированном режиме, чтобы получить доступ к закрытым системным данным. Эти данные защищены от потоков, исполняющихся в пользовательском режиме. Обращения к системе могут быть явными или неявными, такими, как страничные ошибки или прерывания. В отличие от некоторых старых операционных систем, в Windows помимо традиционной защиты на основе пользовательского и привилегированного режимов реализуется защита подсистем на уровне границ процессов. Часть действий, выполняемых Windows no запросу приложения, может исполняться в пользовательском режиме внутри процесса подсистемы, а не только в привилегированном режиме. •

% User Time (% работы в пользовательском режиме) — доля времени, приходящаяся на исполнение процессором кода в пользовательском режиме. Значение данного счетчика должно находиться в разумном соотношении со значениями счетчика % Privileged Time (% работы в привилегированном режиме) для объектов System (Система) и Processor (Процессор), так как это показатели времени активности и общей суммы времени активности.

• % Interrupt Time (% времени прерываний) — доля интервала измерений, приходящаяся на прием и обслуживание процессором аппаратных прерываний. Его значения косвенным образом показывают активность генерирующих прерывания

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

• Interrupts/sec (Прерываний в секунду) — средняя интенсив ность аппаратных прерываний процессора выраженная как количество случаев в секунду. Сюда не входят отложенные вызовы процедур (deferred procedure calls, DPC) — они учитываются отдельно. Счетчик показывает активность генерирующих прерывания устройств, таких, как системные часы, мышь, драйверы дисков, линии коммуникаций, сетевые платы и другие периферийные устройства. Обычно эти устройства прерывают процессор по завершении исполнения ими некоторой операции или когда им требуется обслуживание, Нормальное исполнение потоков при этом приостанавливается. Системные часы обычно генерируют прерывания каждые 10 миллисекунд, что составляет основной фон активности прерываний. Эффективность работы многопроцессорного компьютера может быть определена по значениям счетчиков из таблицы 4-1. Табл. 4-1. Счетчмкн для многопроцессорных компьютеров Счетчик

Описание

Process\ % Processor Time

Суммарное процессорное время для всех потоков процесса

Processor('_Total)\ % Processor Time

Отражает активность всех процессоров компьютера. Это среднее время активности всех процессоров за время наблюдений, деленное на число процессоров. Следует иметь в виду, что значение счетчика равно 50% и тогда, когда все процессоры занять! только на половине заданного интервала времени, и когда половина процессоров занята на протяжении всего интервала

Мониторинг производительности приложения

Решение типичных проблем, связанных с перегрузкой процессора «Узкие» места, связанные с использованием процессоров, возникают, когда количество активных потоков в системе или приложении превышает возможности процессоров. В результате запросы на исполнение потоков помещаются в очередь, и пока последняя не станет пустой, сохраняется высокая загрузка процессоров, что приводит к увеличению времени отклика системы. Если процессоры сервера постоянно сильно загружены (90% или более), то обычно это приводит к образованию очереди потоков, ожидающих выполнения, — это и есть «узкое» место. Такой постоянно высокий уровень загрузки процессоров неприемлем для сервера. Например, наблюдая производительность US-сервера, на котором расположен единственный Web-сайт, использующий приложение СОМ + , написанное на Visual Basic б, вы обнаруживаете, что приложение СОМ+ использует более 90% процессорного времени. Из-за подобной загрузки процессора снижается способность Web-приложения обрабатывать новые подключения к сайту. Определив тип «узкого» места (в данном случае оно связано с работой процессора) и его основную причину (интенсивно использующее процессор приложение), можно определить способ устранения проблемы. Например, физически отделить приложение СОМ+ от Web-сервера или преобразовать его в более эффективный и быстро работающий управляемый код.

ПРИМЕЧАНИЕ При исследовании загрузки процессора следует учитывать роль данного компьютера и типы выполняемых им работ. Высокая загрузка процессора на сервере базы данных менее желательна, чем на Web-сервере. Существует два способа ликвидации «узких» мест, связанных с процессором. Первый —установить на компьютер более быстрых или дополнительных процессоров. Однако, во-первых, это временная мера, и во-вторых, этот способ недешев. При следующем всплеске трафика на Web-сайте вам придется снова установливать дополнительное оборудование или заменять старые

Глава 4

серверы новыми и более быстрыми. Второй и более продуктивный способ — проанализировать программное обеспечение, чтобы выявить конкретный проце?сс или часть приложения, которые становятся виновником возникновения «узкого» места. Как правило, прежде чем покупать новые аппаратные средства, следует попытаться повысить производительность программного обеспечения. Помимо счетчиков объекта Processor (Процессор) в объекте System (Система) предусмотрены и другие, позволяющие выявить «узкие» места в использовании процессора.

Объект System Объект System (Система) и связанные с ним счетчики отражают сводную информацию по потокам, исполняемым процессором. Они дают важную информацию для определения обицей производительности системы. Далее перечислены наиболее важные счетчики. •

Processor Queue Length (Длина очереди процессора) — количество потоков в очереди процессора. В отличие от дисковых счетчиков (обсуждаемых далее в этой главе) данный счетчик учитывает только готовые, но не исполняющиеся потоки. В этом случае формируется только одна очередь потоков, ожидающих выделения им процессорного времени, даже на многопроцессорном компьютере. Таким образом, если в компьютере несколько процессоров, то показания счетчика следует разделить на их общее число. Одним из способов определения наличия в вашем приложении «узкого» места, связанного с процессором, является наблюдение за счетчиком System\Processor Queue Length- He уменьшающаяся длина очереди на фоне перегруженного (90% и выше) процессора — очевидный показатель наличия такого «узкого» места. При высокой загрузке процессора значение счетчика Processor Queue Length не должно быть равным 2 или более длительное время. Если же это так, когда процессор загружен мало, то скорее всего имеет место некая блокировка, а не «узкое» место. Кроме того, значение счетчика Processor1^ Interrupt Time (Процессор^ времени прерываний) косвенным образом свидетель-

Мониторинг производительности приложения

ствует о повышенной активности дисковых драйверов, сетевых адаптеров и других устройств, генерирующих прерывания; •

Context Switches/sec (контекстных переключений/сек) — это общая частота переключения с одного потока на другой для всех процессоров компьютера. Переключение контекста происходит, когда исполняющийся поток добровольно отдает процессор, когда он вытесняется готовым к исполнению потоком с более высоким приоритетом или при переключении контекста между пользовательским и привилегированным режимами для вызова сервиса Executive или подсистемы. Регистрируемое значение равно сумме числа переключений контекстов [Thread\Context Switches/sec (Поток\Контекстных переключений/сек)] по всем процессорам компьютера. V объектов System (Система) и Thread (Поток) предусмотрены счетчики переключения контекста. Они показывают разность значений двух последних измерений, деленную на интервал между измерениями. Система, в которой из-за неэффективного кода приложения или плохой системной архитектуры регистрируется частое переключение контекста, может потреблять очень много ресурсов. Ваша задача — в любом случае снизить объем переключений контекста на сервере приложения или базы данных. Фактически переключения контекста не дают серверу выполнять полезную работу, так как ресурсы процессора отвлекаются на обслуживание потока, который теперь не может выполняться, так как ожидает логического или физического ресурса либо приостановил свое исполнение. К симптомам частого переключения контекстов относятся низкая пропускная способность на фоне высокой загрузки процессора, которая возникает при уровне частоты переключений в 15 000 или выше. Чтобы определить, является ли частота переключения контекста чрезмерной, сравните ее со значением Processor\% Privileged Time (Процессор\% работы в привилегированном режиме). Если данный параметр равен 40% или более и частота переключения контекста высока, то самое время искать причину частого переключения контекста. Наконец, при мониторинге производительности системы следует убедиться в том, что значение счетчика $ystem\Context

Глава 4 Switches/sec, отражающего общесистемную частоту переключения контекста, разно или близко к значению счетчика Thread\Context Switches/sec для экземпляра _Total. Наблюдая за ними в течение длительного времени, вы выясните допустимый диапазон различий в их показаниях.

«Узкие» места при работе с диском Место на диске — это постоянная проблема. Независимо от того, сколько дискового пространства на ваших серверах, ваши программы его займут. Однако «узкие» места при работе с диском связаны со временем, а не с дисковым пространством. Диск тормозит работу, когда компоненты, выполняющие чтение или запись на диск, не способны угнаться за остальной частью системы. В отличие от объема дискового пространства другие компоненты дисковой подсистемы, в которых могут возникать «узкие» места, вряд ли можно назвать широко известными. Их несколько: шина ввода-вывода, шина устройства, контроллер диска и блок головок. Каждый из них способен ограничивать производительность. Системный монитор измеряет различные показатели физической и логической производительности диска. Для полноты картины использования ресурсов диска необходимо учитывать значения нескольких счетчиков, причем в отдельных случаях вам придется наблюдать за ними несколько дней. В результате, чтобы установить, является ли дисковая подсистема «узким» местом вашего сервера или нет, вам, возможно, придется выполнить некоторые математические расчеты. Подробно необходимые формулы описаны в приводимом далее примере. Однако прежде позвольте представить некоторые счетчики, необходимые при выявлении «узких» мест дисковой подсистемы. Их применение позволит вам выявлять проблемы, планировать увеличение возможностей дисковой подсистемы, а также измерять ее загрузку. Значения некоторых счетчиков потребуются в упомянутых выше формулах. * Average Disk Queue Length (средняя длина очереди диска) — среднее число запросов на чтение и запись, помещенных в очередь выбранного диска за указанный интервал времени. • Average Disk Read Queue Length (средняя длина очереди чтения диска) — среднее число запросов на чтение, помещен-

Мониторинг производительности приложения

ных в очередь выбранного диска за указанный интервал времени. • Average Disk Write Queue Length (средняя длина очереди записи диска) — среднее число запросов на запись, помещенных в очередь выбранного диска за указанный интервал времени. • Average Disk sec/Read [Среднее время чтения с диска (сек)] — среднее время считывания данных с диска (в секундах). • Average Disk sec/Transfer [Среднее время обращения к диска (сек)] — среднее время пересылки данных диска в секундах. • Disk Reads/sec (Обращений чтения с диска/сек) — частота операций чтения с диска. • Disk Writes/sec (Обращений записи на диска/сек) — частота операций записи на диск.

Как ACT Team выявила «узкое» место дисковой подсистемы Группе внутренних разработок Microsoft потребовалось оценить серверные аппаратные средства двух производителей. На серверах предполагалось размещать реляционную базу данных Webприложения, разрабатываемого этой группой. С Web-приложением одновременно должны были работать несколько тысяч пользователей; таким образом, для успеха проекта правильный выбор аппаратных средств имел решающее значение. Специалисты планировали провести несколько нагрузочных тестов и определить их влияние на использование ресурсов сервера базы данных. Для этого на Visual Basic было написано средство нагрузочного тестирования, моделирующее реальные условия работы приложения. Оно исполнялось клиентскими компьютерами, как Win32~npuлoжeнue. Для тестирования взяли сотню клиентских машин. Один экземпляр исполняющейся тестовой программы моделировал 5 пользователей, каждый из которых подключался к разным базам данных сервера (от db1 go db5). Производственный процесс использовал результаты исполнения клиентами посредством ADO или OSQL пакетных файлов SQL, соответствующих отдельным операциям. Пакетные файлы генерировались путем трассировки работы с сайтом пользователя-человека с

Глава 4

помощью SQL Profiler. В процессе тестирования выполнялись следующие операции: • загрузка страницы регистрации в системе; •

выбор имени пользователя и нажатие клавиши «ввод»;

•

загрузка страницы заданий;

•

предоставление менеджеру сведений о реальных временных затратах;

•

загрузка страницы просмотра ресурсов;

• установка и сохранение напоминаний; • передача задания другому ресурсу. Клиентские компьютеры настроили таким образом, чтобы во время теста выполнялись обращения ко всем пятистам базам данных. Это позволило избежать ситуации, когда на одну базу пришлось бы большинство транзакций. После настройки клиентских компьютеров запустили программу тестирования, которая работала в течение 20 минут (15 минут отводилось на «прогрев»). Далее 20 минут регистрировались показатели производительности сервера базы данных. В программе тестирования были заданы 10- и 60-секундные задержки при выполнении запросов к базам данных. Каждый моделируемый пользователь начинал свою работу спустя случайно выбранный промежуток времени от общего начала теста и выполнял одну операцию. Затем он ожидал 10 или 60 секунд и выполнял следующую операцию. В обоих сценариях значительные объемы времени расходовались на чтение и запись дисковых данных, что послужило поводом для исследования возможностей используемых дисковых подсистем. Расчеты показали, что число операций ввода-вывода превысило число, заявленное производителем как максимум, при котором диски еще обеспечивают хорошую производительность. Параметры производительности, собранные при выполнении тестов с 10- и 60 секундными задержками, указывали на наличие «узкого» места в дисковой подсистеме сервера 1. Чтобы проверить это, мы подсчитали значения полученных параметров активности физического диска;

Мониторинг производительности приложения

Кол-во операций а/в на 1 диск = [On. чтения + {4хОп. записи)] / Число дисков

Если бы рассчитанное число операций на один диск превзошло возможности сервера, то это доказало бы существование «узкого» места в дисковой подсистеме. Максимальные возможности дисков и результаты расчета числа операций на один диск приведены ниже. Заметьте, что показатель максимальных возможностей диска в конфигурации RAID 5 во всех расчетах равен 85 операциям ввода-вывода на один диск. Сценарий с 10-секундным временем ожидания для сервера 1. Возможности диска = 85 операций ввода-вывода на один диск Рассчитанное число операций на 1 диск = [269,7 + (4x74,6) ] / 5 Рассчитанное число операций на 1 диск = 113,62 операций на один диск

При значении 113,62 операций на один диск на сервере 1 возникает «узкое» место в дисковой подсистеме, так как возможности последней равны 85 операциям на один диск. Сценарий с 10-секундным временем ожидания для сервера 2. Возможности диска = 85 операций ввода-вывода на один диск Рассчитанное число операций на 1 диск = [136,3 + (4x43,0)] / 4 Рассчитанное число операций ча 1 диск = 77,7 операций на один диск

Загрузка в 77,7 операций на один диск меньше возможностей дисковой подсистемы сервера 2, равной 85 операциями на один диск, так что «узкое» место в данном случае не возникает, Сценарий с 60-секундным временем ожидания для сервера 1. Возможности диска = 85 операций ввода-вывода на один диск Рассчитанное число операций на 1 диск = [294,8 + (4x71,8) ] / 5 Рассчитанное число операций на 1 диск = 116,4 операций на один диск

При уровне в 116,4 операции на один диск на сервере 1 возникает «узкое» место в дисковой подсистеме, так как ее возможности — всего 85 операций на один диск.

Глава 4

Сценарий с 60-секундным временем ожидания для сервера 2. Возможности диска = 85 операций ввода-вывода на один диск Рассчитанное число операций на 1 диск = [68.9 + (4x24.0) ] / 4 Рассчитанное число операций на 1 диск = 41.2 операций на один диск Загрузка в 41,2 операции на один диск значительно ниже возможностей дисковой подсистемы сервера 2, равной 85 операциями на один диск, так что «узкое» место в данном случае не возникает. При числе операций на один диск, равным Т13,62 и 116,4 соответственно, на сервере 1 возникает «узкое» место, так как его возможности, по данным производителя, выдерживают лишь нагрузку в 85 операций ввода-вывода на один диск.

Влияние архитектуры дисковой подсистемы на производительность Многие современные Web-приложения взаимодействуют с сервером базы данных. Если не все, то многие из протестированных нами приложений использовали SQL Server 2000, и в большинстве случаев нам удавалось добиться значительного прироста производительности за счет настройки сервера базы данных. Этот прирост достигался за счет оптимизации SQL-кода, схемы базы данных или параметров использования дисков. При проектировании архитектуры базы данных вам потребуется определить, каким образом данные и журналы будут считываться и записываться на диск. Например, записывать ли журнал на RAIDустройство или на обычное? Если ваш выбор окажется неправильным, то в дисковой подсистеме возникнет «узкое» место. В одном из таких случаев мы смогли доказать наличие или отсутствие «узкого» места с помощью формул. Подробности данного проекта и использованные формулы описаны в приведенном выше примере.

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

Мониторинг производительности приложения

системного монитора имеются и другие средства анализа использования памяти. Возможно, вам следует их изучить, так как они позволяют сократить необходимое время мониторинга системы.) • Page faults/sec (Ошибок страницы/сек) —- среднее число страничных ошибок в секунду. Оно измеряется как число страниц в секунду, при обращении к которым произошла ошибка, и так как при каждом таком обращении затронута только одна страница, то это число равно числу обращений, вызвавших страничные ошибки. Счетчик регистрирует как «жесткие» (требующие обращения к диску) ошибки, так и «мягкие» (когда страница может быть найдена в памяти). Большинство процессоров способны обрабатывать большое число «мягких» ошибок без существенных последствий. Однако «жесткие» ошибки, требующие обращения к диску, вызывают значительные задержки. •

Available Bytes (Доступно байт) — указывает количество байт памяти, доступных процессу в данный момент. Счетчик Pages/ sec (Обмен страниц/сек) отражает количество страниц, которые либо считываются с диска из-за «жестких» страничных ошибок, либо записываются на диск для освобождения рабочего набора процесса из-за страничных ошибок.

•

Pages Reads/sec (Чтений страниц/сек) — частота повторной загрузки страниц с диска для обработки страничных ошибок. Счетчик показывает число операций без учета числа страниц, загруженных о результате каждой из них. «Жесткая» ошибка возникает при обращении процесса к странице виртуальной памяти, которая в данный момент отсутствует в рабочем наборе или другом месте физической памяти и должна быть считана с диска. Этот счетчик — основной для регистрации страничных ошибок, которые вызывают общесистемные задержки. Он включает как операции считывания страниц из кэша файловой системы (обычно по запросу приложений), так и операции считывания из некэшированных файлов, отображаемых в память. Чтобы определить среднее число страниц, считываемых за одну операцию, сравните значение Метоry\Page$ Reads/sec со значением Memory\Pages /nput/sec (Память\Ввод страниц/сек).

Глава 4

•

Pages writes/sec (Запись странии/сек) — частота, с которой страницы записываются на диск для освобождения места в памяти. На диск записываются только измененные страницы, так что они, скорее всего, содержат данные, а не код. Этот счетчик показывает число операций, не учитывая число страниц, записанных в результате каждой из них. Оно равно разности между двумя последовательными измерениями, деленной на интервал между ними.

•

Pages/sec (Обмен страниц/сек) — частота считывания страниц с диска и записи их на диск в результате обработки страничных ошибок. Этот счетчик — основной для регистрации страничных ошибок, вызывающих общесистемные задержки, Он показывает сумму значений Memory\Pages Input/sec (Память\Ввод страниц/сек) и Memory\Pages Output/sec (Память\Вывод страниц/сек). Значение измеряется в числе страниц, поэтому его можно напрямую сравнивать со значениями других счетчиков страниц, таких, как Memory\Page Faults/sec (Ошибок страницы/сек). Он включает как операции считывания страниц из кэша файловой системы (обычно по запросу приложений), так и операции считывания из не кэширозанных файлов, отображаемых в память.

Как ACT Team выявила утечку памяти На данном примере мы покажем, как нам удалось определить утечку памяти в приложении, переданном нашей группе на тестирование производительности. Наш аналитик встречался с разработчиками с целью определения стандартных пользовательских сценариев данного Web-приложения. Разработчиков беспокоило использование памяти приложениями COM-f, исполняющимися на Web-сервере. Аналитик пришел к выводу, что лучший способ выявления проблем использования памяти — провести серию нагрузочных испытаний. На основании предоставленных разработчиками сценариев поведения пользователей были созданы сценарии тестирования. При выполнении короткого нагрузочного теста в журналы производительности записывалось использование ресурсов сервера, на котором были размещены приложения СОМ+. Во время этого часового тестирования аналитик наблюдал потребление памяти в объемах около 20 Мбайт. Он

Мониторинг производительности приложения

обратил внимание на то, что и через три часа после прекращения теста эта память не была освобождена. Данные наблюдения послужили поводом к дальнейшим исследованиям потребления памяти приложением (табл. 4-2). Для анализа работы приложения с памятью был выполнен 12-часовой непрерывный нагрузочный тест. В результате обнаружилось, что помимо высокой активности процессора за время теста значительно увеличился объем, выделенной приложению памяти, а объем свободной виртуальной памяти сервера стал крайне мал (табл. 4-3}. Через три часа после окончания теста из 671 Мбайт памяти, выделенных dIIhost, 640 Мбайт no-прежнему не были освобождены. Все выглядело таким образом, что основной расход виртуальной памяти приходился на удовлетворение запросов процесса dllhost. В течение часового теста объем выделенной памяти возрос лишь в пределах с 38 до 59 Мбайт. При 12-часовом тесте рост оказался значительно выше — от 368 до 671 Мбайт, Память не освобождалась до тех пор, пока сервер не перезагрузили. Далее процесс dllhost проанализировали с целью определить процессы, деятельность которых вызвала его работу, и выявить конкретный процесс, отвечающий за утечку памяти. Когда такой процесс был установлен, профилирование его кода позволило разработчику точно определить место в программе, где работа с памятью велась неправильно. Конечно, при использовании управляемого кода, не возникает такое количество проблем управления памятью, как для неуправляемого кода. Табл. 4-2. Результаты часового теста ~ Среднее-MS

~ Максимум / Bcero-IIS

5ystem-% общего времени процессора

55%

1 00%

lnetinfo-% общего времени процессора

0,5%

Dllhost-% общего времени процессора

41%

1 00%

Память: доступно

1 64 Мбайт

1 85 Мбайт

Windows 2000 IIS 5.0

Память: страниц/сек

0,2

Процесс Inetinfo: выделено памяти

14 Мбайт

1 4 Мбайт

Процесс Dllhost: выделено памяти

38 Мбайт

56 Мбайт

100

Глава 4

Таблица 4-3. Результаты 12-часового теста Windows 2000 IIS 5.0

~ Среднее-US

5ystem-% общего времени процессора lnetinfo-% общего времени процессора Dllhost-% общего времени процессора Память: доступно Память: странии/сек Процесс Inetinfo: выделено памяти Процесс Dllhost: выделено памяти

69%

- Максимум / Bcero-IIS

0,6%

100% 1,5%

71%

100%

56 Мбайт

196 Мбайт

295

14Мбайт 368 Мбайт

14.4 Мбайт 671 Мбайт

При поиске утечек памяти следует работать со счетчиками Memory\Avaliable bytes (Память\Доступно байт}/ Process\Private Bytes (Процесс\Байт исключительного пользования) и Ргосess\ Working Set (Процесс\Рабочее множество). Обычно при наличии утечки памяти возрастают значения Proces$\Private Bytes и Process\ Working Set, а значение Memory\Avaifable bytes снижается. В этом позволяет убедиться Диспетчер задач: достаточно определить PID и наличие его связи с вашим приложением. При проверке на наличие утечек памяти тест производительности необходимо выполнять длительное время, чтобы установить реакцию приложения в условиях истощения доступной памяти.

Создание и настройка оповещений Сервис Performance Logs and Alerts (Оповещения и журналы производительности) применяют для генерации оповещений о наступлении заданных событий, связанных с производительностью. Например, можно так настроить оповещение о падении объема доступной памяти Web-сервера ниже 20 Мбайт, чтобы оно: • вносило записи з журнал событий приложений; •

отправляло сетевое сообщение заданному пользователю;

•

генерировало журнал параметров производительности;

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

Мониторинг производительности приложения

101

исходит с памятью Web-серзера. Вы можете создать оповещение, выводящее в журнал событий приложений запись всякий раз, когда происходит всплеск показаний счетчика Pages/Sec (Обмен странии/сек). Таким образом, вам не придется вручную отыскивать всплески в огромном журнале производительности. Вы легко выделите их из журнала событий, просто отфильтровав. Оповещение создается следующим образом. 1. Откройте Системный монитор, для чего щелкните Start (Пуск), выберите Programs (Программы), выберите Administrative Tools (Администрирование) и щелкните Performance (Системный монитор). 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности), затем щелкните Alerts (Оповещения). На правой панели отобразится список ранее определенных оповещений, если они есть. Зеленый значок означает, что оповещение активизировано, красный — что оно отключено, 3. Щелкните правой кнопкой пустое место на правой панели и выберите New Alert Settings (новые параметры оповещений). 4. В поле Name (Имя) введите название оповещения, затем щелкните ОК. 5. Комментарий к оповещению, а также счетчики, пороги срабатывания и интервал измерений задается на вкладке General (Общие). Чтобы указать действия, которые необходимо выполнить при срабатывании сигнала, перейдите на вкладку Action (Действие), а для определения расписания слежения за условиями срабатывания воспользуйтесь возможностями вкладки Schedule (Расписание).

ПРИМЕЧАНИЕ Для создания или изменения конфигурации журнала зам потребуется полный доступ к следующему подразделу реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\SysmonLog\Log Queries Обычно администраторы имеют такой доступ по умолчанию. Они вправе предоставить его другим

102

Глава 4

пользователям через меню Security программы Regedt32.exe. Кроме того, для запуска сервиса Performance Logs and Alerts (который устанавливается одновременно с ОС и исполняется в фоновом режиме) вам потребуются права на запуск и настройку системных сервисов. Администраторам такие права даны по умолчанию, и они могут предоставить их другим пользователям посредством групповых политик. ВНИМАНИЕ Некорректное изменение содержимого реестра способно нанести серьезный урон вашей системе. Прежде чем редактировать реестр, сделайте резервные копии всех важных данных, которые хранятся на компьютере. Чтобы задать для оповещений счетчики и пороги срабатывания, выполните следующие действия. 1.

Откройте системный монитор.

2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности), а затем щелкните Alerts (Оповещения). 3. Дважды щелкните строку оповещения в правой панели. 4. В поле Comment (Комментарий) введите описание оповещения. 5. Щелкните Add (Добавить). Для каждого счетчика или группы счетчиков, которые нужно добавить в журнал, выполните следующие действия. 1. Для мониторинга счетчиков компьютера, на котором будет исполняться сервис Performance togs and Alerts (Оповещения и журналы производительности), щелкните Use Local Computer Counters (Использовать локальные счетчики). В противном случае для мониторинга счетчиков на заданном компьютере независимо от того, где будет исполняться сервис, щелкните Select Counters From Computer (Выбрать счетчики с компьютера) и укажите имя компьютера. 2. Выберите подлежащий мониторингу объект производительности.

Мониторинг производительности приложения

103

3. Выберите один или несколько связанных с объектом счетчиков. 4. Для мониторинга всех экземпляров выбранных счетчиков щелкните All Instances (Все вхождения) (двоичные журналы могут содержать информацию об экземплярах, которые не были доступны сначала, но появились впоследствии). В противном случае для наблюдения за конкретными экземплярами выбранных счетчиков щелкните Select Instances From List (Выбрать вхождения из списка) и затем выберите нужный экземпляр или экземпляры. 5. Щелкните Add (Добавить). 6. В Alert When The Value Is (Оповещать когда значение) выберите Under (Меньше) или Over (Больше), а в поле Limit (Порог) укажите пороговое значение срабатывания. 7. В поле Sample Data Every (Снимать показания каждые) укажите величину и единицу измерения интервала обновления данных. 3. Завершите настройку оповещения с помощью вкладок Action (Действие) и Schedule (Расписание).

ПРИМЕЧАНИЕ При создании консоли мониторинга для экспорта обязательно выбирайте Use Local Computer Counters (Использовать локальные счетчики). В противном случае данные будут собираться с компьютера с указанным именем независимо от того, где установлен файл консоли. Чтобы настроить оповещения, выполните следующие действия. 1. Откройте системный монитор. 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности), а затем щелкните Alerts (Оповещения). 3. Дважды щелкните строку оповещения в правой панели. 4. Щелкните вкладку Action (Действие). 5. Для генерации записи, просматриваемой с помощью Event Viewer (Просмотр событий), выберите Log An Entry in the Application Event Log (Сделать запись в журнале событий приложения).

104

Глава 4

6. Для отправки сообщения посредством сервиса Messenger выберите Send a Network Message to {Послать сетевое сообщение) и введите название компьютера, на котором будет отображено сообщение. 7. Для запуска журнала регистрации счетчика при оповещении выберите Start Performance Data Log (Запустить журнал производительности) и укажите нужный журнал. 8. Для запуска программы при срабатывании сигнала тревоги выберите Run This Program (Запустить программу) и введите путь и имя файла либо щелкните Browse (Обзор) для поиска файла. При срабатывании сигнала сервис создаст процесс и запустит указанный командный файл. Вы также можете задать параметры командной строки программы. Для этого щелкните Command Line Arguments (Аргументы командной строки! и выберите соответствующие флажки параметров командной строки. Чтобы вручную запустить или остановить журнал счетчика, журнал трассировки или оповещение, выполните следующие действия. 1. Откройте системный монитор. 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности), затем щелкните Counter Logs (Журналы счетчиков), Trace Logs (Журналы трассировки) или Alerts (Оповещения). 3. На правой панели щелкните правой кнопкой название нужного журнала или сигнала, затем щелкните Start (Пуск) для запуска генерации журнала или мониторинга сигнала тревоги либо Stop (Стоп) для остановки.

ПРИМЕЧАНИЕ Прежде чем журнал или сигнал стартует или остановится, возможна небольшая задержка, которая заметна по изменению цвета значка (с зеленого на красный при остановке или наоборот). Для удаления счетчиков из описания журнала или сигнала тревоги выполните следующие действия.

Мониторинг производительности приложения

105

1. Откройте системный монитор. 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности), затем щелкните Counter Logs (Журналы счетчиков), Trace Logs (Журналы трассировки) или Alerts (Оповещения). 3. Дважды щелкните на правой панели название оповещения или журнала. 4. В списке Counters (Счетчики) выберите счетчик, который хотите удалить, затем щелкните Remove (Удалить). Для просмотра или изменения параметров журнала или оповещения выполните следующие действия. 1. Откройте системный монитор. 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности). 3. Щелкните Counter Logs (Журналы счетчиков), Trace Logs (Журналы трассировки) или Alerts (Оповещения) 4. Дважды щелкните на правой панели название оповещения или журнала. 5. Просмотрите или измените параметры журнала или оповещения. Чтобы определить условия запуска или остановки журнала или оповещения, выполните следующие действия. 1. Откройте системный монитор. 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности}, затем щелкните Counter Logs (Журналы счетчиков), Trace Logs (Журналы трассировки) или Alerts (Оповещения). 3. Дважды щелкните на правой панели название оповещения или журнала. 4. Щелкните вкладку Schedule (Расписание). 5. В разделе Start log (Запуск наблюдения) выберите одну из следующих опций; • для активизации журнала или сигнала вручную щелкните Manually (Вручную). Если выбрана данная опция, то для старта журнала или активизации сигнала щелкните назва-

106

Глава 4 ние журнала на правой панели и затем выберите Start (Пуск); • для активизации журнала или сигнала в указанное время щелкните At (Время) и укажите время и дату.

6. В разделе Stop Log (Запуск наблюдения) выберите одну из следующих опций: • для остановки журнала или сигнала вручную щелкните Manually (Вручную). Если выбрана данная опция, то для остановки журнала или оповещения щелкните название журнала на правой панели и затем выберите Stop (Стоп); • для остановки журнала или оповещения по истечении заданного интервала времени щелкните After (Через) и укажите число единиц времени, а также тип этих единиц (дни, часы и т.д.); • для остановки журнала или оповещения в указанное время щелкните At (Время) и укажите время и дату (год задается четырьмя цифрами, остальные параметры — двумя.; • для прекращения генерации журнала, когда файл журнала заполнится: о для журнала счетчика щелкните When the Log File is Full [Когда файл журнала заполнен). Данные будут записываться в файл до достижения им размеров, указанных вами на вкладке Log Files (до 2 Гбайт); о для журнала трассировки щелкните When the n-MB Log File is Full (Когда файл журнала заполнен). Данные будут записываться в файл до достижения им размеров, указанных вами на вкладке Log Files (в Мбайт). 7. Задайте другие необходимые параметры журналов и оповещений (при этом учитывайте доступный объем дискового пространства и размеры дисковых квот; если в результате генерации журнала пространство на диске будет исчерпано, то произойдет ошибка): • для журналов выберите в разделе When a Log File Closes (Когда файл журнала будет закрыт) нужный сценарий закрытия журнала:

Мониторинг производительности приложения

107

о для создания циклического (постоянного, автоматического) журнала счетчиков или трассировки выберите Start a New Log File (Начать новый файл журнала); о для запуска программы по завершении журнала (например, команды копирования завершенных журналов на архивный компьютер) выберите Run This Command (Выполнить команду). Введите путь и имя нужной программы или щелкните Browse (Обзор) для ее поиска; • для оповещений з разделе When An Alert Scan Finishes (Когда наблюдение за оповещением будет закончено) выберите Start a New Alert Scan (Начать новое наблюдение), если требуется постоянный мониторинг условий оповещения. Чтобы удалить журнал или оповещение тревоги, выполните следующие действия. 1. Откройте системный монитор. 2. Дважды щелкните Performance Logs and Alerts (Оповещения и журналы производительности). 3. Щелкните Counter Logs (Журналы счетчиков), Trace Logs (Журналы трассировки) или Alerts (Оповещения). 4. На правой панели щелкните правой кнопкой название журнала или оповещения и выберите Delete. Опция открытия нового файла журнала недоступна, если вы выбрали режим закрытия журнала в определенный момент (дата и время) или закрываете его вручную.

Заключение В этой главе мы рассмотрели приемы использования системного монитора для тестирования производительности и выявления «узких» мест на системном уровне. Вы узнали о некоторых объектах и счетчиках, мониторинг которых позволяет отыскать «узкие» места. Умение работать с системным монитором совершенно необходимо для успешного тестирования и анализа характеристик производительности.

Глава 5

Способы анализа производительности работы Web-приложений в сети не зависят от операционной системы (Microsoft Windows NT, Windows 2000 и Windows XP), технологий разработки (статический HTML, ASP, Windows DMA, а теперь и .NET) и доступа к данным (RDO, ADO или ADO.NET). Причина такого постоянства кроется в том, что основной протокол, используемый для Интернет-коммуникаций, остается все тем же —TCP/IP. С появлением .NET и понятия о программе, как о сервисе, эти способы можно применять для выявления связанных с сетью «узких» мест и повышения сетевой производительности как старых приложений, так и разработанных на основе ,NIET Framework.

Проведение анализа сетевой производительности приложения Многие пользователи no-прежнему подключаются к Интернету посредством модемов, обеспечивающих крайне малые скорости передачи данных, и в обозримом будущем ситуация вряд ли изменится. Задача анализа сетевой производительности приложения — выявить медленно работающие страницы или код и внести изменения, чтобы пользователю было комфортнее работать с приложением. Мы полагаем, что вы знакомы с основами вычислительных сетей, например с моделью OSI (Open Systems Interconnection), но вряд ли вы столь же хорошо знаете основы

Анализ производительности работы в сети

109

анализа сетевой производительности. Поэтому прежде чем углубиться в описание процесса анализа сетевой производительности, мы познакомим вас с необходимыми терминологией и концепциями. Если вы встретите в этой главе незнакомые термины, рекомендуем книгу Mitch Tullock «Microsoft Encyclopedia of Networking, Second Edition» (Microsoft Press, 2002). Вам также следует ознакомиться с вопросами, которые чаще всего задают авторы тестируемых приложений. Среди них могут оказаться, например, такие: «Какое влияние на моих удаленных пользователей окажут сетевые задержки (network latency)?», «Что такое сетевой обмен (round trip) и как это влияет на удобство работы моих пользователей?», «Как мне определить объем передаваемых данных для каждого страничного просмотра (page view) и другого содержимого (content), загружаемого пользователями при работе с моим Web-приложением?», «Мои пользователи жалуются на большое время отклика. Что мне делать?», «Как мне выявить и устранить задержки обработки (processing delay) на моем IIS-сервере или SQL-сервере?» В этой главе мы ответим на подобные вопросы, а также дадим определения приведенных выше терминов и представим примеры, демонстрирующие сущность этих понятий и их влияние на производительность приложения. Мы также расскажем немного об инструментах анализа сетевой производительности: Microsoft Network Monitor и Compuware Application Expert.

ПРИМЕЧАНИЕ Мы используем термин просмотр страницы для обозначения самой страницы вместе со связанными с ней с элементами или файлами. Например, когда мы говорим об Default.aspx, то подразумеваем сам этот файл и сопутствующие ему файлы изображений, таблиц стилей (style sheet), сценариев Java и т. д. Сетевые задержки Проще всего определить сетевую задержку как время, требуемое пакету данных для перемещения по сетевому соединению. Чем меньше задержка между элементами вашего Web-приложения, тем меньше время отклика. Задержки и полоса пропускания

110

Глава 5

(bandwidth) — это два фактора, в основном влияющие на скорость сетевого соединения. Чтобы узнать сетевую задержку между клиентом и Web-приложением, воспользуйтесь утилитой pathping или другими утилитами, подобными средству Visual Trace Route, предоставляемому Application Expert. Презентация Compuware Application Expert в формате Microsoft Power Point находится на прилагаемом к книге компакт-диске.

ПРИМЕЧАНИЕ Программа pathping — это утилита командной строки, объединяющая возможности утилит ping и tracert. Чтобы воспользоваться ею, откройте окно командной строки и введите pathping имя_сервера. На экране отобразятся узлы сети между вами и сервером, а также задержка или время сетевого обмена для каждого узла. Любое соединение по локальной или глобальной сети ограничено сетевыми задержками. К факторам, увеличивающим задержки, относятся плохое качество сетевых устройств, большие расстояния, приводящие к увеличению промежуточных узлов и устройств на пути пакетов, а также перегрузки в сети. Например, задержка типичного локального соединения, установленного посредством 56-килобитного модема, может составить 200 миллисекунд, тогда как при увеличении расстояния, когда данным придется преодолеть множество сетевых устройств, задержка вырастет до 500 миллисекунд. В табл. 5-1 показано влияние сетевых задержек, измеренных с помощью Network Monitor, при запросе 46-килобайтной домашней страницы IBuySpy из браузера Microsoft Internet Explorer. Результаты измерений были импортированы в Response Time Predictor приложения Application Expert, что позволило нам экстраполировать времена отклика на случаи 200-миллисекундной и 500-миллисекундной задержки для модемного соединения со скоростью 56 кбит/с. Подробнее это и другие средства Application Expert мы рассмотрим далее в разделе «Работа с Application Expert фирмы Compuware». В данном случае дополнительная 300-миллисекундная задержка увеличивает время отклика не на 300-миллисекунд, а на 2,5 секунды. Это связано с тем, что задержка оказывает влияние на каждый сетевой обмен.

Анализ производительности работы в сети

111

Табл. 5-1. Задержка и время отклика Скорость соединения

Задержка, мс

Время отклика, '.

1 0 Мбит/с

0,5

56 кбит/с

200

56 кбит/с

500

8,5

ПРИМЕЧАНИЕ Один из способов борьбы с задержками — размещение Web-приложения в географической близости от его пользователей. Это не гарантирует лучшее соединение между пользователями и Web-приложением, но обычно сокращает задержки. Сетевые обмены Сетевой обмен — это генерируемая приложением пара «запрос — ответ» между клиентом и сервером. Запрос, посылаемый Web-браузером Web-серверу, и отправляемый обратно ответ, составляют один сетевой обмен. Когда вы вводите в браузере URL, например http://www.rnicrosoft.com, каждая картинка, таблица стилей или другой элемент страницы, отправляемый в отзет на ваш запрос, составляют отдельный сетевой обмен. Дополнительные обмены происходят при установлении каждого соединения с Web-сервером. Далее в этой главе мы обсудим, как, применив Application Expert, можно быстро получить число сетевых обменов, требуемых вашими ASP-страницами. В сочетании с задержками количество сетевых обменов оказывает огромное влияние на время отклика приложения. Представьте себе, что ваши US-серверы расположены на западном и на восточном побережьях США. Вы находитесь в Калифорнии, и для загрузки ASPXстраницы входа в приложение IBuySpy с сервера на западном побережье требуется 4 секунды, тогда как на загрузку ее с сервера восточного побережья — 6,5 секунд. Дальнейшие исследования показывают, что задержка в соединении с сервером восточного побережья составляет 500 миллисекунд, а западного — 200 миллисекунд. Так как сетевая задержка вносит свой вклад в каждый сетевой обмен, то отклик с восточного побережья идет примерно на 2 секунды дольше.

112

Глава 5

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

Уменьшение числа сетевых обменов Самым эффективным методом уменьшения числа сетевых обменов считается сокращение числа объектов на странице. В табл. 5-2 приведены данные для домашних страниц двух крупнейших поисковых Интернет-сайтов, которыми вам, вероятно, приходилось пользоваться. В первом случае на домашней странице всего шесть объектов, и она загружается очень быстро. На второй странице размещено около 15 объектов, и ее загрузка занимает гораздо больше времени. Обратите внимание на разное число сетевых обменов, необходимых для загрузки этих страниц. Табл. 5-2. Влияние количества объектов на странице на число сетевых обменов Сайты

Число объектов

Число обменов

Поисковый сайт 1 (оптимизированный)

Поисковый сайт 2 (медленный)

На первом сайте удалось снизить число объектов до шести, что обеспечило менее чем 10-секундное время отклика для большинства соединений на скорости 56 кбит/с. Для уменьшения числа объектов на домашней странице этого сайта размещена одна большая картинка, состоящая из восьми изображений. Так как один сетевой обмен требуется для загрузки каждого объекта, то, объединив восемь небольших изображений в один запрос, удалось избежать семи обменов.

Передаваемые данные Передаваемые данные — это объем информации, перемещенной между Web-браузером клиента и Web-сервером, обычно измеряемый в килобайтах, Наилучший способ измерения передаваемых данных — разбиение сценариев работы пользователя с вашим приложением на просмотры страниц вместе со связанными с ними элементами. Например, при первом обращении к до-

Анализ производительности работы в сети

113

машней странице IBuySpy передается 46 килобайт некэшированных и 24 килобайта кэшированных данных (при последующих запросах многие объекты будут загружаться из кэша вашего браузера, расположенного во временном каталоге браузера на вашем компьютере). Наш опыт показывает, что допустимое время отклика достигается, когда объем данных, передаваемых при просмотре страницы и связанных с ней элементов, не превышает 50 килобайт. Это дает максимальные шансы получить короткое время отклика для низкоскоростных Интернет-соединений, типа 56-килобитных модемов. Говоря об объеме данных, в этой главе мы используем пару терминов — килобиты в секунду и килобайты передаваемых данных. Для лучшей иллюстрации связи между этими метриками в табл. 5-3 показаны соотношения между битами и байтами, килобитами и килобайтами и килобайтами и мегабайтами, Табл. 5-3. Преобразование мер Измеренное значение

Преобразованное значение

8 бит 1 килобайт

1 байт 1024 байта

1024 килобайта

1 мегабайт

Уменьшение объема передаваемых данных Разработано несколько методов снижения объемов данных, передаваемых между Internet Explorer и IIS, например сжатие средствами IIS, удаление лишних символов и пустых промежутков, уменьшение числа объектов на странице и оптимизация картинок. Сжатие HTTP — это встроенное средство IIS и Internet Explorer. Оно хорошо работает в случае статического содержимого, такого, как НТМ-файлы, HTML-файлы, С55-файльи5-файлы и несжатые картинки. Однако с динамическим содержимым может возникнуть ряд проблем, в том числе неправильное отображение страницы или потеря ее функциональных возможностей. Сжатие также связано с дополнительными расходами ресурсов сервера IIS. По умолчанию сжатие HTTP отключено, его можно активизировать на вкладке Services WWW Service Master Properties, показанной на рис. 5-1.

114

Глава 5

Рис. 5-1. Активизация средств сжатия данных IIS Активизировав сжатие HTTP, не забудьте задать типы файлов, подлежащих сжатию, путем редактирования метабазы. Далее показано, как следует изменить содержимое метабазы для сжатия статических файлов TXT, )5, CSS, DOC и XLS files; 1. активизируйте сжатие HTTP, как показано на рис. 5-1; 2. откройте окно командной строки и перейдите в папку adminscripts; 3. выполните команду: cscript.exe adsutil.vbs set WSSvc/Filters/ Compression/GZIP/HcFileExtensions "txt" "js" "ess" "doc" "xls"; 4. выполните команду: cscript.exe adsutil.vbs set W3Svc/Filters/ Compression/DEFLATE/HcFileExtensions "txt" "js" "ess" "doc" "xls"; 5. выполните команду: iisreset.exe /restart. Другой метод уменьшения объема передаваемых данных подразумевает удаление избыточных символов и пустых промежутков, Особенно значительный эффект достигается в циклах, при передаче клиенту больших объемов данных. Кроме того, многие разработчики помещают в свой код комментарии, что добавляет на страницу дополнительные символы и строки и увеличивает объем передаваемых данных. Сокращение числа объектов на странице уменьшает объем передаваемых данных. Многие сайты используют картинки для

Анализ производительности работы в сети

115

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

ПРИМЕЧАНИЕ Если вы хотите максимально сократить размеры своих страниц, используйте короткие имена переменных и файлов, а также «плоскую» структуру каталогов. Это немного уменьшит объем передаваемых данных, так как клиенту будет отсылаться меньше текста. Картинки делают Web-сайт более привлекательным внешне, но их применение связано со значительными расходами. Если возможно, работайте только с картинками в формате GIF (Graphics Interchange Format). Использование оптимизированных или сжатых картинок снизит объем передаваемых данных, причем чаще всего при сохранении качества изображения. Большинство высококлассных программ создания изображений содержат средства оптимизации и сжатия файлов картинок. Используйте одни и те же файлы для хранения изображений логотипа вашей компании, панелей навигации и других картинок, повторяющихся по всему приложению. Обязательно указывайте одни и те же путевые имена, иначе Internet Explorer будет считать эти картинки разными. После первого выполнения запроса Internet Explorer кэширует картинки на локальном компьютере. Другой вариант загрузка картинок с использованием JavaScript. При этом картинки загружаются в фоновом режиме одновременно с остальными элементами страницы. Последующие запросы к кэшированным картинкам будут выполняться быстрее с точки зрения конечного пользователя, так как Internet Explorer сохраняет картинки локально.

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

116

Глава 5

Задержки обработки Задержки обработки возникают, когда запрос клиента проводит слишком много времени на промежуточном или серверном уровне приложения. Причиной может быть плохо написанный код, исполнение которого занимает несколько секунд, или недостаточная настройка SQL-запросов и неправильная индексация, вызывающие длительное исполнение хранимых процедур и других SQL-команд. Задержки обработки непосредственно влияют на время отклика. Мы обычно считаем нормой задержки более 1 секунды. Однако стандарты вашего приложения могут быть как более, так и менее строгими в зависимости от параметров — типа приложения и размеров пользовательской аудитории. Например, если приложение генерирует большие отчеты для группы аналитиков, состоящей всего из нескольких человек, то допустимо большое время отклика. Это объясняется тем, что длинные отчеты могут зачастую дольше обрабатываются сервером базы данных, а для небольшой пользовательской аудитории наверняка существуют бюджетные ограничения, в результате чего не удастся максимально оптимизировать приложение. Однако, если пользовательская аудитория велика и состоит из покупателей, заказывающих ваши товары, вам следует максимально оптимизировать время отклика. Иначе возможно падение продаж по причине недовольства пользователей из-за медленной работы приложения.

Сокращение задержек обработки Наиболее распространенный способ сокращения времени отклика приложения — уменьшение задержек обработки. Для этого требуется ускорить медленно работающие ASPX-страницы, управляемый код или SQL-запросы. Подробнее об этом рассказано в разделах данной книги, посвященных MS, управляемому коду и SQL. Далее в разделе «Выявление задержек обработки в приложении» мы рассмотрим, как с помощью Network Monitor или Application Expert определить, имеются ли задержки обработки на заших страницах и на каком уровне приложения они возникают, Необходимо определить место кода приложения, в котором происходит задержка. Для этого разработано несколько методов:

Анализ производительности работы в сети

117

в приложениях .NET вы можете включить трассировку для ASPX-страниц. При обращении к такой ASPX-странице из браузера статистика и временная информация отобразится внизу страницы. Для включения трассировки на уровне страницы добавьте директиву Тгасе="Тгие", как показано на рис. 5-2;

<iS Register TsefEefis'-ISuySpi" 7«*М«ие-«Веас1ев" 9Ео-"_Н*ш*ег.

Рис. 5-2. Включение трассировки ASPX-страниц • в коде стандартных ASP-приложений для выявления проблем можно использовать таймеры. Просто вставьте таймерные переменные по тексту ASP-сценария и выведите их значения з текстовый файл. Данный метод профилирования позволяет идентифицировать место задержки с точностью до функции или строки кода. На прилагаемом компакт-диске содержатся примеры измерения временных параметров для VBScript и JScript — ACETimerVB.doc и ACETimerJS.doc. Очень часто такие задержки связаны с вызовом неэффективно написанного специализированного компонента или с SQL-командной, на исполнение которой требуется несколько сотен миллисекунд или даже несколько секунд;

118

Глава 5

ПРИМЕЧАНИЕ Простейший прием профилирования: вставьте response.end перед тем местом ASPстраницы, где вы подозреваете наличие задержки. При загрузке такой страницы исполнение ASP-сценария завершится при исполнении этой команды. Если при этом задержка обработки не отмечается, переместите response.end дальше по коду ASP и загрузите страницу снова. В конце концов, вы таким образом определите место сценария, вызывающего задержку. • самым легким способом выявления «узких» мест и задержки обработки в SQL считается использование SQL Profiler. Достаточно просто генерировать трассировочный файл SQL Profiler во время обращения к странице. Задержки, вызванные исполнением команд SQL или сохраненных процедур, будут отображены в поле Duration трассировочного файла. Определив таким образом медленно работающие команды или процедуры, вы сможете заняться их оптимизацией. Подробно оптимизация SQL-команд и сохраненных процедур обсуждается в главе 8.

Время отклика При анализе сетевой производительности приложения время отклика считают с момента выдачи запроса клиентом до поступления ответа на него. Повышение производительности приложения — это то же самое, что сокращение общего времени отклика при просмотре каждой страницы приложения, включая все связанные с ней элементы. К факторам, увеличивающим время отклика, относятся большое число сетевых обменов, низкая полоса пропускания, высокие задержки на линиях подключения конечных пользователей, большие объемы передаваемых данных, а также задержки обработки в коде IIS, управляемом коде или в SQL-запросах. В конце главы мы расскажем, как быстро рассчитать время отклика с помощью Application Expert. Допустимое время отклика зависит от различных факторов, в том числе от типа приложения, назначения каждой страницы приложения, полосы пропускания и задержек сетевого соединения.

Анализ производительности работы в сети

121

сетевых обменов, требуемых для расчета времени отклика при страничных просмотрах или иных действиях пользователей, в результате которых генерируются запросы к Web-серверу. Предусмотрено две версии Network Monitor для Windows 2000: •

Network Monitor 2 Lite входит в состав Windows 2000 версий Advanced Server u Data Center. Эта версия способна анализировать только сетевой трафик между локальной сетевой платой и другими, взаимодействующими с ней, узлами;

•

Network Monitor 2 Full входит в состав Microsoft System Management Server (SMS) 2. Эта версия позволяет выполнить анализ всего трафика сети из одного узла, где установлен драйвер Network Monitor.

Network Monitor перехватывает сетевые кадры, помогая обнаруживать и анализировать причины сетевых проблем. Он позволяет выявлять проблемы сетевых приложений, записывая данные, пересылаемые между компонентами приложения, сетевые обмены, время доступа к сети и задержки обработки. Установка МАС-адреса и IP-адреса Перед началом анализа работы сети вам нужно записать МАСадреса и IP-адреса всех узлов. Для этого на каждом сервере и клиенте откройте окно командной строки и введите ipconfig/all. Результаты выполнения данной команды содержат информацию об IP-адресе, DNS-серверах, суффиксе DNS, физическом или МАС-адресе и др. Эти сведения позволят вам настроить фильтр анализатора и выделить сетевой трафик приложения, Часто запись в файле hosts позволяет вам повлиять на узлы сети и заставить их взаимодействовать с определенными, выбранными вами сетевыми адаптерами и IP-адресами. Обычно файл hosts, не имеющий расширения, находится в папке C:\windows\system32\drivers\etc. Для добавления или изменения его записей откройте файл с помощью Microsoft Notepad и следуйте приведенным в файле примерам.

ПРИМЕЧАНИЕ Если в клиентском компьютере или на сервере установлено несколько сетевых адаптеров, отключите лишние адаптеры; это гарантирует, что весь трафик проходит через один и тот же адаптер.

122

Глава 5

Настройка Network Monitor Прежде чем приступить к сбору информации о работе пользовательских сценариев, Network Monitor необходимо настроить. Есть три основных параметра, настройка которых гарантирует, что собранные вами данные будут корректными и полными: фильтр анализатора (capture filter), буфер данных (capture buffer) и сеть. Фильтры анализатора позволяют ограничить объем перехватываемых данных только теми узлами, которые используются вашим приложением. Вы легко выделите пересылаемые данные и сетевые обмены, избежав анализа лишнего сетевого трафика в файле трассировки. Типичный фильтр показан на рис. 5-3. Capture Filter

—ЗдР/ЕТУРЕ = Any3APoiAnjjETYPE Щ [Address Pairs) T-INCLUDE Web Servel IIP] <--> SQL Server JPJ

Рис 5-3, Фильтр Network Monitor Важным параметром считается и буфер данных. По умолчанию его размер равен 1 мегабайту. Если страница пересылает большие объемы данных, то вы можете задать другое ограничение. Обычно для сбора больших объемов данных мы устанавливаем размер буфера в 10 мегабайт. На рис. 5-4 показано диалоговое окно Capture Buffer Settings программы Network Monitor.

Анализ производительности работы в сети

123

rapture Buffer Scl lings

Рис. 5-4. Диалоговое окно Capture Buffer Settings программы Network Monitor Важно убедиться в том, что вы собираете данные с нужной сети. Если в компьютере установлено несколько сетевых адаптеров, то следует указать сеть, подлежащую анализу. Чтобы убедиться в том, что сбор данных выполняется из нужной сети, запустите трассировку Network Monitor и выполните команду ping для IPадреса или URL тестируемого Web-приложения. Затем остановите трассировку Network Monitor и убедитесь в том, что трафик команды ping перехвачен. Если это не так, переключите Network Monitor на другую сеть и повторите описанные выше действия до тех пор, пока данные не станут собираться с нужной сети. На рис. 5-5 показано диалоговое окно выбора сети Network Monitor.

Рис. 5-5. Диалоговое окно Select A Network программы Network Monitor Настройка окружения Аппаратные средства, используемые при анализе сетевой производительности, включают тестового клиента и все серверы приложения (US-сервер, SQL Server, сервер приложений), а также все используемые сетевые устройства (переключатели, концентраторы, маршрутизаторы, мосты, распределители нагрузки и т. д). Приложения с высокими требованиями к готовности (availability) и масштабируемости обычно обращаются к нескольким одина-

124

Глава 5

ковым Web-серверам для равномерного распределения сетевого трафика. При анализе подобных приложений вам следует убедиться в том, что в момент проведения анализа функционирует только один из Web-серверов приложения. Это нужно для того, чтобы вы гарантированно собрали весь трафик соответствующего Web-сервера. Предусмотрены различные способы сбора сетевого трафика приложения с помощью Network Monitor. Вот некоторые из них: • большинство приложений состоят из серверов, связанных сетевым переключателем (switch), так как при этом каждый порт имеет выделенную полосу пропускания, и производительность повышается. Сетевые переключатели изолирую трафик каждого порта, что делает невозможным для Network Monitor перехватывать трафик между уровнями приложения. Однако посредством перекрытия (spanning) или зеркализации портов большинство моделей переключателей удается настроить на копирование всего трафика с каждого выбранного вами порта. Информацией о настройке перекрытия портов владеет

Переключатель

SQL-сервер Клиент: • Web-браузер • Netmon

Рис. 5-6. Использование перекрытия портов

Анализ производительности работы в сети

125

производитель вашего сетевого оборудования. Используя версию Network Monitor для SMS и подключив клиента Network Monitor к данному порту, вы сможете наблюдать весь трафик от каждого уровня своего приложения (рис. 5-6.); если вы не можете изменять конфигурацию переключателя или если он не поддерживает перекрытие портов, воспользуйтесь другим простым способом: подключите все серверы вашего приложения к одному концентратору (hub). В концентраторах полоса пропускания используется всеми портами совместно; таким образом, клиентский компьютер с установленным Network Monitor сможет перехватывать трафик всех уровней приложения (рис. 5-7}; Концентратор

SQ L-сервер Клиент: • Web-браузер • Netmon

Рис. 5-7, •

Использование сетевого концентратора

полная версия Network Monitor позволяет установить драйвер Remote Network Monitor на каждом уровне вашего приложения для удаленного сбора трафика. Если вы выберете данный способ, установите драйвер Remote Network Monitor на каждом уровне своего приложения. В меню Start (Пуск) щелкните Control Panel (Панель управления), затем выберите Add/ Remove Programs (Установка и удаление программ). В диалоговом окне Add/Remove Programs (Установка и удаление программ) щелкните Windows Components (Добавление и удаление компонентов Windows), выберите Management and Monitor

126

Глава 5

Tools (Средства управления и наблюдения), затем — Network Monitor Tools (Средства сетевого монитора) и щелкните ОК. Данный метод позволяет собрать на одном клиенте информацию, перехваченную всеми удаленными агентами. Преимущество этого способа в том, что он быстрее, чем сбор данных на каждом уровне вашего приложения по отдельности. Однако есть и недостаток — более долгая подготовка, так как на каждом сервере необходимо установить дополнительный компонент. Данная модель сбора данных изображена на рис. 5-8;

Переключатель

Клиент: • Web-браузер • Netmon

SQL-сервер: • Netmon

Рис. 5-8. Использование удаленных драйверов Network Monitor •

самым простым методом сбора трафика считается использование Network Monitor 2 Lite для сбора информации на уровне IIS. Обычно этот уровень расположен между уровнем клиента Internet Explorer и уровнем SQL. Следовательно, если клиент Network Monitor установлен на US-сервере, вы сможете перехватывать весь входящий и исходящий трафик (рис. 5-9).

Анализ производительности работы в сети

127

Переключатель

SQL-сервер Клиент: • XVeb-браузер

Рис. 5-9. Использование уровня IIS как клиента Network Monitor

Сбор сетевого трафика Теперь, после того как Network Monitor u сетевое окружение настроены, займемся сбором сетевого трафика. Мы разработали несколько приемов, которые помогут вам • Так как обычно мы разбиваем пользовательские сценарии на отдельные действия, то рекомендуем собирать данные для каждого страничного просмотра по отдельности. Это позволит легко определить, какие объемы данных пересылаются при просмотре каждой страницы и связанных с нею элементов, При поиске сценариев, требующих больших объемов передаваемых данных и большого числа сетевых обменов, вы можете просуммировать результаты для отдельных страничных просмотров. • Чтобы убедиться в достоверности полученных данных, выполните процедуру их сбора несколько раз. В 90% случаев, данные сетевого анализа оказывались корректными, однако, пока вы не выполните несколько повторных сборов данных для

128

Глава 5

проверки, в этом нельзя быть уверенным. Чтобы убедиться в повторяемости результатов, мы выполняем каждую процедуру сбора данных три-четыре раза. Результаты повторных тестов должны быть если не идентичными, то похожими с точки зрения числа сетевых обменов и объема передаваемых данных. Network Monitor позволяет сохранять файлы собранных данных (САР), которые можно использовать для дальнейшего анализа или импорта в другие программы, такие, как Application Expert. Сохраните фильтры анализатора и базу данных адресов (обсуждавшиеся выше) на случай проведения повторных тестов. Это позволит вам в будущем сэкономить время на настройку Network Monitor. На рис. 5-10 и 5-11 показаны диалоговые окна Save Capture Filter и Save Address As.

S.iv Capture Filter jt]

FilejjarnS: Save э$!$$* jCapluie f'ih

'-I

СлгювГ

iLJ

Рис. 5-70. Диалоговое окно Save Capture Filter программы Network Monitor • Задачей сетевого анализа является сбор информации, относящейся только к передаваемым между узлами данным исследуемого приложения. Для этого запустите сбор данных в Network Monitor, запросите страницу, введя URL в строке адреса браузера, и завершите сбор данных сразу же, как толь-

129 ко загрузка страницы завершится. Загрузка страницы считается завершенной, когда Internet Explorer отображает Done в нижнем левом углу панели состояния. Этот прием позволит вам отсечь лишний трафик, передаваемый после того, как страница уже загружена.

'Budge Broadcast 'BROADCAST _J PAR5ER5 'BROADCAST jXjdefault.adi 'BROADCAST 'LAN Managei 'MAC Active Mora 'NETBIOS FunctiC NETBIOS Mdticc "Ring Error Monilo"Ring Pararnelei S iucllO

Рис. 5-11. Диалоговое окно Save Addresses As программы Network Monitor Структура собранных Network Monitor данных Файл собранных Network Monitor данных состоит из двух представлений: окна перехвата (capture) и окна отображения данных. Как показано на рис. 5-12, окно перехвата отображает объем данных, передаваемых между узлами. и оста» IG08895316E 005fj3BD3)86B 0050№DF0897 (Ш8ВЕ2МЭВ

ШИВЕ гаде - --

•

.• '

.661236

]ОВГО049С7ВВ

Рис. 5-12. Окно перехвата Network Monitor Окно отображения данных содержит девять столбцов и, как правило, много строк — в зависимости от объема собранных данных. По умолчанию в трассировочном файле отображается МАСадрес сетевой платы. Чтобы облегчить восприятие трассировоч-

130

Глава 5

ного файла, измените адрес на имя или тип компьютера. На рис. 5-13 показаны данные, собранные на пути от клиентского браузера до сервера IIS и далее до SQL-сервера и обратно. ВШу

2,Г7. . _

' loeis

Qptiore да**"

LOCAL

ЗШ И CISCO 67?OAO

ТС?

.A..S.

- . . . . . . . .

JDBB3Z JUWB32 JUUE32

JUlilBS^ JUME3^ JTJBHSi

...

m=-'i i

эизвэг

. . .

jU*q!3l

ЛЖЗЗг

. . .

JLWB32

DU5413l

. . .

JUWBIJZ JUHB3£ JOVB3E

."•и^з ЛТНВЭЗ JUTilB32

JUTflB^S JUHB3Z JijHB3£

-JUblB3£ JUWE3Z JUUE^E

лЛшэг

лтнвзг

2.2V- - -

D0BOD049iT737

LOCAL

TCP

.A. .S.

Z.ZO- - -

LOCAL

0000DQ49C73J

TC?

. AF..

2.20...

LOCAL

ОаЯОСЮ49С7Э =

ТС?

[:|j::: ££

£"£Г £

2.гЗ.--

CISCO Й7ЭОАО

LOCAL

TCP

.АР...

: .. .

in i :::

juiiiB3e

JUMB3?

IU •

*1:«Х)1Е

№:51.X2''

j i:^(j;C

Рис. 5-13. Окно отображения данных Network Monitor Все отображаемые здесь данные важны, однако основными считаются объем передаваемых данных, количество сетевых обменов и общее время.

Работа с Application Expert фирмы Compuware Application Expert предоставляет расширенные возможности для предсказания времени отклика приложения и подробную информацию на уровне приложения для настройки распределенных приложений с целью достижения оптимальной сетевой производительности. Application Expert используется как анализатор пакетов или для импорта файлов, сгенерированных Network Monitor, а также как полнофункциональный анализатор пакетов. При анализе сетевой производительности особенно полезны следующие возможности Application Expert: карта диалога, диаграмма пакетов, анализ последовательностей, средство предсказания времени отклика. О них рассказано в следующих разделах.

Анализ производительности работы в сети

131

Карта диалога После импорта данных сетевого перехвата в Application Expert вы можете моделировать взаимодействие между уровнями приложения. На рис. 5-14 показан карта диалога (conversation map) начальной страницы IBuySpy (без кэширования). По ней можно быстро определить объем передаваемых данных и число сетевых обменов при отображении страницы и всех связанных с нею элементов.

Рис. 5-14.

Карта диалога Application Expert

На карте представлены узлы (клиент, IIS и SQL) и взаимодействия, происходящие при обращении к стартовой странице. Диалогом здесь называется передача данных между различными узлами приложения. Вы можете рассматривать диалоги побайтно или выбирать из контекстного меню удобную вам метрику, например байты полезной информации, кадры или сетевые обмены. Обратившись снова к рис. 5-6, мы видим, что между клиентом IE и сервером IIS всего передано 46 кбайт данных, для чего потребовалось 18 сетевых обменов.

132

Глава -i

Диаграмма пакетов Анаграмма пакетов (bounce) представляют собой отличное средств, отображающее взаимодействие между уровнями приложения на пакетном уровне. Оно позволяет выявлять задержки обработки. На рис. 5-15 показан диаграмма пакетов для страницы Default.aspx приложения IBuySpy.

Рис. 5-15. Диаграмма пакетов Application Expert Диаграмма пакетов отображает временные характеристики обмена пакетами в клиент-серверных сетевых взаимодействиях. Здесь показаны отдельные сетевые кадры з той последовательности, как они передавались между узлами во время сбора данных. На рис. 5-15 видно, что стартовая страница IBuySpy имеет очень малую задержку обработки — примерно 170 миллисекунд. На диаграмме пакетов каждая вертикальная линия представляет узел, а горизонтальные — временные интервалы. Время отсчитывается от начала трассировки, которое принято за 0. Внутри диаграммы цветные горизонтальные линии отображают перехваченные кадры. Размер каждого кадра обозначен цветом, описанным в легенде внизу окна: красный — менее 100 байт, желтый ~ до 512 байт, зеленый — до 1024 байт и голубой — более 1024 байт.

Анализ производительности работы в сети

133

Анализ последовательностей Для определения запросов, вызывающих задержки обработки, наряду с диаграммой пакетов полезно воспользоваться средствами анализа последовательностей (thread). Объединенное представление позволяет рассматривать последовательности по отдельности. Панели связаны динамически, так что когда вы выполняете действия в верхней панели, содержимое нижней изменяется •— в ней отображаются различные представления. Например, если щелкнуть последовательность в верхней панели, то в нижней появятся кадры, связанные с этой последовательностью, При необходимости Application Expert автоматически изменяет масштаб диаграммы пакетов. Если вы щелкнете кадр, отображаемый на диаграмме пакетов, то получите подробную информацию о соответствующей последовательности. На рис. 5-16 показан анализ последовательностей для страницы Default.aspx приложения IBuySpy. С помощью средств анализа последовательностей Application Expert удается легко выделить все 16 объектов, требуемых для просмотра этой страницы. Добыть эту информацию напрямую из файлов Network Monitor или из представления трассировки пакетов Application Expert гораздо труднее.

TTP[ffiilMirevbvs,:imagesfliil gtHTIP'l II]

Рис. 5-16. Анализ последовательностей в Application Expert

134

Глава 5

Для получения более подробной информации воспользуйтесь трассировкой пакетов для выбранного кадра с помощью опции Drill Into Packet Trace контекстного меню или дважды щелкнув кадр на диаграмме пакетов. Данное представление аналогично отображению необработанных результатов перехвата в Network Monitor. На диаграмме трассировки пакетов отображаются все пакеты и важная информация о каждом из них, в том числе номер кадра, номер подтверждения, размер окна и общее количество байт (объем переданных данных) в сравнении с байтами полезной нагрузки (общее количество минус заголовки и кадры подтверждения). Диаграммы пакетов, последовательностей и карта диалога представляют собой обработанные представления исходных данных, отображаемых на диаграмме трассировки пакетов. Диаграмма трассировки пакетов для страницы Default.aspx приложения IBuySpy показана на рис. 5-1 7,

Рис. 5-17. Диаграмма трассировки пакетов Application Expert Средство предсказания времени отклика Средство предсказания времени отклика (Response Time Predictor) позволяет предсказать влияние пропускной способности и задер-

Анализ производительности работы в сети

135

жек на общее время отклика. Это очень полезно для определения времен отклика ваших Web-страниц в тестовой среде до начала рабочей эксплуатации приложения. Такие данные помогают выявить и устранить проблемы производительности до реальной эксплуатации вашего приложения. Например, оптимизировать те его страницы, которые не удовлетворяют вашим ограничениям на время отклика. Предсказанное время отклика зависит от множества факторов, включал число сетевых обменов, объем передаваемых данных и задержки обработки, которые моделируются с помощью алгоритмов, разработанных Compuware. Для предсказания времени отклика необходимо задать параметры полосы пропускания и задержек, характерные для условий эксплуатации приложения. Полоса пропускания и задержки следует определять для самой медленной линии связи. На рис. 5-18 показана модель Response Time Predictor для начальной страницы I Buy Spy.

1 СС Г. -.С i .09 I 53 2 ОС 2 fin 3 IB 3 5п 4 ЬС 4 5П !. И 5 5Г f :,-!, В 58 7 30

Рис. 5-18. Средство предсказания времени отклика в Application Expert

136

Глава 5

Анализ сетевых данных с помощью Application Expert В предыдущих разделах этой главы мы перечислили и определили ключевые компоненты, используемые в процессе анализа сетевой производительности приложения. Поэтому зам уже известно, что Network Monitor •— приложение, используемое для перехвата сетевого трафика между уровнями приложения. Теперь мы расскажем о нашем методе анализа сетевой производительности приложения и выявления ее «узких» мест. Формат файла перехваченных сетевых пакетов позволяет просматривать его в Network Monitor или импортировать в Application Expert. Содержимое этого файла сложно интерпретировать, особенно начинающим пользователям. Применение для анализа перехваченных пакетов Application Expert позволяет значительно сэкономить время. Для импорта файлов перехваченных пакетов Network Monitor в Application Expert: 1. откройте Application Expert; 2. создайте новое приложение; 3. откройте Windows Explorer и перейдите в папку, где расположены файлы перехвата; 4. перетащите эти файлы мышью во вновь созданное приложение. Расчет объема передаваемых данных После сбора данных сетевого трафика мы выделяем трафик между уровнями приложения. Расчет объема передаваемых данных в Application Expert выполняется с помощью карты диалога. На рис. 5-19 видно, что для страницы Checkout.aspx приложения IBuySpy и связанных с нею элементов между клиентом Internet Explorer и уровнем US-сервера передается примерно 15 кбайт данных, а между US-сервером и уровнем SQL-сервера — 4 кбайт. Подсчет числа сетевых обменов Подсчет числа сетевых обменов выполняется с помощью карты диалога Application Expert. Из рис. 5-20 видно, что для страницы Checkout.aspx приложения IBuySpy и связанных с нею элементов между клиентом Internet Explorer и уровнем US-сервера выполняется пять обменов, а между IIS-сервером и уровнем SQL-сервера — десять.

Анализ производительности работы в сети

ЙШ*Й ft -

a4a32i c*3):4

Рис. 5-19. Использование Application Expert для расчета объемов передаваемых данных

Рис. 5-20. Использование Application Expert для подсчета числа сетевых обменов

137

Глава .5

138 Выявление задержек обработки в приложении

Задержки обработки на уровнях IIS или SQL-сервера оказывают существенное влияние на время отклика. Их возникновение объясняется рядом факторов, таких, как медленно исполняющиеся сценарии или компоненты ASPX-страниц, требующие оптимизации сохраненные SQL-процедуры или неправильно построенные индексы SQL-таблиц. Для определения наличия в своем приложении задержек обработки разработаны различные инструменты и методы. Один из них —- SQL Profiler, выполняющий мониторинг на уровне SQL. В поле «time taken» в журналах IIS регистрируется длительность обработки на US-уровне, а диаграмма пакетов Application Expert позволяет выявить слишком большие интервалы между сетевыми кадрами. ; edit Vj&* IMCS *g*

"i*S

«*

Рис. 5-21. Использование Application Expert для поиска задержек обработки

ПРИМЕНЕНИЕ Для отладки и тестирования мы рекомендуем вести журнал IIS в формате W3C Extended Log. При этом регистрируются все допол-

Анализ производительности работы в сети

139

нательные параметры, такие, как время обработки, число отправленных и принятых байт. Подробнее о формате файла W3C Log — в главе 6. Задержки между кадрами длительностью более секунды следует отметить и исследовать. Уменьшив подобную задержку и откорректировав код приложения, вы сократите на тот же объем общее время отклика для данной страницы. На рис. 5-21 показана задержка обработки длительностью в 1,3 секунды на уровне US-сервера для страницы обновления пользовательской корзины в приложении IBuySpy. Предсказание времени отклика Средство предсказания времени отклика программы Application Expert позволяет моделировать времена отклика на основании объема передаваемых данных, числа сетевых обменов и задержки обработки, полученных в результате перехвата сетевого трафика. Получаемые модели позволяют предсказать время отклика для разных скоростей соединения и сетевых задержек и дают вам возможность определить, будет ли ваше приложение работать ожидаемым образом, еще до его эксплуатации.

ПРИМЕНЕНИЕ Альтернативный способ предсказания времени отклика при различных скоростях соединения и задержках состоит в использовании аппаратного устройства, моделирующего глобальную сеть, — WAN-имитатора. Аппаратные WAN-имитаторы размещаются между уровнями Web-приложения и подавляют сетевой сигнал в соответствии с запрограммированными спецификациями. Например, можно разместить имитатор между тестовым клиентом и уровнем Web-сервера и запрограммировать его так, чтобы понизить скорость соединения до 56 кбит/с и ввести 500-миллисекундную сетевую задержку. Мы обычно используем сочетание медленных модемных соединений, высокоскоростных широкополосных соединений (DSL или кабельные модемы) и стандартных офисных соединений -

140

Глава 5

Т1 или ЛВС. Для каждого типа соединения можно протестировать наименьшую и наибольшую сетевые задержки. Имейте в виду, что параметры полосы пропускания и сетевых задержек в этих моделях не устанавливаются жестко раз и навсегда. Эмпирическим путем мы установили: • 56-килобитные модемные соединения имеют 200-миллисекундную задержку в лучшем, и 500-миллисекундную задержку в худшем случае; • 256-килобитные соединения DSL или посредством кабельных модемов имеют 50-миллисекундную задержку в лучшем случае и 200-миллисекундную задержку в худшем случае; • линии Т1 (1,54 мбит\с) имеют 50-миллисекундную задержку а лучшем случае и 100-миллисекундную задержку в худшем случае; • соединения ЛВС — это 10- или 100-мегабитные соединения в зависимости от архитектуры сети. Обычно в лучшем случае задержка равна 10 миллисекундам или менее, а в худшем 50 миллисекундам. Как показано на рис. 5-18, средство предсказания времени отклика программы Application Expert позволяет задать скорости соединения и задержки для каждого уровня приложения. Формула расчета времени отклика учитывает скорость соединения, объем передаваемых данных, количество сетевых обменов, сетевые задержки и задержки обработки. В табл. 5-5 перечислены типичные времена отклика для начальной страницы приложения IBuySpy (в отсутствие кэширования) в соответствии с нашей моделью переменных скоростей соединения и сетевых задержек, Табл. 5-5. Моделирование времен отклика Скорость соединения

Модем 56 кбит/с

256 кбит/с DSL

1,54 мбит/с T1

10 мбит/с ЛВС

Задержка, мс

200-500

50-200

50-100

10-50

Время отклика, с

6-9

2-3

1-1,5

0,5-1

Анализ производительности работы в сети

141

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

Глава 6

Web Под термином «Web-уровень» мы подразумеваем Web-сервер, обслуживающий HTTP-запросы удаленных браузеров, таких, как Internet Explorer. Разработано множество различных Web-серверов для разных платформ. Web-сервер, созданный специалистами компании Microsoft, называется Internet Information Server (IIS), no сути он предатавляет собой файл-сервер и сервер приложений для Web-сайтов и Web-приложений, доступных через Интернет или G закрытой интрасети. 115 — это очень мощный Web-сервер, поддерживающий как статичное, так и динамическое содержимое. К первому обычно относятся картинки или простые текстовые файлы на HTML, которые изменяются редко. Для конечного пользователя динамическое содержимое может выглядеть статичным, так как запрос, по которому сценарий исполняется на серверной стороне, выполняется сервером, а клиент получает только результаты. Обычно динамическое содержимое дает пользователю больше возможностей, чем статичное. При каждом запросе динамическое содержимое способно настраиваться произвольно. Обычно оно генерируется некоторым дополнительным компонентом или сценарием, обрабатываемым Webсервером в результате удаленного запроса. В этой главе речь пойдет о таких типах динамических приложений, как приложения ASP.NET и традиционные ASP-приложения. В качестве примера в этой главе мы использовали ASP.NET Web-приложение Интернет-магазина IBuySpy, написанное на языке VB.NET.

Анализ и настройка производительности Web-уровня

143

Вы узнаете о том, как выявлять «узкие» места приложения на Web-уровне. Мы не будем перечислять все возможные «узкие» места —это просто нереально, а расскажем вам, как анализировать Web-приложения. Надеемся, что, воспользовавшись нашим опытом и методом профилирования Web-приложений ASP.NET, вы научитесь быстро выявлять некоторые распространенные «узкие» места Web-уровня, вызывающие проблемы масштабируемости вашего Web-приложения. После того как «узкое» место з Web-приложении выявлено, вам будет гораздо проще устранить проблему самим или с помощью специалистов. Мы предполагаем, что у вас уже есть определенные знания и опыт работы с US и Web-приложениями. Подробное описание администрирования и настройки Web-сервера выходит за рамки данной книги, поэтому мы приводим список источников информации по этой теме: • IIS — Документация no Microsoft Internet Information Services 5.0; • ASP.NET — G. Andrew Duthie «ASP. NET Microsoft ASP.NET Step by Step» (Microsoft Press, 2002); Jim Buyens «.Web Database Development Step by Step .NET Edition» (Microsoft Press, 2002); «ProfessionalASP.NET» (Wrox Press, 2001}; • ASP.NET — Francesco Balena «ADO.NET Programming Microsoft Visual Basic .NF7» (Microsoft Press, 2002); Jim Buyens «Web Database Development Step by Step .NET Edition» (Microsoft Press, 2002}; «ProfessionalADO.NET» (Wrox Press, 2001}.

Особенности конфигурации и параметры производительности Прежде чем приступить к тестированию производительности, крайне важно познакомиться с некоторыми особенностями конфигурации вашего Web-приложения, связанными с производительностью. Необходимо знать метод аутентификации и другие глобальные параметры приложения, чтобы быстро понять, как работает данное Web-приложение, Хотя приложения ASP и ASP.NET очень отличаются друг от друга, они могут сосуществовать на одном и том же Web-сервере, так как используемые ими расширения имен файлов отображаются IIS на разные DLL. Одним из важнейших различий этих при6-5681

144

Глава 6

ложений является способ их настройки. Описание конфигурации приложений ASP.NET выполняется с помощью текстовых файлов в формате XML, тогда как настраиваемые параметры традиционных ASP-приложений хранятся в метабазе и в реестре. Хранение информации в XML-файлах значительно упрощает задачу представления данных в читабельном формате и их динамического обновления: вам не придется перезапускать Web-сервер.

Расширения имен файлов для ASP.NET Впервые имея дело с любым Web-приложением ASP.NET, например IBuySpy, вы заметите много новых расширений имен файлов: • ASPX — используется для страниц Web-форм, которые очень похожи на традиционные ASP-страницы; • ASCX — файлы с таким расширением содержат пользовательские элементы управления для Web-форм и представляют собой один из методов повторного использования кода в ASP.NET; • ASMX — предназначено для файлов, реализующих Web-cepзисы XML; • VB — в файлах с таким расширением хранятся модули фонового кода (code behind) на Visual Basic .NET. При разработке Web-приложения на Visual Basic .NET с каждой Web-формой будет связан файл на Visual Basic. Это позволяет отделить элементы пользовательского интерфейса от прикладных алгоритмов; • CS — аналогично расширению VB за исключением того, что код в этих файлах написан на новом языке С#. Модули фонового кода, написанные на С#, имеют то же имя, что и Webформа, но с расширением CS; • Global.asax — файлы с таким расширением используются для переменных и процедур уровня приложения и уровня сессии, вызываемых, когда Web-приложение стартует или получает очередной пользовательский запрос.

Аутентификация в ASP.NET В Web-приложениях ASP.NET используются три режима аутентификации: Windows-аутентификация, Passport-аутентфикация и

Анализ и настройка производительности Web-уровня

145

аутентификация формой. ASP.NET не отвечает за процесс аутентификации целиком; он разделен на два уровня: IIS и уровень приложения ASP.NET. Режим аутентификации задается тегом <authentication> в файле Web.config (подробно — далее в этом разделе). Windows-аутентификация Этот режим, при котором аутентификация входящих запросов исполняется IIS, предназначен для компьютеров Microsoft Windows. В основном он применяется в интрасетях. В нем предоставлено три разных метода; базовый, дайджест и интегрированный. • Базовая аутентификация Этот метод работает с большинством браузеров. Так как пароли пересылаются открытым текстом, то в случае Интернет-сайтов его применение допустимо при использовании SSL-ширования, хотя и не рекомендуется. • Дайджест-аутентификация Этот метод требует контроллера домена Windows 2000 и HTTP 1,1 (поэтому поддерживается не всеми браузерами). Пароль передается не открытым текстом, но как хешированное значение, что несколько повышает защиту. Однако для проверки контроллером домена пароли должны храниться на нем незашифрованными. Таким образом, необходимо обеспечить защиту контроллера домена от внешних атак. •

Интегрированная Windows-аутентификацип (NTLM) Этот метод поддерживается только Internet Explorer и считается самым безопасным, так как имена пользователей и пароли никогда не пересылаются по сети. Он требует наличия у каждого пользователя учетной записи на Web-сервере или контроллере домена,

Passport-аутентифиация Passport-аутентификация — это централизованный сервис, предоставляемый Microsoft, который позволят вам входить на любой сайт, поддерживающий Passport, используя единое имя пользователя и пароль (то есть обеспечивается единая регистрация).

146

Глава 6

Аутентификация формой Аутентификация формой позволяет разработчикам создавать собственные схемы аутентификации в Web-приложениях, Однако пароли при этом пересылаются открытым текстом, так что не забудьте использовать SSL для их защиты. В этом режиме создается страница входа в систему, которая связывается с ASP.NET в файле Web.config, где можно задать ограничения защиты. Для проверки имени пользователя и пароля используется база данных или Windows 2000 Active Directory.

Конфигурационные файлы Для настройки Web-прилжения ASP.NET обращается к набору XML-файлов. На самом верхнем уровне, в папке (режим по умолчанию) [Каталог Windows]\Microsoft.NET\Framework\versionx.x.x\ CONFIG\, находится файл machine.config. В файле задаются параметры по умолчанию для всех приложений ASP.NET на данном сервере.

ПРИМЕНЕНИЕ При редактировании этого файла соблюдайте крайнюю осторожность, так как изменения в нем влияют на все Web-приложения ASP.NET на данном сервере. Другой конфигурационный файл -— Web.config — уникален для конкретного приложения. Если вы создаете Web-приложение с помощью Visual Studio .NET, то этот файл создается автоматически. Если вы не используете Visual Studio .NET, то причин для беспокойства нет. В отсутствие файла Web.config приложение наследует значения по умолчанию из файла machine.config. Чтобы продемонстрировать вам возможности настройки с помощью этих файлов, мы кратко рассмотрим некоторые из параметров. В табл. 6-1 перечислены некоторые теги, применяемые в конфигурационных файлах. Более подробно об атрибутах всех этих элементов рассказано в документации .NET Framework.

Анализ и настройка производительности Web-уровня

147

Табл. 6-1. Теги конфигурационных файлов Ге1

Описание

<trace>

Данный элемент полезен, когда вы пытаетесь получить дополнительную информацию о работе Webприложения. Он позволяет собирать информацию о запросах, получаемых Web-сервером. (http://<UA«j сервера>/<имяприложени(1>/1гасе.а\^.) He забудьте установить его в false на этапе развертывании своего Web-приложения

Определяет, как обрабатываются Web-запросы и поиски по сайту; например какой язык используется при обработке запросов

Управляет компонентами среды времени исполнения ASP.NET и HTTP, включая атрибуты для числа запросов, после которого возвращается 503, максимальный размер входных файлов и минимальное число потоков для обработки новых запросов

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

<pages>

Позволяет настраивать SessionState, ViewState и другие параметры, обеспечивающие дополнительные возможности вашего Web-приложения

<customErrors> Данный элемент позволяет вам настроить Web-приложение таким образом, чтобы сообщения об ошибках выдавались в терминах, понятных пользователю <authentication> Позволяет выбрать режим аутентификации <identity>

Позволяет Web-приложению использовать олицетворение

<authorization> Задает учетные записи, имеющие права на доступ к ресурсам <machinekey>

Задает ключи шифрования и дешифрования данных «cookie». Однако его нельзя использован на уровне подкаталогов

<securityPolicy> Позволяет выбирать поименованную политику защиты <trust>

Реализует политику защиты, объявленную элементом securityPolicy

см. след. стр.

148

Табл. 6-1. Тег

Глава 6

(продолжение) Описание

<$essionState> Используется для настройки элемента HttpModule — в основном в отношении поддержки состояния сессии <httpHandlers> Позволяет связывать запросы к разным типам ресурсов с классами обработчиков. Также применяется для ограничения доступа no HTTP только к файлам определенных типов <processModei> Определяет режимы исполнения Web-приложения и предоставляет различные возможности, такие, как автоматический перезапуск и допустимый размер памяти, позволяющие повысить производительность <webControls> Позволяет использовать клиентские реализации серверных элементов управления ASP.NET посредством указания файлов сценария <clientTarget> Позволяет использовать единый псевдоним для вашего приложения <browserCaps> Позволяет приложению получить информацию о браузере пользователя

Знакомство с Web-приложением Некоторые из приведенных выше конфигурационных параметров оказывают отрицательное влияние на создаваемое Web-приложение и даже создают проблемы при разработке тестовых сценариев для него. Например, многие могут считать элемент <customErrors> в Web.config полезным, так как благодаря ему удается задать страницу сообщения, куда будет перенаправляться пользователь при возникновении ошибки. При создании тестового сценария в ACT вы по умолчанию не получаете визуальной индикации того, что отображается на странице. Если при записи вашего тестового сценария возникает ошибка, то возможно перенаправление на нестандартную страницу ошибки, в результате чего в файл журнала IIS будет помещен код состояния 200 (успех). Для страницы же, на которой произошла ошибка, будет записан не истинный код ошибки, а 302 (перенаправление). Поэтому следует очень внимательно разобраться в работе приложения, в противном случае на решение подобных проблем вам придется тратить много времени.

Анализ и настройка производительности Web-уровня

149

ПРИМЕЧАНИЕ Если вы заметили, что одна страница просматривается множество раз, обратитесь к файлу Web.config и убедитесь, что это не вызвано нестандартной обработкой ошибок в этом Web-приложении ASP.NET.

Профилирование Web-приложения .NET В .NET предусмотрено несколько доступных средств, позволяющих выполнять мониторинг и выявлять проблемы производительности на Web-уровне. К задачам профилирования, о которых пойдет речь в этом разделе, относятся анализ файлов журнала US, использование нового средства трассировки ASP.NET, просмотр данных производительности с помощью системного монитора (с которым вы уже познакомились).

Файлы журнала IIS Файлы журнала IIS позволяют решить ряд задач, в том числе анализ поведения пользователя или типичных шаблонов трафика, мониторинг активности с точки зрения защиты, а также зачастую оказываются полезными при выявлении и устранении проблем Web-приложений. В следующих разделах мы кратко опишем журнал US и продемонстрируем, как быстро выявить проблемы производительности на верхнем уровне (на уровне страниц). Определив, какие страницы вашего приложения работают плохо, вы затем сможете подробнее рассмотреть их исходный текст и точно определить место возникновения проблемы. Мы начнем с файлов журнала IIS, генерируемых в ответ на действия клиента. Форматы файлов журнала IIS предоставляет различные модули и форматы ведения журнала. За исключением модуля ODBC, выводящего результаты в базу данных, все остальные файлы журнала представляют собой текстовые ASCII-файлы. Форматы NCSA Common Log File Format и Microsoft IIS Log Format — фиксированные, их нельзя настраивать. Мы всегда используем при тестировании формат W3C Extended Log File Format, так как его можно настроить, выбрав поля, подлежащие мониторингу. Это очень удобно с точки зрения администрирования, так как в журнале фиксируется меньше данных,

150

Глава 6

что позволяет сэкономить дисковое пространство и улучшить читабельность журналов без потери функциональных возможностей. Все упомянутые выше модули, генерирующие текстовые файлы, можно настроить таким образом, чтобы создавать новый журнал по достижении заданного размера файла или момента времени (ежечасно, ежедневно, еженедельно и ежемесячно). Мы не будем подробно описывать все поддерживаемые IIS форматы журналов, но немного расскажем о формате W3C Extended Log File Format, так как именно его применяем для идентификации проблем в Web-приложениях. По умолчанию время запроса, указываемое в файле формата W3C Extended Log File Format, соответствует времени по Гринвичу, тогда как остальные форматы используют местное время. Помните, что отметки времени в файле журнала генерируются сервером после обработки запроса, но не отражают время пересылки данных клиенту и время обработки на клиенте.

СОВЕТ При создании тестового сценария или отладке Web-приложения мы рекомендуем зам выбрать все поля. В противном случае — только те, что необходимы для профилирования вашего Web-приложения. Это сэкономит место на диске и облегчит разбор и навигацию по файлу журнала. Ниже приведен фрагмент одного из наших журналов в формате W3C Extended Log File Format. Следует отметить, что для вывода s журнал мы выбрали не все доступные поля, но лишь те, которые необходимы для данного Web-приложения. «Software: Microsoft Internet Information Services 5.0 «Version; 1.0 ffDate: 2002-05-24 17:25:01 ttFields: date time c-ip cs-method cs-uri-stem cs-uri-query scstatus sc-bytes cs-bytes time-taken 2002-05-24 17:25:01 161.39.207.242 GET /storevbvs/default.aspx 200 12693 373 2516 Первые четыре строки расширенного журнала W3C, начинающиеся с символа #, содержат директивы или заголовочную информацию, в том числе номер версии формата журнала, дату и время создания файла, а также идентификаторы полей, выводимых

151

Анализ и настройка производительности Web-уровня

в каждой записи журнала. Префиксы идентификаторов полей представлены в табл. 6-2, Табл. 6-2. Идентификаторы полей W3C Extended Log File Префикс

Значения

Дейсгвия сервера Действия клиента

cs-

Вызов сервера клиентом Вызов клиента сервером

sc-

В табл. 6-3 приведен полный список полей формата журнала W3C Extended Log File Format. Табл. 6-3. Поля формата W3C Extended Log File Format Поле

Обозначение

Описание

Дата

Date

Время IP-адрес клиента

Time c-ip

Имя пользователя

c-username

Дата операции Время операции IP-адрес клиента, обратившегося к серверу Имя аутентифицированного пользователя, обратившегося к серверу. Анонимные пользователи обозначаются дефисом

Имя и номер экземпляра сервиса Имя сервера

s-sitename

IP сервера

Номер Интернет-сервиса и экземпляра, исполняющегося на клиентском компьютере s-computername Имя сервера, на котором сгенерирована данная запись журнала ; •

Метод

cs-method

Цель (stem) URI

cs-uri-stem

Запрос URI

cs-uri-query

Статус Http

sc-status

IP-адрес сервера, на котором сгенерирована данная запись журнала Действие, которое пытался выполнить клиент (например, метод GET) Запрошенный ресурс, например Default, htm Запрос, который пытался выполнить клиент, если запрос был Статус завершения http см. след. стр.

Глава 6

152

Табл. 6-3.

(продолжение)

Поле

Обозначение

Описание

Сатус Win32 Отправлено байт

sc-win32-status sc-bytes

Статус завершения Windows

Получено байт

cs-bytes

Количество полученных сервером байт

Порт сервера

s-port

Номер порта, к которому подключился клиент

Затраченное время time-taken Версия протокола

cs-protocol

Количество отправленных сервером байт

Продолжительность выполнения операции Версия протокола (HTTP, FTP), использованная клиентом. Для HTTP это либо HTTP 1.0, либо HTTP 1.1

Пользовательский cs(User-AgentJ агент

Браузер клиента

cs(Cookie)

Содержимое принятого или отправленного «cookie» (если имеется)

Предыдущий сайт

cs(Referer)

Предыдущий сайт, посещенный этим пользователем, то есть сайт, предоставивший ссылку на данный сайт

Генерация журнала включена в IIS по умолчанию и может быть отключена на уровне сайта, каталога или файла, для чего следует щелкнуть нужный элемент правой кнопкой и очистить поле флажка Log Visits (Запись в журнал} в диалоговом окне свойств оснастки ММС, как показано на рис. 6-1. Отключение генерации журнала для некоторых каталогов, содержащих статичные или редко меняющиеся файлы, — это еще один метод сокращения размеров журнала Web-сервера и экономии дискового пространства. Например, только при просмотре стартовой страницы http://localhost/storevbvs/Default.aspx Web-приложения IBuySpy в журнал IIS будет помещено 16 записей. Эта страница ссылается на 14 картинок, одну таблицу стилей и плюс сам файл Default.aspx. Помните, что с точки зрения пользователя, это один запрос URL, хотя при его обработке на Web-сервер и посы-

Анализ и настройка производительности Web-уровня

153

лается несколько HTTP-запросов (один запрос на Default.aspx, один на таблицу стилей и 14 на картинки). Можете себе представить, каких размеров достигнет файл журнала и сколько места на диске он займет при обработке сценария нагрузочного тестирования, запрашивающего множество страниц через несколько браузерных сессий на протяжении длительного времени. images Properties toiy JDoctiMRTfsj Oiectej) Security! HTTP Headers] Custom 1

When cawcing to ihs resource, the content shoulc coma Item

Help

Рис. 6-1.

Флажок Log Visits

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

154

Глав;) 6

Использование журнала для выявления проблемных страниц Теперь, когда вы узнали о содержимом файла журнала, мы рассмотрим почти реальный пример использования файла журнала MS для быстрого поиска ошибок на Web-уровне. 1. Код сайта IBuySpy написан очень эффективно, поэтому сначала нам придется самим создать проблему в коде страницы ProductList.aspx для моделирования задержки загрузки страницы. Мы говорили ранее, что это почти реальный пример, так как данный код вызывает одинаковые результаты на нескольких разных машинах. Если бы мы попытались создать демонстрационный код, реализующий плохо написанную конкатенацию строк или некий цикл, возвращающий большое количество строк базы данных, то производительность и время исполнения ASPX для страницы ProductList.aspx оказалось бы разным в зависимости от аппаратной конфигурации. На странице ProductList.aspx закомментируйте четвертую строку: <Г@ OutputCache Duration="6000" VaryByParam="CategoryID" %> Затем вставьте приведенный ниже код между <% и %> в пятой строке ProductList.aspx.

<% V/////////////////////////////////////////////////////////// ' СДЕЛАТЬ: -Закомментировать 4 строку ProductList.aspx. -Это отключит OutputCache, что позволит -нам ввести задержку. System. Threading. Thread. Sleep (7000) '7-секундная задержка.

2. Отключите ведение журнала для файла IBuySpy.css, подкаталогов Images и Productlmages, чтобы сосредоточиться на анализе запросов к файлам типа ASPX.

ПРИМЕЧАНИЕ Это не умаляет важности оптимизации или уменьшения размеров ваших картинок или таблиц стилей, чтобы исключить вероятность образования «узкого» места Web-приложения.

Лнализ и настройка производительности Web-уровня

155

3. Убедитесь, что пример сайта IBuySpy установлен правильно. Затем в параметрах IIS удостоверьтесь, что выбран формат W3C Extended Log File Format и в нем следующие поля: date, time, c-ip, cs-method, cs-uri-stem, cs-uri-query, sc-status, sc-bytes, cs-bytes, time-taken. 4. Наконец, выполните одну итерацию сценария тестирования Browse с помощью Microsoft ACT. Сценарий тестирования Browse находится на прилагаемом к книге компакт-диске, подобно о нем говорилось в главе 3. Это не нагрузочный тест, но скорее автоматизированное выполнение пользовательского сценария, так как мы выполняем лишь одну итерацию в единственной браузерной сессии. Результаты исполнения сценария тестирования в журнале HS таковы: ^Software: Microsoft Internet Information Services 5 , 0 «Version: 1.0 #Date: 2002-05-30 18:36:11 tfFields: date time c-ip cs-method cs-uri-stem cs-uri-query scstatus scbytes cs-bytes time-taken 2002-05-30 18:36:11 181.39.207.242 GET /storevbvs/Default.aspx 200 0 346 15 2002-05-30 18:36:18 181,39.207.242 GET /StoreVBVS/ productslist.aspx CategoryID=20&selection=2 200 0 377 7016 2002-05-30 18:36:18 181.39.207.242 GET /storevbvs/ Default.aspx test=count 200 0 357 16 Обратите внимание, что в приведенном журнале три запроса, Сначала, вам нужно убедиться в том, что все запросы выполнились без ошибок. Для этого следует просмотреть поле sc-status — код состояния. Табл. 6-4 содержит полезную сводку кодов состояния HTTP. Табл. 6-4. Коды состояния HTTP Состояние

Описание

2хх 200 201

Успех ОК: запрос отработал успешно Создан: запрос отработал успешно, в результате создан новый ресурс см. след. стр.

156

Табл. 6-4.

(продолжение)

Состояние

Описание

202

Принят: запрос был принят на обработку, но не был завершен

203

Неточная информация

204

Нет содержимого: у сервера нет информации, которую можно было бы возвратить

Зхх

Перенаправление

301

Перемещено: запрашиваемые данные перемещены на новое место и это изменение постоянно

302

Найдено: запрашиваемые данные временно имеют другой URL

303

Метод: рекомендация клиенту попробовать другой адрес

304

Не изменено: документ не был изменен, как ожидалось

4хх

Вероятные ошибки клиента

400

Неверный запрос: неверный синтаксис запроса или запрос не может быть выполнен

401

Неавторизован: у клиента нет доступа к данным

402

Требуется оплата: указывает на применение некоторой схемы оплаты

403

Запрещено: нет доступа даже при наличии авторизации

404

Не найдено: сервер не может найти данный ресурс

5хх

Вероятные ошибки сервера

500

Внутренняя ошибка: сервер не может выполнить запрос из-за неожиданно возникших проблем

501

Не реализовано: сервер не поддерживает данную операцию

502

Сервер перегружен: сервер перегружен или на обслуживании

503

Тайм-аут шлюза: сервер выдал запрос другому сервису, который не обработал этот запрос своевременно

Все три записи журнала соответствуют запросам СЕТ (как указывает название метода) и выполнились успешно с кодом завершения 200, Кроме того, объемы пересылаемых данных невелики (как показывают поля количества принятых и отправленных байт). Время исполнения ASPX из поля time-taken невелико для страницы Default. aspx, но для ProductList.aspx составляет более семи секунд (точнее, 701 6 миллисекунд). Итак, мы выявили проблему.

Анализ и настройка производительности Web-уровня

157

Журналы US очень полезны для выявления медленно работающих или пересылающих большие объемы данных страниц, а также при поиске ошибок Web-приложения. Теперь, когда мы успешно выявили проблему на уровне страницы, обсудим новое средство ASP.NET, позволяющее нам определить место возникновения проблемы с точностью до строки кода.

Трассировка на уровне кода Трассировка — это новое полезное средство ASP.NET для отладки и профилирования проблем, возникающих на уровне приложения, страницы или кода. Вы можете распечатывать операторы во время исполнения кода, что позволит точно определить, что же происходит в данной точке программы. В традиционных ASP-страницах отладка выполнялась путем вставки в код многочисленных операторов Response.Write. Чтобы вы полностью оценили новое средство трассировки ASP.NET, мы кратко обсудим используемый нами метод выделения медленно работающего кода на традиционных ASP-страницах. Трассировка обычных ASP-страниц После того как с помощью журналов 115 установлены файлы с большими временами исполнения, мы обычно вставляем в текст страницы несколько таймеров, чтобы выделить медленно работающий код. При обращении к странице значения таймеров регистрируются в текстовом файле посредством локальной файловой системы Web-сервера. Далее достаточно просто открыть полученный текстовый файл, чтобы проанализировать информацию таймеров, записанную туда между блоками кода. Ниже приведен пример файла на VBScript: <% Dim t1, t2

'Таймер 1 - запуск таймера для секции 1

t1=Timer К> ВСТАВИТЬ СЮДА БЛОК КОДА <% 'Таймер 2 - запуск таймера для секции 1 t2=Timer 'Следующий код может быть помещен в конец файла ASP. Dim fso, filename, fileref filename = "C:\temp\" + cstr(Timer) + ".txt" 'При каждом исполнении страницы создается новый файл.

158

Глава 6

SET fso = createobjectC'Scripting.FileSystemObject") SET fileref = fso.createtextfile(filename ) 'Вывести значения таймеров в миллисекундах в файл. fileref. writeline("1, " + cstr(t1) + "," + cstr(t2) + cstr(t2-t1)} 'Закрыть файл. fileref .close Другой способ поиска медленно исполняющегося кода на традиционных ASP-страницах таков: сначала надо заметить, сколько занимает исполнение немодифицированного кода страницы. Затем нужно поместить вызов метода Response. End в различные места страницы и снова выполнять запрос к ней, засекая время обработки. Когда метод Response.End прекратит исполнение кода, можно сравнить новое время исполнения со временем исполнения первоначального запроса. Часто для определения места возникновения проблемы требуется несколько итераций этого метода, при этом вы можете получать ошибки, так как код не исполняется целиком. Трассировка в ASP. NET В ASP. NET трассировка возможна либо на уровне страницы, либо на уровне приложения. Трассировка на уровне страницы реализуется путем добавления Тгасе="Тгие" в директиву @ Раде в начале ASPX-файла. Полностью это выглядит так: <%@ Page Тгасе="Тгие"Х> В результате после генерации собственно содержимого страницы к нему будет добавлена HTML-таблица. В ней содержится подробная информация о запросе: время исполнения, дерево серверных элементов управления (с размером VIEWSTATE), заголовок. «cookie», строка запроса вместе с параметрами формы, переменные сервера. Кроме того, вы можете добавлять свои сообщения, используюя методы Trace. WriteO или Trace. Warn(). Оба метода генерируют одни и те же результаты, но последний выводит их красным цветом. СОВЕТ Обращаем ваше внимание на то, что трассировку следует включать только во время отладки

Анализ и настройка производительности Web-уровня

159

Web-приложения. По журналу MS можно определить, что объем данных, пересылаемых от сервера клиенту для страницы ProductList.aspx, возрастает при включенной трассировке с 13628 до 32695 байт, Этот почти троекратный рост объема передаваемых данных легко может исказить результаты нагрузочного тестирования. Трассировка на уровне приложения активизируется G файле Web.config следующим образом.

<configuration> <system.Web> <trace enabled="true" requestlitnit="15" pageOutput="true" traceMode="SortByTime" localOnly="true"/> </system.Web> </configuration> После активизации режима трассировки в файле Web.config для просмотра трассировочной информации следует из браузера обратиться к специальному HTTP-обработчику (Trace.axd). Параметр requestLimit задает число запросов, для которых записывается трассировочная информация. Имейте в виду, что параметры трассировки на уровне страницы переопределяют параметры трассировки, заданные на уровне приложения. Выявление проблемного кода на страницах ASPX Вернемся к предыдущему примеру, где с помощью журнала MS мы определили медленно исполняющуюся страницу, и воспользуемся новым методом Trace для изоляции кода, вызывающего задержку при обработке страницы ProductList.aspx. 1. Проверьте, что вы включили трассировку на уровне приложения, добавив следующий текст в файл Web.config, расположенный в корневом каталоге Web-приложения IBuySpy.

<trace enablecj="true" requestlimit="15" pageOutput="true"

Глава 6

160 traceMode="SortByTime" loca!Only="true"/> </system.Web> </configuration>

2. Измените следующий блок кода, где происходит задержка, добавив два оператора, начинающихся с Trace. Warn. Эти операторы выведут отладочные сообщений до и после кода, который вы считаете источником проблем.

' СДЕЛАТЬ: -Закомментировать 4 строку ProductList.aspx. -Это отключит OutputCache, что позволит -нам ввести задержку. Trace. Warn("Find Delay", "Timer 1: Begin") System. Tnreading.Th read. Sleepf 7000) '7-секундная задержка, Trace, Warn("Find Delay", "Timer 1: End") 7///////////////////////////////////////////////////////////

Application Trace StoreVBVS

Physical Directory: Ci'\StoreVsvS'',3rore1JBVS\

Requests lo this Appbcation

Рис. 6-2.

Результаты исполнения тестового сценария Browse

Анализ и настройка производительности Web-уровня

161

3. Один раз выполните упоминавшийся выше сценарий Browse с помощью Microsoft ACT. Так вы смоделируете исполнение пользовательского сценария. 4. Наконец, на Web-сервере, где установлен сайт-пример IBuySpy, введите следующий URL в вашем браузере: http://lo.calhost/StoreVBVS/trace.axd. Три запроса, выполняемых нашим сценарием, должны отобразиться так, как показано на рис. 6-2. Обработчик HTTP (Trace.axd) отобразит примерно ту же информацию, что мы видели ранее в журнале II5. Уже ясно, что проблема возникает на странице ProductL.ist.aspx, так как на ее загрузку требуется более 7 секунд. Теперь щелкните гиперссылку Details на странице ProductList.aspx. Efc

С*

<?>Bsit. *

i"'

(S rites

lays

Help

' • О Q (2 жШчЩ [JjMJniitiM Q •*•*

& Erjftri. d p"*3 Lir!ksB:

sffifre» j*] wi^.'.lixs'i-^-ii-i-t.Ei.EaHc» n.drW-l

Request Details • Request DetaDe Session Id: Time nf Requesti Request Encoding:

6/4/2002 4:45:22 PM Unicode (UT=-B1

1 1 race Information Gotflgorv • Message

^53= заде aspx.page asp. oage asp- page asp.. page sspx.paqe "in<s Dslas

Ere init Begin PreRenaer End BreRender Begin SaweViewStete End SaveViewState Begin Render Timer !• us.g-.n

asai oage

End Binder

tel:a*i.^ja~*-«^-l-r.

Request Type: Status Code: Response Encoding:

SET 200 Unicode (UTF-B)

^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | И | И И И | И O.OQOE09 O.OOOS09 0,009746 0.009238 0.009845 0-00005? Э.С11677 0.001632 0.011718 0.000041 0.011749 0 000031

a.utssst

•J V)7C:f. 7 009754

о xiii-г

ri.?rJ-iJi'S 0.00273Э

^der !

;

•

vlHraB.j

^Скаимбак»

Рис. 6-3. Трассировочная информация выводится красным цветом Вы сразу же заметите текст, который мы добавили с помощью Trace. Warn, так как он набран красным цветом. На рис, 6-3 добавленный нами код вы найдете под заголовком Trace Information в категории Find Delay. Около семи секунд занимает исполнение

162

Глава 6

кода между двумя добавленными нами операторами, выводящими строки «Timer 1: Begin» и «Tinner 1: End». Итак, мы снова успешно отыскали место возникновения ошибки. Убедиться, что проблема кроется именно здесь, можно, закомментировав подозрительную строку кода и снова вызвав страницу ProductList.aspx из браузера, При этом время загрузки должно уменьшиться на 7 секунд — это докажет, что проблема найдена верно.

Счетчики системного монитора Системный монитор является превосходным инструментом для мониторинга и анализа производительности Web-приложений ASP.NET. В процессе тестирования параметры производительности можно анализировать в реальном времени или записывать в журнал для последующего изучения. Измеренные параметры производительности используются для поиска возможных проблем производительности, таких, как неэффективное использование процессора или памяти, а также иных факторов, не позволяющих приложению показывать требуемые значения производительности на Web-уровне. Счетчики производительности IIS 8 следующих разделах мы расскажем о счетчиках NS и счетчиках производительности ASP.NET, используемых нашей группой во время тестов производительности. •

Internet Information Services Global (Общий объект служб IIS): File Cache Flushes (Число удалений кэша файлов) и File Cache Hits (Попаданий в кэш файлов) Сравнение значений этих счетчиков позволяет определить отношение числа попаданий в кэш к числу сбросов кэша. Сброс кэша происходит, когда файл удаляется из кэша. Эти глобальные счетчики позволяют определить частоту, с которой объекты удаляются из кэша. Если сбросы кэша происходят слишком медленно, то память расходуется напрасно.

• Internet Information Services Global (Общий объект служб IIS): File Cache Hits % (Процент попаданий в кэш файлов) Показывает отношение попаданий в кэш к числу обращений к кэшу. Для Web-узлов, имеющих, в основном, статичное содержимое, этот показатель должен быть около 80%.

Анализ и настройка производительности Web-уровня

163

• Web Service (Веб-служба): Bytes Total/sec (Всего байт в секунду) Показывает общее количество байт, отправляемых и принимаемых Web-сервером за секунду. Малое значение говорит о том, что US передает данные с малой скоростью. •

Web Service (Веб-служба): Connection Refused (Отклонено запросов) Чем меньше, тем лучше. Большие значения указывают на наличие «узкого» места, связанного с сетевым адаптером или процессором.

• Web Service (Веб-служба): Not Found Errors (Ошибок «Не найдено») Показывает количество запросов, не обработанных сервером, так как запрашиваемый документ не был найден (код состояния HTTP 404). Счетчики производительности ASP.NET В ASP.NET предусмотрено два набора счетчиков производительности для мониторинга производительности Web-приложения. Они относятся к объектам ASP.NET и приложениям ASP.NET. Эти счетчики имеют несколько экземпляров, каждый со своим номером версии. Счетчики без номера версии всегда соответствуют версии с самым большим номером из всех, установленных на компьютере. Системные счетчики производительности ASP.NET

Мы не будем рассматривать все объекты и счетчики производительности в .NET Framework. Подробно о них рассказано на Webсайте Microsoft MSDN и в справочной информации no .NET Framework. В этой главе мы поговорим о системных счетчиках производительности, а также счетчиках производительности приложения, используемых нашей группой при мониторинге и анализе производительности Web-приложений .NET. •

Application Restarts Указывает, как часто перезапускается Web-приложение. Перезапуск приложения возможен из-за изменений конфигурации и двоичных сборок или слишком большом числе измерений страниц. Значения счетчика сбрасывается в 0 при всяком перезапуске IIS или w3svc.

• Requests Queued Количество запросов, ожидающих обслуживания. Если это значение начинает расти в той же степени, что и нагрузка со стороны клиентов, значит, достигнут пре-

164

Глава 6

дел возможностей Web-сервера по параллельной обработке запросов. • Requests Rejected Общее количество запросов, не выполненных из-за недостатка серверных ресурсов. Данный счетчик показывает число запросов, в ответ на которые был возвращен код состояния HTTP 503 («Server is too busy»). В идеале количество отвергнутых запросов должно быть равно 0. • Request Wait Time Число миллисекунд ожидания обработки последним запросом. Средний запрос в идеале должен ожидать обработки буквально мгновение. Счетчики производительности приложения ASP.NET

ASP.NET поддерживает счетчики производительности приложения, позволяющие наблюдать за производительностью одного экземпляра приложения ASP.NET. Все они имеют экземпляр _Total_, соответствующий суммарному значению данного счетчика для всех приложений Web-сервера. Экземпляр _Total_ доступен всегда. Если на сервере нет ни одного приложения, то значения счетчиков равны 0. • Cache Total Turnover Rate Число добавлений и удалений из кэша в секунду. Большое значение указывает на неэффективность использования кэша. • Errors Total Общее число ошибок синтаксического анализатора, компилятора и времени исполнения при обработке HTTP-запросов. Хороший Web-сервер не должен генерировать ошибки. • Request Execution Time Количество миллисекунд, потраченных на исполнение последнего запроса. Значение данного счетчика должно быть стабильным. • Requests Failed Общее число запросов, в результате которых возвращены ошибки авторизации (HTTP 401) и не найденных ресурсов (HTTP 404 или 414) или вызвавших ошибку сервера (HTTP 500). • Requests Not Found Количество не выполненных запросов из-за того, что не найдены соответствующие ресурсы (HTTP 404 или 414).

Анализ и настройка производительности Web-уровня

165

• Requests Not Authorized Количество запросов, не выполненных из-за попытки неавторизованного доступа (HTTP 401). •

Requests Timed Out по тайм-ауту.

Количество запросов, завершившихся

• Requests/Sec Количество запросов, исполняемых в секунду. При постоянной нагрузке это значение должно оставаться в заданном диапазоне. В предыдущем разделе описаны счетчики MS, а также счетчики производительности ASP.NET, регулярно используемые нашей группой для мониторинга и анализа Web-приложений ASP.NET.

Советы по настройке производительности Настройка производительности подразумевает устранение «узких» мест и внесение исправлений в код с целью достижения желаемых показателей пропускной способности или времени отклика при одновременном сохранении масштабируемости. Новые возможности ASP.NET, такие, как кэширование и новые методы доступа к данным, позволят вам существенно повысить производительность и масштабируемость. Отключение некоторых, активизированных по умолчанию, средств, таких, как состояние сессии или состояние представления, если в них нет необходимости, также положительно сказывается на производительности Web-приложения.

Состояние приложения и состояние сессии Ранее поддерживать работу Web-приложения, распределенного по нескольким Web-серверам, не создавая при этом проблем производительности и масштабируемости, было непросто. Приложения ASP.NET предоставляют больше возможностей по сравнению с традиционными ASP-приложениями, однако при использовании любой из них вам no-прежнему придется учитывать противоречия между производительностью и масштабируемостью. Состояние приложения Традиционно переменные приложения использовались для хранения такой информации, как строки подключения или как механизм кэширования значений и наборов данных для их использования при обработке нескольких запросов. Переменные при-

166

Глава 6

ложения no-прежнему существуют в ASP.NET, но для реализации многих функций, которые они выполняли в традиционных ASPприложениях, теперь предлагаются новые, более эффективные методы. Используйте файл Web.config для хранения строк подключения к базе данных либо используйте доверительные (trusted) подключения к серверу базы данных. Для хранения востребованных данных используйте обсуждаемый далее механизм кэширования. V состояния приложения no-прежнему есть ограничение: оно не может совместно использоваться несколькими Web-cepзерами. Состояние сессии Состояние сессии — это данные, хранящиеся з памяти Web-сервера для каждого обратившегося к нему пользователя. Ранее поддержка состояния сессии в Web-приложении сопровождались рядом проблем. Протокол, используемый для выполнения запросов (HTTP), не поддерживает сессии, поэтому в традиционных Web-приложениях клиенту назначался HTTP-«cookie», который возвращался серверу в последующих запросах в пределах некоторого интервала времени. Если Web-приложение работалло на нескольких машинах или на Web-ферме, пользователь при следующем запросе мог быть переназначен на другой компьютер, в результате чего «cookie» сессии терялось, так как его запрещено передавать между разными компьютерами. ASP.NET решает некоторые проблемы масштабируемости, связанные с использованием Web-фермами состояния сессии, позволяя хранить его вне процесса внутри сервиса Windows или в базе данных SQL Server. Помните, что при хранении состояния сессии вне процесса достигается масштабируемость, но снижается производительность. По умолчанию в файле Machine.config поддержка состояния сессии активизирована в режиме «внутри процесса». Данный режим создает для приложений ASP.NET те же ограничения, о которых мы говорили ранее в контексте традиционных ASP-приложений, однако представляет собой наиболее быстрый и эффективный метод реализации состояния сессии, когда это необходимо. Мы рекомендуем отключать состояние сессии в файле Web.config или на уровне страницы всегда, кроме тех случаев, когда без него абсолютно нельзя обойтись. На

Анализ и настройка производительности Web-уровня

167

уровне страницы состояние сессии отключается при помощи директивы <%@ Page EnableSessionState = "False" X>.

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

ПРИМЕЧАНИЕ Мы рекомендуем кэшировать результаты работы тех страниц приложения ASP.NET, к которым пользователи обращаются весьма часто, однако после любой настройки не забывайте выполнять тесты. Не злоупотребляйте кэшированием, так как кэширование слишком больших объемов данных требует значительных ресурсов памяти. Чтобы убедиться в том, что кэш используется эффективно, понаблюдайте за значением счетчика производительности ASP.NEТ Applications\Output Cache Turnover Rate\Total. Оно должно быть малым или соразмерным частоте объявления кэшированных страниц недействительными. Кэширование результатов Кэш результатов ASP.NET может использовать память сервера для хранения результатов обработанных и готовых к отправке клиенту страниц. При включенном кэшировании результатов страница сохраняется после первого обращения к ней. Последующие запросы к странице удовлетворяются из кэша, если страница попрежнему в нем, и возвращаются клиенту сразу, без разбора, компиляции и обработки. Это существенно улучшает время отклика и снижает потребление ресурсов сервера.

168

Глава 6

Кэширование результатов для страниц легко включается с помощью директивы OutputCache. Например, чтобы сохранять результат обработки страниц на время не более 60 секунд, на страницу можно поместить следующую директиву: <%@ OutputCache Duration="60" VaryByParam="None">!> Атрибуты Duration и VaryByParam являются обязательными.

ПРИМЕЧАНИЕ Рекомендуется, чтобы при кэшировании результатов обработки страниц значение Duration составляло не менее 60 секунд, в противном случае частое повторное помещение страницы в кэш приведет не к повышению, но к снижению производительности. Для страниц с коротким временем жизни, но содержащих информацию, получение которой может потребовать значительных ресурсов, лучше использовать объект Cache, позволяющий кэшировать и обновлять данные по мере необходимости (см. раздел «API кэширования»). Атрибут VaryByParam позволяет кэшировать разные версии страницы. Например, страницы могут генерировать разные результаты s зависимости от входных параметров. Значение None атрибута VaryByParam сохраняет результат работы страницы в отсутствие каких-либо входных параметров при обращении к ней. Чтобы сохранить версии страницы для всех возможных сочетаний параметров, можно использовать значение «*». При этом, однако, следует иметь в виду, что кэширование нескольких версий страницы требует дополнительной памяти. Для кэширования результатов на основании некоторого параметра строки запроса или значения поля формы на странице, следует задать имя параметра. Допускается указать несколько параметров, разделенных точкой с запятой. Например, если на странице расположена форма ProductCategory и поля Product, допустимо кэшировать варианты страницы на основании значении этих параметров: <Ж@ OutputCache Duration="10" VaryByParam="ProductCategory;Product"X>

Анализ и настройка производительности Web-уровня

169

Помимо двухобяза!' .,.чых атрибутов у директивы OutputCache есть еще три необязательных атрибута; Location, VaryByCustom и Vary By Header. Атрибут Location указывает, где кэшируются данные (например, на сервере или на клиенте). VaryByHeader позволяет выполнять кэширование на основании определенных заголовков запроса, a VaryByCustom — на основании типа браузера, если указан со значением Browser, либо этот параметр применяется для реализации нестандартной логики с использованием любых иных данных. Кэширование фрагментов Кэширование фрагментов похоже на кэширование результатов в смысле использования той же самой директивы. Данный уровень кэширования применяется для кэширования фрагментов страницы, реализованных как пользовательские элементы управления, и его также называют частичным кэшированием страницы или кэшированием элементов управления. Возможность кэширования фрагментов следует рассматривать всегда, когда в кэш можно помещать большие объемы информации и кэширование на уровне страницы невозможно с точки зрения использования ресурсов памяти сервера и кэша. Как и в случае кэширования результатов, кэширование фрагментов показывает наилучшие результаты, когда помещаемые в кэш данные мало подвержены изменениями или когда для их первоначального получения требуются значительные ресурсы. Для реализации кэширования фрагментов директиву Output следует включить в файл, реализующий элемент управления. Атрибуты Duration и VaryByParam обязательны и имеют в точности то же значение, что и при кэшировании результатов. Кроме того, при кэшировании фрагментов можно использовать еще и атрибут VaryByControl, допустимый только в файле пользовательского элемента управления. <%@ OutputCache Duration="60" VaryByParam="None"!<>

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

170

Глава 6

необходимо отображать категории товаров. Вместо того чтобы при каждом запросе считывать эту информацию из базы данных, следует сохранить категории при помощи API кэширования. Вот наиболее простой способ кэширования данных: Cache("mydata"}() = "some data" Разрешается сохранять не только строки или числа, но и целые наборы данных. Получить данные из кэша столь же просто: X = Cachefmydata") В качестве других полезных методов предлагаются Remove, удаляющий элемент кэша, и Insert, используемый для добавления данных в кэш. Ниже показан пример использования Remove: (Cache. RemoveC'mydata")) Метод Insert объекта Cache является совмещенным (overloaded] и имеет несколько версий. Например, вот какую версию можно использовать для добавления при первом обращении к странице элемента к кэшу без внешней зависимости и с абсолютным временем хранения, равным 120 минутам: Cache.Insert("mydata", mydata, nothing, _ DateTime.Now.AddMinutes(120), TimeSpan.Zero)

Последний параметр здесь называется скользящим окном, его применяют для установки времени хранения элемента в кэше относительно момента, когда элемент был впервые помещен в кэш или последний раз оттуда выбран. Другими словами, этот параметр равен максимальному промежутку времени между последовательными вызовами, который должен пройти, прежде чем данный элемент удаляется из кэша. Например, чтобы поместить элемент в кэш максимум на 10 минут между последовательными обращениями к нему, можно вызвать Insert следующим образом: Cache.Insert("mydata", mydata, nothing, DateTime.MaxValue, TimeSpan.FromMinutes(IO))

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

Лнализ и настройка производительности Web-уровня

171

виде скрытого поля формы, отправляемого браузеру. Размер и содержимое данных состояния отображения определяют посредством директивы Trace на уровне страницы или приложения, как говорилось в разделе «Профилирование Web-приложения .NET». При применении большого числа серверных элементов управления размеры состояния отображения могут стать очень большими, а значит, снизить производительность Web-приложения. Рекомендуется отключать состояние отображения кроме случаев, когда оно абсолютно необходимо. Для этого следует установить свойство EnableViewState="false" на уровне страницы или элемента управления.

ADO.NET Большинство Web-приложений использует серверы баз данных. Связь с уровнем данных и управление данными много значит для производительности приложения наряду с другими факторами, такими, как объем пересылаемых данных и архитектура базы данных. Поэтому вам необходимо знать модель объектов ADO.NET. Правильный выбор объекта и метода имеет значение для производительности приложения, особенно в условиях больших нагрузок. В этом разделе мы расскажем о некоторых рекомендуемых приемах получения и изменения информации источника данных. Более подробную информацию об ADO.NET вы найдете в источниках, указанных в начале главы. В состав .NET Framework входит два провайдера данных (data provider): OLE DB .NET Data Provider и SQL Server.NET Data Provider. Провайдер для OLE DB .NET Data Provider годится для подключения к любому источнику данных, для которого существует компонент доступа OLE DB, например к Microsoft SQL Server или Oracle, но главным образом он предназначен для баз данных, отличных от SQL Server. Для приложений, использующих Microsoft SQL Server версии 7.0 и выше, предпочтительнее провайдер данных SQL Server. Он оптимизирован с учетом особенностей SQL Server и обеспечивает доступ к некоторым возможностям, характерным для этой базы данных.

ПРИМЕНЕНИЕ SQL Server .NET Data Provider используется с SQL Server версии 7.0 или выше.

172

Глава 6

Объект SqlConnection Первым шагом при обращении к уровню данных является установление сессии с сервером базы данных. Для этой цели провайдер данных SQL Server предоставляет объект SqlConnection. Создать сессию очень просто, что демонстрирует следующий код на VB.NET, устанавливающий сессию с SQL Server на локальном компьютере и подключающийся к базе данных Pubs: Dim strCnStr As String = "Data Source = . ; " _ & "Integrated Security=SSPI;" & "Initial Catalog = Pubs" Dim objCn as New SqlConnection(strCnStr) _ objCn.Openf) По умолчанию этот провайдер данных использует пул сессий, что позволяет сократить накладные расходы на создание новой сессии всякий раз, когда требуется доступ к базе, так как вся работа выполнена заранее при первом создании сессии. Важно понимать работу этого средства и уметь им пользоваться. Чтобы воспользоваться сессией из пула, строка соединения для новой сессии должна в точности соответствовать строке соединения, использовавшейся ранее. Даже из-за лишних пробелов в строке среда .NET создаст отдельный пул. Фактически среда .NET создает отдельный пул сессий для каждой новой строки соединения. Из этого следует, что соединения, применяющие разные имена пользователей и пароли, не смогут воспользоваться пулом сессий.

ПРИМЕЧАНИЕ Для повышения эффективности использования пула сессий приложения должны либо применять интегрированную защиту, когда это возможно, либо одно и то же имя пользователя и пароль для всех клиентов приложения. Кроме того, на возможность использования сессии из пула влияет контекст транзакции. Вторая попытка соединения применяет сессию из пула в том случае, когда текущий контекст транзакции совпадает с первоначальным либо вообще отсутствует. Управление размером пула сессий осуществляется путем установки значений свойств min и max, Это важно, если нужно управлять размером памяти, используемой Web-уровнем. Если все сес-

Анализ и настройка производительности Web-уровня

173

cuu пула активны, то запрос на установление дополнительной сессии блокируется до тех пор, пока одна из них не будет освобождена либо не окончится тайм-аут установления сессии (по умолчанию равный 15 секундам). В следующем примере обсуждавшиеся свойства задаются в строке соединения: Dim strCnStr As String = "Data Source = . ; " & "Integrated Security=SSPI;" Ь "Initial Catalog = Pubs;" 4 "Min Pool Size=10;" & "Max Pool Size =100" Другое свойство, влияющее на производительность, — это размер пакета. Его стоит увеличить для приложений, работающих с большими полями типа blob или image. Если же объем передаваемых данных невелик, то эффективнее малый размер пакета. Следующий пример демонстрирует задание значения этого свойства в строке соединения: Dim strCnStr As String = "Data Source = . ; " & "Integrated Security=SSPI;" & "Initial Catalog = Pubs;" & "Packet Size=32768" Объект SqICommand Для Web-приложений распространен такой сценарий, как выборка/модификация данных из базы. Провайдер данных SQL Server реализует классы SqlCommand/DataReader и DataAdapter/DataSet, позволяющие выполнять выборку и модификацию данных. Здесь мы лишь кратко рассмотрим SqlCommand/DataReader; о классах SqlDataAdapter/DataSet вы можете прочитать в других источниках, посвященных непосредственно ADO.NET. SqlCommand/DataReader ориентированы на сессии и предоставляют ряд методов, предназначенных для повышения производительности приложения, К ним относятся ExecuteNonQuery, ExecuteScalar и Execute Reader. Кроме того, класс SqICommand предоставляет метод ExecuteXmlReader для данных, возвращаемых в формате XML. В следующих разделах описаны эти четыре метода и пример использования их в программе (консольное приложение на VB.NET). Программа-пример работает с базой данных NorthWind, устанавливаемой по умолчанию одновременно с Microsoft SQL Server.

174

Глава 6

Метод ExecuteNonQuery Обычно этот метод применяется для выполнения операций Insert, Update и Delete. В этих случаях в возвращаемой клиенту информации наиболее полезными считаются сведения о числе затронутых строк. Данный метод также работает с сохраненными процедурами, содержащими выходные параметры/возвращаемые значения, которые могут быть возвращены клиенту. В следующем примере демонстрируется использование этого метода для вызова сохраненной процедуры, возвращающей число записей о клиентах в таблице Customer базы данных NorthWind: Imports System Imports System.Data Imports System.Data.SqlClient Module ExecuteNonQuery Sub HainO Dim strConnString As String = "Data Source=.;" & "Initial Catalog=Northwind;" & "Integrated Security=SSPI" Dim strSQL As String = "GetNumberOfCustomers" Dim sqlConn As New SqlConnection(strConnString) Dim sqlComd As New SqlCommand(strSQL, sqlConn} sqlComd.CommandType - CommandType.StoredProcedure sqlComd.Parameters.Add(New SqlParameter("@i", SqlDbType.Int)) sqlComd.Parameters(O).Direction = ParameterDirection.ReturnValue sqlConn.Open() sqlComd.ExecuteNonQuery() sqlConn.Closet) Console.WriteLine("Number of customers = {0}", СТуреСsqlComd.Parameters(O).Value, Integer))

End Sub

End Module

Метод ExecuteScatar Этот метод применяют, когда нужно получить с уровня данных единственное значение, например число клиентов или идентификатор одного клиента. Следующий пример кода считывает коли-

Анализ и настройка производительности Web-уровня

175

честно записей о клиентах из таблицы Customers базы данных North Wind: Imports System Imports System.Data Imports System.Data.SqlClient Module ExecuteScalar Sub MainC) Dim strConnString As String = "Data Source=.;" & "Initial Catalog=Northwind;" & "Integrated Securtty=SSPI" Dim strSQL As String = "select count(*} from customers" Dim sqlConn As New SqlConnection(strConnString) Dim sqlComd As New SqlCommand(strSQL, sqlConn) sqlConn.Open() Dim о As Object= sqlComd.ExecuteScalarO sqlConn.Close{) Console.WriteLine("Number of customers = {0}", CType(o, Integer)} End Sub

End Module

Метод ExecuteReader Данный метод предназначен для случаев, когда нужно получить одну строку данных или множество строк, содержащих большое число колонок. Метод полезен, если вам нужно выполнить только один просмотр полученных данных. В следующем примере из таблицы Customers базы данных NorthWind считываются идентификаторы, фамилии контактных лиц и номера телефонов клиентов. Imports System Imports System.Data Imports System.Data.SqlClient Imports Microsoft,VisualBasic Module ExecuteReader Sub Hain() Dim strConnString As String == "Data Source=.;" & "Initial Catalog=Northwind;" _

176

Глава 6 & "Integrated Security=SSPI" Dim strSQL As String = _ "select customerid,contactname,phone from customers" Dim sqlConn As New SqlConnection(strConnString) Dim sqlComd As New SqlCommand(strSQL, sqlConn} sqlConn.Openf) Dim sqlDfi As SqlDataReader = _ sqlComd.ExecuteReader(CommandBehavior.CloseConnection) Do While sqlDR.ReadO Console.WriteLine(sqlDR("customerid").ToString() _ & ControlChars.Tab _ & sqlDR.GetSqlString(1).ToString() _ & ControlChars.Tab _ & sqlDR.GetSqlString(2).ToString()) Loop sqlDR.CloseO End Sub

End Module В тех случаях когда вы уверены, что запрос возвратит только один ряд, при вызове данного метода можно задать значение SingleRow перечислимого типа ComtnandBehavior в качестве параметра: Dim sqlDR As SqlDataReader = _ sqlComd.ExecuteReader(CommandBehavior.SingleRow);

Значения полей строки могут быть получены либо по имени, либо по номеру позиции, как показано в предыдущем примере. В общем случае использование номера позиции немного повышает производительность. Кроме того, если вам известны возвращаемые типы данных, то добиться большей производительности можно, используя для получения возвращаемых значений методы провайдера данных SQL Server, специально предназначенные для этих типов. Таких методов несколько, в том числе GetSqtString и Getlnt32, СОВЕТ Старайтесь использовать методы провайдера данных SQL Server для конкретных типов всегда, когда это возможно.

Анализ и настройка производительности Web-уровня

177

Метод ExGcuteXMLReader Этот метод полезен, когда данные SQL Server возвращаются в формате XML. Например, чтобы получить данные в формате XML, оператор SQL можно модифицировать таким образом, чтобы SQL Server возвратил данные в этом формате: Imports System Imports System.Data Imports System.Data.SqlClient Imports System.Xml Module ExecuteXmlReader Sub Main() Dim strConnString As String = "Data Source=.;" & "Initial Catalog=Northwind;" & "Integrated Security=SSPI" Dim strSQL As String = "SELECT customerid," & "contactname," & "phone " & "From customers " & "FOR XML AUTO" Dim sqlConn As New SqlConnection(strConnString) Dim sqlComd As New SqlCommand(strSQL, sqlConn) sqlConn.Open() Dim xmlR As XnuReader = sqlComd.ExecuteXmlReaderQ Do While xmlR.ReadO Console. WriteLine(xmlR. ReadOuterXmlO) Loop xmlR.CloseO sqlConn.Close() End Sub End Module

Типичные «узкие» места Web-уровня «Узкие» места на Web-уровне возникают по разным причинам, например из-за проблем конфигурации, недостатка аппаратных ресурсов, плохой архитектуры приложения или неэффективной программной реализации. Для устранения проблем конфигура-

178

Глава 6

ции следует всегда поддерживать документацию и сценарии сборки приложения з актуальном состоянии и проверять работоспособность конфигурации, особенно после крупных изменений, Эффективное нагрузочное тестирование позволяет выяснить, возможно ли масштабировать Web-приложение, установив дополнительные аппаратные средства. Если вы масштабировали приложение таким образом, необходимо помнить о недостатке этого метода: будьте готовы к дополнительным усилиям по сопровождению оборудования. Масштабирование подробно обсуждается в конце главы. Предпочтительным же считается выявление «узких» мест с последующим исправлением или настройкой кода программ, Это циклический процесс, который требует тестирования производительности и настройки в течение всего жизненного цикла программного обеспечения. В этом разделе мы рассмотрим общие подходы, а также поделимся своим опытом использования новых, более эффективных приемов программирования.

Пример реальной проблемы конфигурации

Предположим, что ваше Web-приложение неравно перенесли из среды разработки в среду эксплуатации. Естественно, вы привели тестирование производительности приложения в среде разработки и получили показатели производительности, которые можно сравнить с результатами тестмрова." ния в среде эксплуатации. При анализе показателей производительности (счетчики и журналы 115) вы обратили внимание-на значительно большие объемы пересылаемых данных при проведении теста в среде эксплуатации. Кроме того, показатели пропускной способности при тестировании в среде разработки оказались гораздо выше. Вы ожидали, что будет наоборот, так как в реальной среде используются до-. лее мощные аппаратные средства, а тестовые сценарии и набор тестовых клиентов одинаков в обоих случаях. Вы начинаете исследовать свой Web-сервер среды эксплуатации для выяснения различий в конфигурации между эксплуатационной и тестовой средой и обнаруживаете, что в файле Web.config в среде разработки включены опции Trace и O&bugf причем это произошло как раз перед тем, как его:>/! . скопировали »а эксплуатационные серверы.

Анализ и настройка производительности Web-уровня

179

Ограничение размера страницы Одна из наиболее частых причин «узких» мест на Web-уровне — бесконечная загрузка страниц. Передача на странице слишком большого объема данных может вызывать проблемы производительности как US-сервера, так и сети. Хотя это кажется очевидным, многие Web-приложения, которые мы анализировали, страдают от больших времен отклика только из-за того, что их страницы слишком велики. Не бойтесь разделить содержимое. Это может стоить вашим пользователям лишнего щелчка мышью, но зато запрашиваемые ими данные будут загружаться гораздо быстрее. Вот несколько советов, следуя которым вы обеспечите более короткое время отклика, что наверняка улучшит впечатление пользователей от вашего приложения: • если ваше Web-приложение возвращает огромные наборы записей, попробуйте разбить результаты выборки на страницы; • уберите из своего кода и HTML пустые промежутки и комментарии, это уменьшит объем данных, пересылаемых по сети; • уберите из таблиц стилей неиспользуемые стили. Оптимальное использование картинок Оптимизируйте все изображения и используйте их умеренно либо когда это действительно необходимо вашему Web-приложению. Повторное использование одной и той же картинки позволяет сократить число сетевых обменов, так как большинство браузеров умеют кэшировать картинку на клиенте, чтобы всякий раз не выкачивать ее с Web-сервера заново. Одна большая картинка эффективнее, чем несколько маленьких. Часто рекламные картинки загружаются в другого сайта, который вам неподконтролен. В крайних случаях это может вызвать тайм-аут загрузки вашей страницы из-за того, что сторонний ресурс стал недоступным или слишком медленно загружается. Если ваш сайт динамичный и содержит много графики, стоит разместить динамическое содержимое и изображения на разных Web-серверах, соответствующим образом настроив каждый из них. Используйте соглашение об именовании Разработайте соглашение об именовании, походящее для вашего случая и обеспечивающее читабельность, стараясь сделать

180

Глава 6

структуру каталогов максимальной «плоской». Давайте короткие названия файлам, каталогам и переменным, применяя сокращения всегда, когда возможно. Это сократит объем данных, передаваемых в каждом запросе, что может иметь большое значение, так как часто HTML-страница ссылается на файлы разных типов (картинки, таблицы стилей, сценарии, исполняющиеся на клиенте и т.п.). Избегайте такой структуры каталогов, как та, что показана следующем URL, содержащем 68 символов: http://yoursite/goodoldunitedstatesofamerica/northcarolina/pictures/ Сократив длину пути в структуре каталогов, вы сэкономите 41 символ только в одном запросе: http://yoursite/us/nc/pics/ Отключение SSL Используйте SSL в Web-приложениях только при необходимости. Протестируйте свои страницы в режимах с использованием SSL и без него, чтобы определить расходы на шифрование данных. В общем случае мы обнаруживали 20- или 30-процентное снижение производительности при использовании SSL. Правильно организовав размещение содержимого своего сайта по разным папкам, вы сможете включать или отключать SSL на уровне каталогов. В большинстве случаев нет необходимости применять SSL для картинок, таблиц стилей и других типов файлов, таких, как сценарии, исполняющиеся на клиентской стороне. Использование новых возможностей На бойтесь пробовать новые методы и средства программирования. Многие новые средства программирования не только обеспечивают дополнительные функциональные возможности, но и повышают производительность по сравнению с существующими. Например, хотя Response.Execute доступен уже достаточно давно, no-прежнему о коде ASP/ASPX встречаются вызовы Response.Redirect, хотя при применении последнего пользователям требуется дополнительный сетевой обмен. Мы видали также много Web-приложений .NET, испытывавших проблемы производительности из-за неэффективной работы со строками в циклах. Часто для их решения достаточно использовать новый класс .NЕТ StringBuikler, который может дать огромный выигрыш

Анализ и настройка производительности Web-уровня

181

в производительности при конкатенации большого числа строк в цикле.

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

Масштабирование вширь, масштабирование вверх или настройка производительности? Обычно масштабируемость достигается двумя схожими методами: масштабированием вширь (scaling out) и масштабированием вверх (scaling up). Эти методы следует использовать только после тестирования производительности и настройки Web-приложения. Тестирование производительности позволяет выявить «узкие» места и ограничения приложения. Настроив производительность, вы повысите пропускную способность, снизите время отклика или решите обе эти задачи. Теперь мы познакомим вас с определениями, а также с доводами за и против масштабирования вширь, масштабирования вверх и настройки производительности. Масштабирование вширь Масштабирование Web-уровня вширь подразумевает установку дополнительных Web-серверов с целью преодоления «узких» мест или ограничений, выявленных на этом уровне. В результате масштабирования вширь, если отсутствуют «узкие» места, связанные с сетью, SQL-уровнем и другими компонентами за пределами Web-сервера, пропускная способность повышается. Недостатком данного метода считается его дороговизна: расходы на аппаратные и программные средства, а также на развертывание прило-

182

Глава 6

жения (электроэнергия, площадь помещения, охлаждение и т.д.}. Кроме того, требуется больше персонала для сопровождения и установки продукта. Масштабирование вверх Масштабирование Web-уровня вверх представляет собой установку в ваши Web-серверы дополнительного оборудования, такого, как память или процессоры, с целью преодоления ((узких» мест или ограничений, выявленных на этом уровне. Этот метод менее затратный по сравнению с предыдущим, так как память и процессоры относительно дешевы в сравнении с покупкой целого компьютера. Однако в этом случае не всегда возможен линейный рост производительности. Обязательно проверяйте правильность принятого решения, сравнивая результаты тестирования производительности до и после модернизации. Настройка производительности Настройка производительности — это просто ликвидация «узких» мест в приложении с целью достижения поставленных критериев пропускной способности и времени отклика. Иными словами — исправьте код вместо добавления аппаратных средств. Если данный метод не применяется во время цикла разработки приложения, то он может оказаться самым дорогостоящим, так как требует больших расходов на оплату труда разработчиков, тестеров и сопровождающего персонала.

Когда следует масштабировать Web-уровень Частая ошибка при создании и развертывании Web-приложения — использование для преодоления «узких» мест множества аппаратных средств. Настройка производительности приложения сэкономит вам время и деньги: вы поймете, когда действительно требуется добавлять новые аппаратные средства путем масштабирования вширь или вверх. В главе 2 описаны этапы определения требований к приложению в зависимости от примерного числа пользователей вашего Web-приложением. Далее рекомендуется протестировать производительность и настроить Web-приложение с целью достижения или превышения оценочных критериев. Для определения максимального числа пользователей для конкретного Web-приложени и для планирования увеличения

Анализ и настройка производительности Web-уровня

183

аппаратных ресурсов стоит также выполнить анализ стоимости транзакции, описанный в главе 9. Масштабирование Web-уровня следует проводить только после того, как выявлены и устранены все иные ограничения производительности. Например, если на SQL-уровне количество пользователей ограничено теми, с которым в состоянии справиться один US-сервер, то сначала следует решить проблемы SQL. He имеет смысла масштабировать ваш Web-уровень, добавляя новые USсерверы или устанавливая в старые сервера дополнительной памяти и процессоров, если SQL-уровень и так работает на пределе.

Разумная достаточность • Допустим, вы организуете океанские круизы и хотите определить, насколько большим должно быть судно, чтобы обслужить максимум клиентов, сохранив качество и ассортимент услуг. Для очень большого судна окажутся закрытыми некоторые маршруты, например через Панамский канал. Если не все билеты на каждый рейс проданы, то расходы на содержание лайнера не оправдаются. Лучшее решение судно, вместимость которого соответствует пиковым требованиям по числу пассажиров и размеру дохода, плюс, возможно, еш,е 5%. Тот же самый принцип применим при расчете объемов аппаратных средств, необходимых для развертывания Web-приложения.

Как масштабируется Web-уровень Для обеспечения отказоустойчивости и избыточности каждое Web-приложение должно использовать не менее двух Web-серверов. Избыточность можно обеспечить и на базе единственного компьютера, но наличие только одного Web-сервера повышает уязвимость приложения в случае поломки этого сервера. Проще всего выполнить масштабирование Web-уровня, установив дополнительные Web-серверы и использовав аппаратно или программно реализованный механизм распределения нагрузки. Программное распределение нагрузки Программное средство распределения нагрузки, разработанное Microsoft, называется Network Load Balancing (NLB). Обычно NLB —

184

Глава 6

это наименее дорогой способ распределения нагрузки, использующий сервисы, которые входят з состав Windows 2000 Advanced Server, Windows 2000 Data Center Edition и Windows .NET Server. Данный метод годится для большинства приложений и позволяет располагать Web-уровень на нескольких узлах. Подробные инструкции и приемы практического применения можно найти по адресу http://www.microsoft.corn. Аппаратное распределение нагрузки Распределение нагрузки с помощью аппаратных средств считается оптимальным, так как вводит дополнительный уровень, отдельный от кода Web-приложения, то есть не занимающий ресурсы Web-сервера. Продукты и решения для аппаратного распределения нагрузки предлагаются многими компаниями, такими, как Cisco, F5 Labs и Extreme Networks. Подробно об установке и настройке аппаратных средств распределения нагрузки рассказано на Web-сайтах вышеупомянутых производителей.

Заключение Ознакомившись с конфигурацией вашего Web-приложения, следует выявить «узкие» места на Web-уровне. При этом приложение профилируют с помощью мониторинга журналов IIS и данных System Monitor, а также выявляют места кода, вызывающие задержки и другие проблемы. Для этого предлагаются новые средства трассировки ASP.NET. Использование, когда это возможно и целесообразно, новых методов и средств, предоставляемых ASP. NET, таких, как кэширование выходнь!х данных, обеспечит значительный выигрыш в производительности.

Глава 7

В этой главе речь пойдет о производительности в отношении к общеязыковой исполняющей среде (common language runtime, CLR). Прежде всего — об особенностях CLR, которые оказывают наибольшее влияние на производительность Web-приложений .NET, и о специальных счетчиках производительности, применяемых для анализа работы стандартного Web-приложения .NET. Кроме того, обсуждаются программы, которые Microsoft использует при профилировании управляемого кода: DevPartner Studio от Compuware и Appmetrics от Xtremesoft.

CLR и производительность CLR представляет собой компонент .NET Framework, отвечающий за то управление, которое мы подразумеваем, говоря об управляемом коде .NE7~(.NET managed code). Для .NET-приложении CLR заменяет ядро Windows, обеспечивая такие жизненно важные функции, как загрузку, управление памятью и защитой, обработку ошибок, а также средства, необходимые для беспрепятственного взаимодействия с другими компонентами и приложениями. Кроме выполнения функций классической исполняющей среды, CLR также осуществляет компиляцию .NET-приложений именно в той системе, в которой они выполняются. В этой книге мы не будем разбирать причины, по которым Microsoft создала новую исполняющую среду, однако мы позна-

t86

Глава 7

комим вас со многими индивидуальными особенностями и компромиссными решениями конструкции CLR.

Microsoft Intermediate Language Самое главное отличие традиционных приложений от .NET-npuложений заключается в том, что последние не компилируются напрямую з «родной» код того процессора, на котором они в конечном итоге будут выполняться. Взамен этого они компилируются с любых языков, поддерживаемых .NET (например, Visual Basic .NET, C + + .NET или С#) в язык MSIL (Microsoft Intermediate Language], после чего упаковываются и распространяются G виде сборок (assemblies) — файла или набора файлов, содержащих объекты, скомпилированные з язык MSIL, а также описывающих их декларацию (manifest).

Примечание Для просмотра содержимого сборки предназначен инструмент ilaasm.exe, который Microsoft предоставляет вместе с .NET Framework. В таком виде код на языке MSIL может анализироваться и управляться CLR. При этом, что можно считать несомненным достоинством, собирается мусор, посредством которого CLR определяет и автоматически удаляет из памяти более неиспользуемые объекты, а также реализуется типовая безопасность з памяти. Последнее означает, что CLR имеет представление о способе обращения к данному объекту в памяти и может заблаговременно удостоверится з том, что исполняемый код будет использовать объект должным образом. Кроме этого управляемый код упрощает взаимодействие приложений и компонентов, написанных на разных языках.

Компилятор по требованию MSIL-код никогда не исполняется. Исполняется машинный код, сгенерированный встроенным з CLR компилятором, который называется компилятором по требованию (Just-in-Time Compiler, JIT). Как правило, код компилируется только по необходимости. В том случае когда процесс первый раз обращается к методу, в дело вступает JIT и компилирует метод. (Если позднее другое приложение или копия этого же приложения обратится к этому методу, они будут вынуждены аналогичным образом скомпилировать

Анализ производительности управляемого кода

187

себе собственную копию метода.) Одной из частей этого процесса является верификация, при которой CLR удостоверяется в безопасности кода, т. е. в том, что он обращается только к тем объектам в памяти, которые для этого предназначены. После того как код скомпилирован, исполнение начинается с адреса, где расположен сгенерированный «родной» машинный код. Наконец, после завершения процесса сгенерированный код уничтожается. Такой подход дает огромное преимущество в производительности по сравнению с классическими Web-приложениями, написанными с использованием ASP. ASP go сих пор является интерпретируемым языком, что подразумевает дополнительные затраты на интерпретацию изначального кода. ASP не преобразует этот код в более рационально скомпилированную форму аналогично тому, как это делает ASP.NET. Тем не менее при сравнении с классическими скомпилированными приложениями все не столь ясно. Компиляция кода в период выполнения вместо улучшения явно оказывает сильное влияние на производительность. Microsoft приняла меры для минимизации этого влияния, и в некоторых случаях код, скомпилированный посредством JIT, даже превосходит свой неуправляемый аналог. Единственным преимуществом компиляции кода во время работы является то, что во время выполнения о рабочей среде известно много больше, чем разработчик вообще может узнать о ней во время проектирования. В некоторой степени код при JlT-компиляции удается оптимизировать, зная число процессоров и их возможности, а также имея сведения о наличии других системных ресурсов и о том, как они в это время используются. С другой стороны, возможности оптимизации ограничены: она имеет смысл лишь тогда, когда затраченное на нее время меньше того выигрыша, который она дает. Признавая это, JIT реализует определенные алгоритмы, чтобы избежать оптимизаций, которые, вероятно, не сэкономят время, эквивалентное по затратам затраченным усилиям.

Примечание Если вы хотите узнать точное количественное определение влияния JIT на производительность, то найдете ряд полезных счетчиков производительности в объекте .N£7 CLRJit.

788

Глава 7

Возможность предварительной компиляции В состав .NET Framework входит инструмент ngen.exe, который используется для компиляции сборок с языка MSIL в «родной» машинный код зо время их установки. Этот процесс называется предварительной компиляцией (Pre-JIT), На первый взгляд предварительная компиляция кажется лучшим вариантом: зачем компилировать во время работы, если компилятор может успешно пользоваться знаниями об особенностях системы и при установке? Но дело в том, что влияние компиляции по требованию сказывается лишь при загрузке приложения. Поскольку Web-приложения редко перезагружаются (если перезагружаются вообще), то особого смысла в предварительной компиляции нет. Еще одна причина отказа от предварительной компиляции заключается в том, что в этом случае нельзя оптимизировать систему на основе сведений о ее состоянии во время ее работы.

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

Жизненный цикл Web-приложения .NET Теперь, после того как вы познакомились с JIT, мы расскажем, каким еще образом CLR влияет на производительность приложения в различных фазах его выполнения. Имейте в виду, что поскольку речь идет о CLR, то не имеет значения, на каком из высокоуровневых языков программирования написаны компоненты приложения — для CLR они представляют собой либо управляемые сборки, написанные на MSIL, либо неуправляемый код, работающий вне CLR.

Период загрузки — домены приложения CLR загружает приложения в специальные, выделенные для них зоны памяти, называемые доменами приложения (AppDomains), Поскольку CLR обеспечивает типовую безопасность в памяти,

Анализ производительности управляемого кода

189

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

Период выполнения — взаимодействие В период выполнения .NET-приложение способно обращаться к неуправляемому коду, например к СОМ-компонентам и к стандартным DLL Windows. Всякий раз, когда исполнение потока затрагивает управляемый и неуправляемый код, говорят, что имел место переход. С такими переходами связаны определенные затраты. Одна из издержек перехода обусловлена обязательным маришлингом аргументов и возвращаемых значений, которыми обмениваются абоненты. Маршалинг — это процесс упорядочения объектов в памяти в соответствии с ожиданием кода, который будет их обрабатывать. Естественно, такие типы данных, как строки и комплексные структуры упорядочить сложнее, чем простые типы данных, такие, как целые числа.

Примечание Например, ресурсоемким маршалингом считается обработка строк, которые часто необходимо преобразовать в другие форматы, например в ANSI и Unicode. Еще одна издержка перехода касается диспетчера памяти CLR, известного как сборщик мусора. (Сборщик мусора более подробно будет обсуждаться далее в этой главе.) Всякий раз при переходе к неуправляемому коду CLR приходится идентифицировать все объекты неуправляемого кода, к которым происходит обращение. Это необходимо для того, чтобы сборщик мусора не удалил эти объекты и, таким образом, не нарушил работу неуправляемого потока. Объекты, идентифицированные как возможно используемые неуправляемым кодом, называют закрепленными (pinned).

Примечание Очевидно, наиболее благоприятное функционирование приложения -- это минимум

190

Глава 7

переходов, необходимых для выполнения данной работы. Используйте при тестировании счетчик # of marshalling обьекта .NET CLR Interop для поиска зон, в которых потоки приложения осуществляют многократный переход между режимами и до его возвращения практически бездействуют. Период выполнения — сбор мусора Одна из наиболее значимых возможностей CLR — автоматическое управление памятью, более известное как сбор мусора. Разработчику нет необходимости реализовывать свое собственное управление памятью, поскольку CLR автоматически выделяет память для объектов при их создании и периодически просматривает, какие объекты приложения используются з данный момент. Более неиспользуемые объекты помечаются как мусор и удаляются, а занимаемая ими память освобождается для новых объектов. Поколения и переходы Поскольку время, затраченное на управление памятью, составляет часть времени работы приложения, то сбор мусора должен осуществляться быстро. Практика показала, что подавляющее большинство объектов обычно нужны лишь в течение короткого промежутка времени. Учитывая это, сборщик мусора распределяет объекты по трем категориям, или поколениям, с номерами 0, 1 и 2. Каждое поколение имеет достаточный размер, который определяет общее число байт, доступное объектам данного поколения. Эти размеры меняются во время выполнения приложения, но их первоначальные значения, как правило, приблизительно составляют 256 кбайт, 2 Мбайт и 10 Мбайт для нулевого, первого и второго поколений соответственно. Самыми младшими считаются объекты нулевого поколения. В это поколение помещаются все объекты, заново созданные приложением. Если места для размещения объекта в поколении недостаточно, начинается сбор мусора. При этом каждый объект проверяется на предмет использования. Объекты, еще востребованные, переходят в первое поколение (их называют пережившими

Анализ производительности управляемого кода

191

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

Примечание У вас может возникнуть вопрос: что произойдет если новый объект окажется настолько большим, что его размер превысит все свободное пространство кучи нулевого поколения? Дело в том, объекты размером более 20 кбайт помещаются в специальную, предназначенную только для них кучу, называемую кучей больших объектов. В объекте .NET ClR Memory вы найдете счетчики производительности для слежения за размером кучи больших объектов. Перемещая объекты в первое поколение, сборщик мусора проверяет, есть ли в нем свободное место. Если это так, то, выполнив сбор лишь в нулевом поколении, сборщик прекратит работу. Однако, если размер перемещаемых объектов превысит размер кучи этого поколения, то сбор мусора аналогичным образом производится и здесь. Как и в предыдущем случае, более не нужные объекты будут уничтожены, а оставшиеся переводятся во второе поколение. Заметьте, что после сбора мусора в куче первого поколения находятся лишь объекты, недавно перемещенные из нулевого поколения. Для освобождения пространства под новые объекты второе поколение, аналогично первому, также подвергается сбору мусора. При этом неиспользуемые объекты, как всегда, уничтожаются, однако выжившие уже никуда не перемещаются, а остаются на месте. Таким образом, непосредственно после сбора в куче второго поколения находятся как выжившие, так и недавно перемещенные объекты. Непосредственно после сбора содержимое кучи перегруппируется таким образом, чтобы объекты занимали смежные области памяти. Такую кучу называют уплотненной.

192

Глава 7

Имейте Б виду: если сбор происходит в первом поколении, то он происходит и в нулевом поколении. Всякий же раз, когда сбор мусора затрагивает и второе поколение, говорят, что сборщик мусора сделал полный проход, так как сбор произошел во всех поколениях. До тех пор пока во время сбора необходимо перемещать лишь несколько объектов, процедура считается эффективной — при минимальной работе освобождает наибольший объем памяти. Для поддержания эффективной работы в сборщике мусора предусмотрена возможность саморегулировки, с помощью которой изменяются размеры младших куч в соответствии с интенсивностью перемещения объектов. А именно: если из одной кучи в другую перемещается слишком много объектов, увеличивается размер младшей кучи, что снижает необходимую периодичность сбора. Если же, наоборот, объекты практически не покидают кучу, ее размеры уменьшаются и за счет снижения рабочего набора приложения производительность повышается. Единственным исключением является второе поколение: поскольку объекты из него не перемещаются, сборщик мусора может лишь увеличивать его размер по мере заполнения. Если же размер кучи второго поколения данного приложения неуклонно увеличивается в течение длительного промежутка времени, это, вероятно, сигнал к тому, чтобы проанализировать приложение на предмет уменьшения времени жизни объектов. Если поколение второго уровня больше не способно принять перемещаемые объекты, это означает, что сборщик мусора не может найти свободное место для размещения новых объектов, и попытка создания новых объектов приведет к исключению System.OutOfMemory Exception. Сборщик мусора старается удерживать размер кучи нулевого уровня в пределах размера кэш-памяти второго уровня. При этом минимизируются издержки на обращение к памяти при наиболее частых операциях сбора мусора. Анализируя работу своего приложения, полезно обратить внимание на то, позволяет ли оно сборщику мусора использовать данную оптимизацию. Закрепленные объекты Как упоминалось ранее, закрепленными называют объекты, помеченные как возможно используемые потоками, выполняющи-

Анализ производительности управляемого кода

193

ми неуправляемый код. Во время работы сборщик мусора должен игнорировать такие объекты. Это необходимо по той причине, что изменение адреса объекта о памяти (со время уплотнения или перемещения) обычно вызывает серьезные сбои в неуправляемом потоке. Поэтому до тех пор, пока объект является закрепленным, сбор мусора его не затрагивает. Сборщик мусора не может управлять и использовать память, занимаемую закрепленными объектами. Следует отметить, что закрепленные объекты, как правило, располагаются в местах, где приложение интенсивно использует неуправляемый код. Завершение Некоторые объекты имеют ссылки не неуправляемые ресурсы, например сетевые сокеты или мьютексы. При уничтожении такого объекта обычно теряется ссылка, поэтому разработчики могут предписать сборщику мусора, чтобы объект перед удалением в обязательно порядке проводил очистку — завершение (final ization). Завершение немного снижает производительность. Например, сборщик мусора не может удалить объекты, ожидающие завершения, пока этот процесс не будет завершен. Более того, если такой объект ссылается на другие объекты, последние расцениваются как использующиеся даже в том случае, если они таковыми не являются. В отличие от сборщика мусора, программист не имеет возможности контролировать процесс завершения напрямую. И поскольку никто точно не скажет, как скоро произойдет завершение, возможна блокировка больших объемов памяти из-за скопления ожидающих этой процедуры объектов. Во время сбора мусора ожидающие завершения объекты не удаляются, а переходят в следующее поколение. Этот переход отслеживается счетчиком Finalization Survivors объекта .N£7 CLR Memory. Кроме этого, переход осуществляют и те объекты, на которые ссылаются завершенные объекты. Их переходы отслеживаются счетчиком Promoted Finalization объекта .NET CLR Memory. При мониторинге приложения важно избегать чрезмерной загрузки памяти объектами, прямо или косвенно подвергающимися завершению.

194

Глава 7

Сборщик мусора на серверах и рабочих станциях Всякий раз, когда происходит сбор мусора, сборщик мусора должен приостановить исполнение потоков, осуществляющих доступ к объектам, положение которых в памяти будет изменяться при переходе в другое поколение и уплотнении. Выбор наилучшего режима работы сборщика мусора зависит от типа приложения. Персональным приложениям, которые взаимодействуют непосредственно с отдельным пользователем, как правило, требуется меньшее число объектов памяти, чем Web-приложениям, которые обслуживают сотни и тысячи пользователей. Таким образом, в данном случае уменьшение латентного периода для сбора мусора имеет более высокий приоритет, чем увеличение скорости освобождения памяти. Итак, для сборщика мусора Microsoft предлагает два режима работы. При этом заметьте: наилучший режим не выбирается автоматически — CLR задает режим Workstation CC (mscorwks.dll) до тех пор, пока разработчик не укажет, что необходимо использовать режим Server GC (mscorsvr.dll).

Примечание По нашему опыту для большинства сценариев Web-приложении лучшую производительность показывает режим Server CC. Период выполнения — исключения Всякий раз когда метод сталкивается с неразрешимой в ходе обычного исполнения ситуацией, он создает объект исключение, описывающий непредвиденное условие (например, нехватку памяти или отказ в доступе). В таком случае говорят, что поток предупреждает CLR о наличии сбоя и невозможности продолжить выполнение вплоть до устранения исключения. Способ устранения исключения зависит от наличия у приложения кода для исправления исключения. CLR либо остановит приложение, так как ему не удается устранить исключение должным образом, либо задействует соответствующий обработчик исключений, после чего приложение продолжит выполнение. (Приложение можно настроить так, чтобы его работа должным образом завершалась после устранения определенных исключений; в этом

Анализ производительности управляемого кода

195

случае говорят, что приложение продолжает выполняться лишь для корректного завершения.) Предположим, что метод main() обращается к методу foo(), который в свою очередь обращается к методу barf), а последний генерирует исключение System.FileNotFoundException, Пока поток ищет соответствующий сгенерированному исключению фильтр, CLR приостанавливает его выполнение. Метод Ьаг<) может обладать обработчиком исключений с фильтром для System.DivideByZeroException. Если исключение FileNotFoundException к этому фильтру не подходит, CLR продолжит поиск подходящего фильтра. Если ни один из фильтров, заданных функцией bar(), так и не подошел к исключению, то система направит стек вызовов к той функции, которая обратилась к Ьаг(). В нашем случае это функция foo(). Теперь предположим, что foo() обладает обработчиком для исключений System.FileNotFoundException. Тогда этот обработчик будет задействован, и произойдет перехват исключения. Говоря о глубине перехвата (throw-to-catch depth), мы имеем в виду число уровней, которые CLR необходимо пройти по стеку вызовов для нахождения соответствующего обработчика исключений, В нашей гипотетической модели эта глубина равняется 1. Если бы функция Ьаг() перехватила свое собственное исключение, глубина стала бы нулевой, А если бы CLR потребовалось проделать весь обратный путь вплоть до функции mainf), глубина равнялась бы 2. Как только исключение перехвачено, приложение возобновляет работу в блоке программы, носящем название заключительного блока. Цель заключительного блока — произвести очистку после всех операций, которые могли быть прерваны исключением. Наличие заключительных блоков не обязательно, однако каждый блок, находящийся между методом, сгенерировавшем исключение и его перехватившим, должен быть выполнен, прежде чем приложение возобновит нормальное выполнение. Таким образом, если каждая из функций foo() и bar() в нашем примере обладает заключительным блоком, то оба блока будут выполнены, прежде чем программный поток вернется к нормальной работе. Если же разработчик решит не записывать заключительный блок для функции bar(), а только для foo(), то будет выполнен блок лишь этой функции.

196

Глава 7

Исключения неуправляемого кода Когда неуправляемый код генерирует исключение, которое не может перехватить сам, оно преобразуется в .NET-исключение и CLR будет пытаться его устранить. Как и в случае других .NETисключений, если CLR не сможет устранить исключение, то она остановит выполнение приложения. Неуправляемые исключения, не затрагивающие CLR, не регистрируются никаким счетчиком производительности CLR .NET. Однако .NET-исключения неуправляемого кода будут регистрироваться счетчиками # of Exceps Thrown. При этом счетчик производительности Throw to Catch Depth считает только стековые фреймы среды .NET. В результате чего отображаемая глубина перехвата окажется меньшей реальной. Исключения и производительность Устранение исключений является ресурсоемким процессом. Когда CLR просматривает стек вызовов в поиске надлежащего обработчика исключений, выполнение затрагиваемого потока приостанавливается. А если обработчик найден, то он вместе с некоторым количеством заключительных блоков должен иметь возможность выполнить свою работу до возобновления нормального выполнения. Предполагается, что исключения — события не частые. Также считается, что затраты на их пошаговое устранение окупают получаемый прирост производительности. При мониторинге характеристик приложения возникает соблазн поиска наиболее ресурсоемких исключений. Однако к чему настраивать приложение для ситуации, возникновение которой не предполагается? Приложение, которое быстро избавляется от исключений, по-прежнему вместо реальной работы тратит усилия на борьбу с ними. Таким образом, мы рекомендуем вам идентифицировать те зоны, в которых наиболее часто возникают исключения, и дать им необходимое время для того, чтобы приложение смогло продолжить нормальное выполнение.

Счетчики производительности .NET Теперь, после знакомства с факторами .NET Framework, оказывающими прямое влияние на производительность Web-приложения, мы проанализируем несколько счетчиков .NET, которые

Анализ производительности управляемого кода

197

позволяют оценивать производительность .NET Framework и управляемого кода. Мы не будем рассматривать здесь осе существующие счетчики, поскольку это потребовало бы куда больше места, чем объем этой главы. Мы познакомим вас с теми счетчиками, которые обладают оптимальным соотношением «цена/ качество». По нашему мнению, эти счетчики в кратчайшее время помогут вам собрать почти всю информацию о приложении. Заметьте: этот подкласс счетчиков не отражает всех возможностей мониторинга производительности Web-приложения .NET. В зависимости от архитектуры системы вам, возможно, придется использовать другие счетчики .NET, и даже те, которые не имеют непосредственного отношения к .NET.

Совет Если вы заинтересованы в том, чтобы сбор данных о производительности был включен в разрабатываемую вами программу, задействуйте пространство имен System.Diagnostics.PerformanceCounter. Объект .NET CLR Memory Все счетчики этого объекта показывают, каким образом .NET framework использует память. Независимо от того, работаете ли вы с Web-приложением .NET или с персональным приложением .NET, эти счетчики помогут вам оценить использование памяти системы. Однако они не отслеживают расход памяти неуправляемым кодом, даже в том случае если код является частью анализируемого приложения. Поэтому, когда приложение включает управляемый и неуправляемый код, полученные данные об использовании памяти будут неполными. Счетчик # GC Handles Счетчик # GC Handles отражает число описателей сборки мусора, используемых в данных момент. Это описатели управляемой среды и ресурсов, находящихся вне CLR. Единственный описатель может занимать лишь небольшой объем памяти управляемой кучи, однако представляемые им неуправляемые ресурсы вносят существенный вклад в снижение производительности приложения. Весьма вероятна высокая активность СС-описателей в случае создания множества объектов Web-приложением.

198

Глава 7

Например, если сценарий отдельного пользователя требует назначения неуправляемого ресурса типа сетевого сокета, каждый раз при выполнении этого сценария пользователем содержащий массив объект создается вместе с соответствующим описателем GC. При большой загрузке, особенно во время обращения к этому сценарию, ваш Web-сайт создает большое количество GCобработчиков, что в некоторых случаях приводит к нестабильной работе приложения. Счетчик # Gen 0 Collections Этот и два следующих счетчика важны для оценки эффективности очистки памяти. Счетчик # Gen 0 Collections показывает, сколько раз выполнялся сбор мусора в нулевом поколении с начала работы приложения. Всякий раз при сборе мусора используемые объекты нулевого поколения осуществляют переход в первое поколение. Как уже говорилось, единственным условием, при котором происходит переход из нулевого поколения, является необходимость создания в нем нового объекта, требования которого к памяти превышают имеющиеся. В этом случае используемый объект перейдет с уровня нулевого поколения и освободит ресурсы для создаваемого объекта. Интенсивность сборов в нулевом поколении обычно соответствует интенсивности, с которой приложением выделяется память. Счетчик # Gen I Collections Этот счетчик показывает, сколько раз производился сбор кучи первого поколения с начала работы приложения. Использовать его следует аналогично счетчику # Gen О Collections. Интенсивный сбор мусора в первом поколении — признак нехватки ресурсов, выделенных для объектов, осуществляющих переход из нулевого поколения. В этом случае осуществляется переход объектов во второе поколение, в результате чего тратится больше ресурсов на том уровне. Счетчик # Gen 2 Collections Этот счетчик регистрирует, сколько раз объекты второго поколения подвергались сбору мусора с начала работы приложения. Из трех счетчиков, анализирующих информацию о сборе мусора на уровне поколений, счетчик # Gen 2 Collections считается наиболее важным. В случае его высокой активности при работе

Анализ производительности управляемого кода

199

с Web-приложениями может потребоваться перезапуск процесса aspnet_wp. Это произойдет, когда ресурсы займут всю память второго поколения. Перезапуск приводит к выделению дополнительной памяти. Счетчик # Total Committed Bytes Этот счетчик регистрирует объем виртуальной памяти, занимаемой приложением. Понятно, что в идеале приложение должно занимать по возможности меньшую память для снижения загрузки сборщика мусора. Счетчик % Time in GC Этот счетчик показывает количество бремени, потраченное сборщиком мусора на сбор и уплотнение памяти. Если приложение не оптимизировано, вы увидите, что сборщик мусора работает непрерывно, осуществляя перевод и удаление объектов. Счетчик Gen 0 heap size Счетчик сборщика мусора Gen 0 heap size показывает максимальное количество байт, которое может быть выделено нулевому поколению. Сборщик мусора динамически регулирует объем памяти первого поколения, изменяя его во время выполнения приложения. Уменьшенный размер кучи свидетельствует об экономии памяти и, таким образом, позволяет GC снизить размер рабочего набора приложения. Счетчик Gen 0 Promoted Bytes/sec Этот счетчик показывает количество байт, перемещаемых в секунду из нулевого поколения в первое. Приложение может работать с большим числом переходов, однако, если переход осуществляют объекты небольшого размера, вы не увидите высокой активности этого счетчика. Поэтому его следует использовать вместе со счетчиком # Сел 1 heap size, чтобы узнать, являются ли переходы следствием плохого распределения ресурсов на первом уровне. Счетчик Gen 1 heap size Этот счетчик показывает текущее число байт первого поколения, В отличие от Gen 0 heap size он не выводит максимальный размер первого поколения, а показывает текущий объем памяти,

200

Глава 7

выделенный для его объектов. При работе с этим счетчиком вам одновременно потребуется счетчик # Сел 0 Collections. С увеличением количества сборов в нулевом поколении вы обнаружите одновременный рост объема кучи первого поколения. В конечном счете назреет необходимость перемещения объектов во второе поколение, что приведет к неэффективному использованию памяти. Счетчик Gen 1 Promoted Bytes/sec Счетчик Gen 1 Promoted Bytes/sec показывает — какое количество байт в секунду осуществляет переход из поколения 1 в поколение 2. Как и в случае с Gen 0 Promoted Bytes/sec, вам следует использовать Gen 1 Promoted Bytes/sec вместе со счетчиком Gen 2 heap size. Вместе они дадут вам исчерпывающую информацию о количестве выделяемой для перемещаемых во второе поколение объектов памяти. Счетчик Gen 2 heap size Этот счетчик показывает текущее число байт во втором поколении. При мониторинге приложения с большим количеством переходов во второе поколение будет наблюдаться увеличение размера кучи, поскольку находящиеся здесь объекты нельзя переместить далее.

Объект .NET CLR Loading Описанные в этом разделе счетчики объекта .NEТ CLR Loading при совместном использовании с другими счетчиками типа % Processor Time (% загруженности процессора! предоставят вам подробную информацию о влиянии, которое оказывает на системные ресурсы загрузка .NET-приложений, доменов приложений, классов и сборок. Счетчик Total AppDomains Этот счетчик показывает максимальное число доменов приложений (AppDomains), загруженных с момента запуска приложения. Как было сказано ранее, домены приложения — безопасное и универсальное средство обработки данных, которое используется CLR для обеспечения изолированной работы приложений в одном и том же процессе. Для Web-приложений иногда необходимо использовать множество приложений внутри процесса

Анализ производительности управляемого кода

201

aspnet_wp. С точки зрения производительности знание числа выполняющихся G данный момент доменов приложений является критическим, так как каждый раз, когда вы создаете или удаляете домен приложения, системные ресурсы испытывают дополнительную нагрузку. Также важно знать о взаимодействии между доменами приложений. Например, если ваши приложения во время выполнения должны выходить за границы домена, то будут иметь место контекстные переключения. Как вы уже знаете из главы 4, они являются ресурсоемкими. Особенно это заметно, если на сервере происходит более 15 000 контекстных переключений в секунду. Счетчик Total Assemblies Этот счетчик показывает общее количество сборок, загруженных с начала работы приложения. Сборки могут быть загружены как домено-нейтральные, когда их код совместно используется всеми доменами приложения, или как домено-зависимые, когда их код предназначен лишь для конкретного домена. Если сборка загружена как домено-нейтральная, прирост активности счетчика будет однократный. Вам следует знать об общем количестве сборок загруженных на сервере из-за ресурсов, которые необходимы для их создания и уничтожения. Иногда разработчики загружают сборки, которые на самом деле не являются обязательными для приложения. Счетчик Total Classes Loaded Этот счетчик показывает общее количество классов, загруженных во всех сборках с начала работы приложения. Каждый загруженный класс не является статическим, поэтому обладает конструктором. При обращении к классу разработчик должен создать его экземпляр, что сильнее сказывается на ресурсах чем однократное создание объекта и обращение к его методу. Объект .NET CLR LocksAndThreads При поиске «узких» мест, относящихся к потокам или процессам, лучше всего начать с объекта .NET CLR LocksAndThreads. Здесь мы обсудим те счетчики объекта .NET CLR LocksAndThreads, которые позволяют быстро и эффективно устранить возможный конфликт.

202

Глава 7

Счетчик Contention Rate/sec Этот счетчик показывает, сколько раз з секунду во время выполнения поток делает неудачные попытки запроса управляемой блокировки. Следует отметить, что в случае тяжелого конфликта потоки не обязательно получают блокировки в запрашиваемом ими порядке. Счетчик Total # of Contentions Этот счетчик показывает общее число неудачных попыток запроса управляемой блокировки, сделанных потоком в CLR. Счетчик Current Queue Length Этот счетчик показывает общее число потоков, ожидающих в данный момент управляемые блокировки. Если вы видите, что при постоянной загрузке приложения показания счетчика непрерывно увеличиваются, то, возможно, имеет место неразрешимая блокировка. Различие между неразрешимой и разрешимой блокировкой заключается в том, что неразрешимая блокировка возникает, когда ошибка в логике кода приложения делает невозможным снятие блокировки с объекта.

Объект .NET CLR Exceptions Производительность приложений, которые генерируют очень много исключений, может быть очень низкой. В идеале приложение не должно генерировать исключений вообще. Однако часто разработчики намеренно включают генерацию исключений как часть процесса проверки ошибок. До запуска производства приложения такой код, генерирующий исключение, необходимо удалить. Здесь мы показали два счетчика объекта .NET CLR Exceptions. Если вы решите использовать лишь один из них, тогда советуем выбрать Exceps Thrown/sec. Если его показания превысят 100 исключений в секунду, это можно считать веским основанием для проведения дополнительного исследования кода приложения. Счетчик # of Exceps Thrown Этот счетчик показывает общее число исключений, сгенерированных после запуска приложения. Он регистрирует как .NETисключения, так и неуправляемые исключения, преобразованные

Анализ производительности управляемого кода

203

з .NET-исключения (например, исключение из-за ссылки на несуществующий указатель в неуправляемом коде повторно генерируется в управляемом коде как исключение .NET System.NullReferenceException). Однако он не регистрирует исключения, сгенерированные и перехваченные в неуправляемом коде. Этот счетчик учитывает как обработанные, так и необработанные исключения, а также те, что генерируются повторно. Применяйте это великолепное средство для определения части кода, которая может генерировать большое количество исключений. Для определения необходимо сделать разбор программы с одновременным контролем счетчика. В случае внезапного скачка в подсчете исключений вы можете вернуться и просмотреть исполняемый в этой части программы код, чтобы точно локализовать место генерации исключений. Счетчик # of Exceps Thrown /sec Этот счетчик показывает количество исключений, генерируемых в секунду. Он регистрирует как .NET-исключения, так и неуправляемые исключения, преобразованные в .NET-исключения однако не регистрирует исключения, сгенерированные и перехваченные в неуправляемом коде. Кроме этого, он учитывает как обработанные, так и необработанные исключения. Как уже говорилось, если вы заметили, что число исключений в секунду составляет 100 и более, то вам необходимо проанализировать исходный код длл определения причины и места, где генерируются эти исключения.

Объект .NET CLR Security В зависимости от того, сколько внимания вы уделяете безопасности Web-приложения, вы будете либо очень активно пользоваться предлагаемым в этом разделе набором счетчиков, либо не пользоваться им вообще. Эти счетчики необходимо применять лишь в том случае, когда это действительно нужно. Несмотря на то, что проверка безопасности снижает производительность приложения, проводить ее необходимо. Однако неправильное использование средств безопасности .NET Framework не только создает бреши в безопасности, но и снижает производительность приложения.

204

Глава 7

Счетчик # Link Time Checks Работая с этим счетчиком, вы часто будете наблюдать его повышенную активность. Это может ввести в заблуждение, если не разобраться, чем она вызвана. Впрочем, это справедливо и для других счетчиков. Отображаемые показания не указывают на значительное ухудшение производительности, а лишь свидетельствуют об активности системы безопасности. Счетчик показывает, сколько всего после запуска приложения выполнено проверок защиты по правам доступа кода (Code Access Security, CAS) в период связывания. Проверка в период связывания осуществляется один раз для каждого вызывающего объекта и на одном уровне и, таким образом, она менее ресурсоемка, чем проход по стеку. Счетчик % Time in RT checks Этот счетчик показывает, сколько времени в процентах затрачено на проверку CAS в период выполнения, после последней аналогичной проверки. Счетчик обновляется в конце проверки и показывает не среднее, а последнее зарегистрированное значение. Если значение этого счетчика большое, то вам необходимо проанализировать — что проверялось и как часто. Причиной может быть излишняя глубина обхода стека (счетчик Stack Walk Depth будет обсуждаться далее) или многочисленные проверки в период связывания. Счетчик Stack Walk Depth Этот счетчик показывает глубину стека во время последней проверки CAS в период выполнения. Такая проверка осуществляется посредством прохода по стеку. Это, например, происходит, когда приложение обращается к объекту, у которого четыре метода (А — D). Если код обращается к методу А, глубина прохода по стеку равна 1. Однако если бы вы обратились к методу D, который в свою очередь обращается к методам С, В и А, глубина обхода стека оказалась бы равной 4. Счетчик Total Runtime Checks Этот счетчик показывает общее число проверок CAS в период выполнения после запуска приложения. Проверки CAS в период выполнения происходят при обращении вызывающего объекта

Анализ производительности управляемого кода

205

с запросом о конкретном разрешении. Во время проверки рассматривается текущий стек потока вызывающей программы. Используя данные этого счетчика и счетчика Stack Walk Depth, зы получите исчерпывающее представление о потерях производительности во время проведения проверки безопасности. Большое количество общего числа проверок в период выполнения и большая глубина стека свидетельствуют о потере производительности.

Профилирование управляемого кода В этом разделе речь пойдет о том, как профилировать управляемый (или неуправляемый) код с помощью DevPartner Studio 7.0 от Compuware. Сейчас представлено довольно много профилировщиков, но здесь в качестве примера мы взяли DevPartner Studio, используемый командой АСЕ.

Знакомство с Compuware DevPartner Studio DevPartner Studio Professional Edition от Compuware Corporation поможет вам создавать надежные и высокопроизводительные приложения. Анализ производительности облегчит поиск и точную локализацию критических элементов в коде, сторонних компонентах или операционной системе даже в случае отсутствия исходного кода. Пробную версию DevPartner Studio 7.0 Professional Edition можно получить на http://www.compuware.com/products/ devpartner/. Профилирование с помощью DevPartner Studio Во многих приложениях за производительность в большой степени отвечает лишь относительно небольшая часть кода. Главная задача — быстро ее найти, чтобы разработчики могли сосредоточиться на том фрагменте, повышение производительности которого с высокой вероятностью увеличит общую производительность приложения. Во время анализа рабочих характеристик DevPartner Studio измеряет частоту и время выполнения кода вплоть до отдельной строки применительно к широкому ряду компонентов: Visual Basic,

206

Глава 7

Visual C + +, Visual Basic .NET, C#, Visual C, C/C+ + , а также к Webприложениям с ASP.NET, (Script и VBScript и при использовании IE или IIS. Сбор данных о производительности при помощи DevPartner Studio не вызывает затруднений. В случае управляемого кода просто запустите приложение, предварительно активировав Performance Analysis. В случае неуправляемого кода активируйте Instrumentation Manager и перекомпонуйте приложение. Один из возможных способов — первоначально собрать характеристики на уровне метода (а не строки), чтобы выявить наиболее ресурсоемкие методы. Далее следует собрать данные уже на уровне строки. Так вы быстро выявитье группы методов, претендующие на улучшение в первую очередь.

Примечание Чтобы не собирать данные для всех системных файлов, проверьте переключатель Exclude System Images в окне DevPartner Performance and Coverage Exclude Images. После оптимизации исходного кода установите этот переключатель таким образом, чтобы активировать изучение использования приложением системного кода. Это особенно важно в случае использования .NET Framework. Окно Session По окончании выполнения приложения характеристики производительности выводятся в окне Session, как это показано на рис. 7-1. В левой панели перечислены исходные файлы и системные образы, используемые во время сессии, а также процент затраченного в период выполнения времени на каждый файл. Вы можете быстро просмотреть любой файл, а также содержащиеся в нем методы. Имейте в виду, что в данном примере мы используем приложение со смесью «родного» C + + и С# кода. Кроме того, вы можете отобрать группы полезных файлов или методов (например, 20 наиболее используемых методов), чтобы сконцентрировать внимание на коде, который используется большую часть времени выполнения приложения или обращения к которому наиболее часты. Справа расположена панель данных,

Анализ производительности управляемого кода

207

на которой перечислены методы и их исходный код, а также итоговая информация. КД Д. Ш1 ч гг ...^.тегдм ДГСД.ДДГ^

•- И(||( Modulus !!7MBttoj5 :,Эва , ГЕ Jjj R5RAIGHT_W2t: - НЕ: (Drivel)

nleinudl.!} jsoncsln мвИиа

!•' 13 System(91.2%) ЕЭ Top ZO Source Methods H Top20M«hPds " '] 1ННННМЯНЛВЛ1^1Я И "те ЭЭ Called Methods

',*n

• j •«]*#! !

_4^>n*;*ijct ^ЛТ.С|_ •,iregnedril,drs4n»dir,:,ong) c SpftedBumo Dr i.-c> . jr ..etc. . SpeedBurnp Cf-er.Far Mel CjulcfrjortOnt.inlj 5peed8urno D-«4r.Fo С-яхие 5peed6urna O"Sr.Fo f.jl-eCppRr Ckc< UtiveCppSpMlBljnpC lug [.Цлт 5peedBump Driver. Fo .FormLLaad SpeedBump Driver. Fo VBdjlNetBtnj: :1 :pe?1hump Driver. Fo Ma-agedCppHn_O<* P P P -

„j

»^

„„, ...... '^.jg ••-- — ? i

'"J(5*!<5«&5)

0.9 0,5 0.4

21. S 31.5 11.0

Э9.109 302 [

0.0 0.0 0.0

60.2 0.7 0.5 33.3

L 799 1 1

1.999 ( 3.5Э6 119

o.o

::.i

[

0.1

;2C г 25.2S1

0.0

^-0.0 0.0

0.0 0,0 0,0

1 0 С

I С

Ш5

Рис. 7-1.

Окно Session DevPartner Studio

уцжжш ш"'иМт7!ШЖ-ШИ!Г^^^А' : 1

РЙе

§*t

U w

Prnip.t

iff- ' -J ' 1- ; И Й

&jiW

*"•"-,"*

t^'bij'j

f - ih

L-i^^

]ft'-^^w

Й^й

I'"

-',

^ Щ Performance anah,,-,

t -'ebua -

: -

^iDJ^J

-.°:»

.-;..

"^^'*?? ii

Orwpr.dCTFf Мг-tod y:l

» te >1*!-а;и.-»1( ; SBSSDC SirinawJ

Counl

Si.wiih duldjeri

79 213 73 213 =

0.2 '

Т1п»..?9нгёе

14 122.1

_^ •

{

1.4 ! 112 654.1 4 . 1 : Э.ЭЭ 241.1 1.0 82 013. 1 2 . 0 . 165 624.1

НИНЕ ИРЬох - G e t b l g l t e m (cjhHndDlcj, ICC PICTUHZBOX) ; HDi: hDC - йгсЬС (йЯэок) ; MoveToEx (hDC, 0, 1, NULL ; HPEK hOldPen - (HPCH) S f f l f f g t O b j e o t l h D C , GetScccltOfcJect ( E L A C

IS 216

1.7 139 3 4 1 . 6 6 . 0 485 0 9 2 . 9 1.1 ; 69 3 5 3 . 4

Select Object ( h D C , GelStocrteCbject (TJHITE P E N ) ) ; LineTo ( h D C , aiEleHirnt.3, 11: SeleccCbJeec (hDC, hOJdPenl ;

78 218

D.2 !

73 213 : 73

213 E

78 213 78 213 T6 21Б

ss=

18 7 5 3 . 6

> у

Jj|

Рис. 7-2. Окно Source Code DevPartner Studio Один из приемов работы — сортировка сессионных данных по среднему времени, которое затрачивается на каждый метод, с последующим анализом на предмет улучшения наиболее ресурсоемких методов. Выбрав на панели данных окна Session метод, вы сможете подробно изучить исходный код. На рис. 7-2 покаi-568'

208

Глава 7

зан пример исходного кода, который аннотирован числом выполнений каждой строки кода, процентом времени, затраченного на вызываемые (дочерние) функции, и общим количеством времени, затраченным на выполнение строки кода. Кроме того, выделяется наиболее ресурсоемкая строка, которая может служить «отправной точкой» для дальнейших изменений в выбранном коде. Окно Method Details Другой способ повысить производительность — исследовать взаимоотношения между функциями, к которым происходит обращение в приложении. Как и прежде, сначала необходимо выбрать метод. Описание метода включает методы, к которым он обращается, и методы, которые обращаются к нему (рис. 7-3). В верхнем разделе окна идентифицируется выбранный метод и указаны характеристики его производительности. В разделе Parents перечисляются все методы, которые к нему обращаются, а в разделе Children — все методы, к которым обращается он сам. Режим просмотра Method Details позволит вам разобраться во взаимоотношениях вызовов метода и происходящих при этом затратах, а просмотрев последовательность вызовов, вы лучше поймете работу кода и влияние вызовов на инфраструктуру.

Рис. 7-3. Окно Method Details DevPartner Studio

Анализ производительности управляемого кода

209

Работа с распределенными приложениями DevPartner Studio генерирует отчет о рабочих характеристиках распределенных приложений, включая приложения, работающие з Web. Программа позволяет осуществлять комплексное профилирование распределенных приложений с компонентной структурой. В случае Web-приложений DevPartner осуществляет сбор данных о приложениях, созданных в Visual Studio .NET, а также об использующих языки сценариев, поддерживаемые IE и IIS. Во время работы распределенного приложения DevPartner может получать информацию о каждом отдельном локальном или удаленном процессе, включая сессионные данные на сервере и сопоставлять эти данные. При сопоставлении данные о разных процессах объединяются в один файл. DevPartner автоматически сопоставляет сессионные данные с различными процессами, а именно: •

с обращениями на основе протокола DCOM между методами в различных процессах;

•

с HTTP-запросами, о которых в качестве клиента выступает IE, а в качестве сервера — I IS.

Чтобы сохранить связь между методами объектов DCOM, а также связь между клиентом HTTP и сервером (IE и IIS), DevPartner автоматически сопоставляет полученные из этих сессий данные. Затем он объединяет сопоставленные данные с данными клиента в один сессионный файл. В режиме просмотра Method Details вы можете просмотреть этот файл и методы. В том случае если связи на основе протокола СОМ или связи клиент/сервер между IE и MS не существует, стоит использовать команду Correlate Performance Files, выбрав Tools в меню DevPartner, чтобы объединить данные различных сессий вручную. Эффективный анализ производительности .NET .NET Framework очень сложна и богата возможностями. В ней удается достичь много, используя лишь несколько строк кода. Это удобно разработчикам, однако создает трудности при настройке производительности приложения. Например, вы можете обнаружить, что 95% времени выполнения приложения занимает

210

Глава 7

.NET Framework. Как повысить производительность в этом случае? В следующих разделах описаны основные принципы повышения продуктивности анализа с помощью DevPartner Studio. Определите измеряемые параметры Прежде чем начать сбор данных о производительности, проанализируйте работу приложения. Например, при профилировании Web-сервиса или приложения ASP.NET попробуйте спрогнозировать, как кэширование будет влиять на получаемые результаты. Например, если во время теста постоянно вводятся одни и те же данные, приложение начнет выбирать страницы из кэша, и данные о производительности окажутся искаженными. В таком случае попробуйте обеспечить различие вводимых данных или, что проще, отредактировать конфигурационный файл машины таким образом, чтобы во время теста кэширование отключалось. Закомментируйте следующую строку: odd name="OutputCache" type="System.Web.Caching.OutputCacfieModule''/^ Учитывайте начальные затраты

.NET Framework осуществляет много единовременных инициализаций. Чтобы это не искажало результаты, тестируйте приложение, профилируя все функции, а затем, с помощью кнопки Clear на панели инструментов Session Control, удалите данные. После запустите тест, проверяющий те же функции для получения более точной картины о производительности. Учитывайте затраты .NET Framework

Используйте счетчик % with Children на вкладке Method List или Source, чтобы узнать, как много времени тратит .NET Framework. С помощью окна Child Methods вкладки Method Details проверьте .NET Framework, чтобы выяснить, какие методы являются ресурсоемкими и почему, Переработайте приложение таким образом, чтобы число выполняемых им действий стало меньше, или не так часто обращайтесь к .NET Framework. Осуществите полный сбор данных о распределенных приложениях

При анализе производительности Web-приложения, многоуровневых клиент-серверных приложений или приложений, использующих Web-сервисы, включите в тест все компоненты удален-

Анализ производительности управляемого кода

211

ных приложений. Применяйте DevPartner Performance и Coverage Remote Agent для настройки сбора данных о производительности на удаленных системах. Если ваше приложение использует компоненты C/C++, тогда перед сбором данных подготовьте эти компоненты для анализа производительности. Конечно, рекомендации, касающиеся представлений о работе приложения, стартовых затрат и затрат .NET Framework, равно применимы к сбору данных о серверных компонентах,

Использование AppMetrics для наблюдения за компонентами .NET Enterprise Services СОМ+ предоставляет СОМ-компоненты (неуправляемый код) для создания масштабируемых и эффективных приложений. Через Enterprise Services эти компоненты также доступны управляемому коду .NET Framework. К их функциям относится координация транзакций для распределенных ресурсов, управление пулом объектов, защита на основе ролей и т. д. Вы можете настроить компоненты управляемого и неуправляемого кода на использование этих функций. AppMetrics for Transactions (AppMetrics) — это система мониторинга приложений Enterprise Services, она применяется при профилировании производительности приложений, активно использующих СОМ+. Многим приложениям, с которыми мы имеем дело, для взаимодействия с существующими системами, приходится «обертывать» свой управляемый код в компоненты СОМ + . Получаемые с помощью AppMetrics характеристики позволяют быстро определить, снижает ли приложение СОМ+ производительность. AppMetrics годится для мониторинга управляемых и неуправляемых компонентов Enterprise Services. Она разработана для наблюдения за приложениями, работающими как в опытных, так и серийных средах. AppMetrics Manager Для снижения влияния мониторинга на производительность системы и приложения в AppMetrics используется схема «агент диспетчер». Агент располагается на сервере приложения, где, занимая минимальное количество системных ресурсов, собирает данные о компонентах Enterprise Services. Такой подход позво-

212

Глава 7

ляет AppMetrics получать более точные данные о приложениях независимо от того, работают они на самом деле или их работа лишь имитируется. Агент посылает данные диспетчеру, который располагается на отдельной машине. Диспетчер в свою очередь на основе этих данных создает метрики приложений и их компонентов. Эти метрики включают общее число активизаций экземпляров компонентов, скорость, с которой экземпляр заканчивает работу, и фактическую продолжительность работы отдельных экземпляров. Они применяются для поиска «узких» мест, которые могут возникнуть во время работы приложения, Диспетчер сохраняет метрики в базе данных, обращаясь к которой вы можете создавать отчеты о работе приложений и экземпляров их компонентов. Настройка агента и диспетчера AppMetrics Для оценки компонентов с управляемым и неуправляемым кодом при работе nog Enterprise Services выполните следующие действия. 1. На компьютер с AppMetrics Manager установите монитор Manager.

Рис. 7-4. Панель настройки Diagnostics Application

Анализ производительности управляемого кода

213

2. Добавьте монитор Agent к монитору Manager, чтобы создать монитор Agent на сервере приложения. 3. Выберите приложение(я) для мониторинга на сервере. 4. Вы можете настроить мониторинг конкретных компонентов выбранных приложений.

Использование AppMetrics для предварительного мониторинга Для предварительного мониторинга в AppMetrics предусмотрен Diagnostics Monitor, который регистрирует данные отдельного компонента и транзакционную активность работающего приложения. Diagnostics Monitor отображает метрики в виде подробного отчета, в котором указана продолжительность каждого активного компонента приложения, а также показана логическая цепь обращений метода к компонентам. Это важно, поскольку простои просмотр метрик каждого компонента в отдельности от других компонентов не дает полной картины. Кроме того, это не позволяет судить о том, каким образом компоненты могут обращаться к другим компонентам. Обладая информацией о последовательностях обращений методов к компонентам, вы можете получить представление о взаимоотношениях компонентов во время выполнения, чтобы проанализировать полное время отклика компонента исходя из его составляющих частей. С помощью такого анализа удается определить, находиться ли «узкое» место в объекте корневого компонента или где-то на более низком уровне обращений метода з подчиненном компоненте. На рис. 7-5 показан фрагмент отчета AppMetrics for Transactions, иллюстрирующий: • логическую цепь активности метода; • компонент FMStock7.DAL.Broker, который запускает экземпляр подчиненного компонента FM5tocks7.CAM.7; • метод CreditAccountBalance, активированный на подчиненном компоненте;

Глава 7

214 •

систему именования для межпрограммных вызовов (crossapplication calls). Перед такими вызовами стоит имя другого приложения с двоеточием. В данном примере компонент FMStocks7.GAM.7 находится в другом приложении.

•14257В125 4443355375

Рис. 7-5. Детальный отчет

Примечание Кроме показанной здесь информации, в отчете для всех элементов приводятся время запуска, время завершения работы и коды ошибок. Обладая информацией о межпрограммных вызовах, удается оценить, достоин ли подчиненный компонент быть частью другого компонента. Однако помните, что межпрограммные вызовы сильно загружают процессор, а также увеличивают время работы метода. Если во время одной транзакции компонент делает ряд межпрограммных обращений к подчиненному компоненту, то, возможно, целесообразно сделать так, чтобы подчиненный компонент работал в том же приложении, где находится первое приложение. Сделать это можно несколькими способами. Например, переместить подчиненный компонент в приложение, содержащее первый компонент или же переместить подчиненный компонент в библиотечное приложение. Дополнительная диагностика Прежде чем запустить приложение в серийное производство, следует получить представление о его возможностях. На рис. 7-6 показан фрагмент отчета AppMetrics, в котором подробно описываются активность метода на экземплярах компонента FMStocks7.GAM.7 в течение 10 минут интенсивной работы. Заметьте, что средняя продолжительность проверяемого метода довольно большая и не все обращения заканчивались успешно.

Анализ производительности управляемого кода

215

Рис. 7-6. Отчет о методах Наблюдение за тем, как в течение времени меняется производительность компонента, довольно полезно. На рис. 7-7 показан фрагмент отчета AppMetrics for Transactions, отражающего активность компонента в течение 4-часового периода интенсивной работы.

Рис. 7-7. Отчет о компонентах

Мониторинг рабочего приложения Для мониторинга приложений Enterprise Services в рабочей ере* де AppMetrics предлагает Production Monitor, который через определенные промежутки времени создает метрики активности приложений Enterprise Services. Он менее требователен к ресурсам и менее информативен, чем Diagnostics Monitor. Production Monitor вычисляет итоги и степень активности компонентов и их экземпляров, как показано на рисунках 7-8, 7-9 и 7-10.

Рис. 7-8. Активные компоненты

216

Глава 7

..±j

Component Rice (Started. Completed, Abortid)

-Completsd - Aborted

Рис. 7-9. Частота применения компонентов

Рис. 7-10. Длительность работы компонентов Кроме этого, Production Monitor создает такие метрики, как запуск, останов и сбои приложения. Графический интерфейс AppMetrics отображает метрики для каждого процесса приложения Enterprise Services. На следующем рисунке показано использование ресурсов процессом, соответствующим FMStocks7.GAM. Production Monitor также предлагает мониторинг по предупреждению. Вы можете указать границы активности определенной метрики компонента, например средней продолжительности. Если AppMetrics обнаружит, что активность в зашей системе выше указанного уровня, то он отправит предупреждение по электрон-

Анализ производительности управляемого кода

217

ной почте или SNMP. Кроме того, AppMetrics среагирует на предупреждение запуском специального компонента СОМ, в котором вы можете запрограммировать автоматическую реакцию на данное состояние системы.

Рис. 7-11. Окно Application Process Runtime

jJjConstjIeRw* I АорМеЬгйs Curtis Hur^mtjon Lotff1 j Application Monit

--^ Logging Options Dot Net diagnostics testing m£

Рис. 7-12. Окно Components Process Runtime

218

Глава 7

AppMetrics выдает метрики для каждого отслеживаемого компонента Enterprise Services. На рис. 7-12 показано, что работа экземпляров компонента FM5tocks7.DALBroker в среднем занимает более 10 секунд от момента создания до завершения. Так как такие параметры выходят за указанные рамки, будет выдано предупреждение.

Заключение Знание о профилировании и интерпретации рабочих характеристик управляемого кода — ключ к построению расширяемого и устойчивого Web-приложения .NET. Профилирование управляемого кода можно осуществлять, используя System Monitor и счетчики производительности .NET. Полученная информация пригодится вам при работе с любыми средствами оптимизации кода. Подробнее о масштабируемом, высокопроизводительном коде рассказано в книге «Writing Scalable Code» Саймона Микэма (Simon Meacham) и Майка Паркса (Mike Parks), которая должна выйти в Microsoft Press в ближайшее время.

Глава 8

В любом приложении важнейшими операциями считаются получение, сохранение и отображение данных. .NET-приложения не исключение, и потому надлежащий анализ и настройка SQL-уровня абсолютно необходимы для реализации высокой масштабируемости. Покупка дополнительного или более мощного оборудования для приложений, имеющих «узкие» места на SQL-уровне, обычно не решает проблемы. Прежде чем покупать новое оборудование, необходимо выявить «узкие» места, влияющие на масштабируемость. Например, они могут проявляться в виде увеличения объема операций ввода-вывода или слишком высокой загрузке процессора из-за неверно выбранных индексов или плохо написанных запросов. Эта глава посвящена выявлению «узких» мест на SQL-уровне. Мы обсудим ряд связанных с индексами типичных проблем, выявленных нашей группой — группой анализа производительности компании Microsoft — в процессе работы. Естественно, речь пойдет не обо всех возможных проблемах производительности на SQLуровне — их не удастся вместить в рамки одной главы. Однако мы надеемся, что приведенная здесь информация об используемых нами методах выявления «узких» мест, позволит вам самостоятельно исправить их или корректно описать, если вы решите обратиться за помощью к специалистам. Для демонстрации мы используем примеры на основе сайта IBuySpy, где при необходимости специально создаем проблемы. Результаты примеров этой главы получены с использованием двухпроцессорного сервера на базе Pentium 111 1ГГц с 1 Гбайт оперативной памяти, на котором был установлены Microsoft SQL Server 2000 Enterprise Edition с Service Pack 2 и Windows 2000 Advanced Server с Service Pack 2.

220

Глава 8

Чтобы устранить проблемы производительности и масштабируемости, прежде необходимо изучить структуру базы данных приложения. Если вы используете SQL Server 2000, вам также необходимо хорошо знать Transact-SQL (T-SQL); внутреннее устройство SQL Server, например как оптимизатор запросов выбирает план исполнения; как хранятся индексы и данные и как SQL Server использует кэширование данных и планов исполнения. Мы предполагаем, что вы уже работали с SQL Server 2000 и в определенной степени знакомы с его встроенными инструментами, такими, как SQL Query Analyzer и SQL Profiler. Если же это не так, то рекомендуем обратиться к следующим источникам: •

SQL Server Books Online (устанавливается вместе с SQL Server 2000);

• Kalen Delaney «Inside Microsoft SQL Server 2000» (Microsoft Press, 2000); •

Ken Henderson «The Guru's Guide to Transact-SQL» (Addison Wesley Longman, 2000);

•

«Microsoft SQL Server 2000 Performance Tuning Technical Reference» (Microsoft Press, 2001).

Кроме того, вы должны уметь создавать на сервере базы данных эксплуатационные или предполагаемые уровни нагрузки. Часто нагрузки, создаваемой одним пользователем, недостаточно для того, чтобы проявились проблемы масштабируемости на SQLуровне. Здесь зам может понадобиться информация из главы 3, в которой мы рассказывали о Microsoft Application Center Test, как инструменте нагрузочного тестирования. Надлежащие сценарии нагрузочного тестирования, моделирующие в тестовой среде реальные эксплуатационные нагрузки, позволят вам выявить «узкие» места, прежде чем они возникнут во время эксплуатации приложения. Если вы определили, что для решения проблемы требуется изменение индекса или запроса, то сможете использовать тестовую среду для проверки своих предположений, прежде чем вносить изменения в работающее приложение.

Выявление «узких» мест Во многих случаях определить наличие «узких» мест на SQL-уровне очень просто. Например, если к одному серверу базы данных

Анализ SQL-уровня

221

обращается несколько Web-серверов, то уменьшение числа последних должно снизить пропускную способность приложения. Если же пропускная способность не снижается при уменьшении числа Web-серверов, то, вероятно, «узкое» место находится на SQL-уровне.

ПРИМЕНЕНИЕ Часто, «узкие» места на тестовых клиентских компьютерах возникают до того, как создана достаточная нагрузка на Web-серверы или SQL-серверы. Таким образом, во время каждого теста необходимо периодически проверять степень загрузки ресурсов клиентских компьютеров. Чтобы выявить проблему на SQL-уровне, достаточно уменьшить число Web-серверов, как описано выше, или понаблюдать за загрузкой процессора на каждом из уровней приложения. А вот определить причину проблемы и предложить ее решение весьма сложно: прочитав эту главу, вы не приобретете необходимые навыки мгновенно. Мы познакомим вас с тем, как мы выявляем «узкие» места на SQL-уровне, однако учиться вам придется на собственном опыте. Начнем мы с обсуждения инструментов, поставляемых вместе с SQL Server 2000.

Наш инструментарий Для решения большинства проблем, связанных с SQL, мы используем только средства, входящие в поставку SQL Server 2000. Неэффективные запросы удается выявить с помощью SQL Profiler, блокировки — средствами SQL Profiler и SQL Query Analyzer; другие же причины «узких» мест, такие, как проблемы диска или памяти, выявялются с помощью System Monitor. Рассмотрим каждый их этих инструментов. SQL Profiler При установке по умолчанию SQL Profiler доступен из меню Пуск, раздел Programs\Microsoft SQL Server\Profiler.

ПРИМЕЧАНИЕ Для запуска трассировки пользователь должен иметь административные права на соответствующем SQL-сервере.

222

Глава 8

Запустив SQL Profiler, выберите нужный сервер и введите информацию для входа в систему. После установления сессии откроется диалоговое окно свойств трассировки. В нем имеется 4 вкладки — General, Events, Data Columns u Filters, используемые для настройки параметров трассировки, На вкладке General задают название трассировки, шаблон трассировки, а также режим сохранения данных в файле трассировки или в SQL-таблице. В случае сохранения результатов в файле необходимо указать каталог и имя файла, при сохранении данных в таблице слдеует задать сервер, базу данных и таблицу. На вкладке Events выбирают события, мониторинг которых необходим. События объединены в наборы, внутри которых перечислены отдельные события. При выборе события его описание отображается внизу вкладки. Мониторинг всех событий сразу, может, и не требуется, кроме того, это перегружает сервер. Обычно мы задаем мониторинг следующих событий: •

Stored Procedures: SP:StmtCompleted, SP:Completed, RPC:Completed и TSQL: SQUStmtCompleted, SQL:BatchCompleted Эти события генерируются по завершении обработки оператора, хранимой процедуры, RPC или пакета (batch i. Указав вывод в трассировочную информацию столбцов текста, операций чтения, нагрузки процессора и длительности, вы выявите долго исполняющийся код в терминах ресурсов процессора. Информация о требуемых операциях чтения вам пригодится: именно с ней вы будете сравнивать результаты оптимизации;

• Stored Procedures: SP:Starting, SP:StmtStarting u TSQL: SQUStmtStarting Используя эти события вместе с событиями завершения, вам удастся профилировать хранимую процедуру с точностью до строки кода. Это полезно для долго работающих процедур, так как позволяет определить проблемный оператор до окончания процедуры. Кроме того, если в процессе исполнения хранимых процедур происходят ошибки, то зам удастся установить оператор, их вызывающий; • Sessions: Existing Connection Данное событие позволяет проверить фактические значения параметров SQL Server для сессии базы данных. Параметры сессии могут влиять на об-

Анализ SQL-уровня

223

работку запросов. Например, для использования индексированных представлений (view) необходимо установить в ON параметр ARITHABORT, иначе для выборки данных будет использоваться нижележащая таблица, а не кластерный индекс для представления; • Stored Procedures: SP:Recompile Исполнение хранимой процедуры подразумевает разбор, компиляцию и выполнение. Каждый из этих этапов требует определенного времени. В идеале разбор и компиляцию кода следует выполнять однократно, чтобы затем ресурсы сервера расходовались только на выполнение. Неправильно написанная хранимая процедура может требовать перекомпиляции при каждом вызове, что отрицательно влияет на время ее исполнения и даже вызывает блокировки. С помощью данного события удается определить масштаб перекомпиляции и выявить код, требующий оптимизации, включив в ту же трассировку событие SP: Starting; • Lock: Timeout and Lock: Deadlock Мониторинг данного события необходим, так как оно напрямую влияет на масштабируемость приложения. Тайм-аут блокировки или дедлок вызывают незавершенные транзакции и ошибки на клиентской стороне; • Errors and Warnings: Attention Данное событие генерируется всякий раз, когда сессия завершается по инициативе клиента или по тайм-ауту. Для приложений, которым обычно требуется длительное время на обработку, вам, вероятно, придется увеличить длительность тайм-аута или уменьшить число таймаутов. Например, в ADO.NET установить свойство CommandTimeOut в значение более 30 секунд (по умолчанию) для запросов, работающих долгое время; •

Errors and Warnings: Missing Column Statistics SQL Sewer может автоматически создавать и поддерживать статистику для таблиц и индексов. Эта информация представляет собой распределение значений в некоторых колонках таблиц и индексов и используется при обработке запросов для выбора плана выполнения. Если статистика отсутствует или устарела, то может быть выбран неэффективный план исполнения, что отрицательно скажется на общей производительности приложения;

224

Глава 8

• Errors and Warnings: Missing Join Predicate Данное событие генерируется всякий раз, когда в запросе встречается декартово произведение (соединение без указания условия). Декартово произведение используются крайне редко и может оказаться результатом ошибки разработчика. Мониторинг этого события позволит определить, не используется ли данный тип соединения таблиц; •

Errors and Warnings: Exception u Error Log Эти события полезны для выявления любых необычных ошибок, возникающих в результата нагрузочного тестирования приложения. Мониторинг этих событий позволяет определить, являются ли они результатами повышенной нагрузки. Например, если установить для всех сессий флаги трассировки 1204 и 3605, то SQL Profiler зафиксирует информацию, связанную с дедлоками. Дедлоки представляют собой серьезную проблему, формирующую у пользователя плохое впечатление о приложении и значительно влияющие на пропускную способность приложения.

Подробнее о «event classes» — в SQL Server Books Online. На закладке Data Columns можно указать столбцы, значения которых должны фиксироваться во время трассировки. Из 43 столбцов обязательными являются Event Class u SPID. В зависимости от интенсивности взаимодействия приложения с SQL-сервером и количества пользователей вы можете получить огромный массив трассировочных данных. Помните, что не все столбцы содержат значения, так как в зависимости от конкретного события некоторые столбцы не имеют смысла. Например, длительность имеет смысл только для событий завершения, таких, кгк5Р:Сотрieted', а для SP:5tarting этот столбец останется пустым. Некоторые используемые нами столбцы, перечислены в табл. 8-1: Табл. 8-1. Часто используемые столбцы трассировки Столбец Event Text CPU

Описание Название события. Например, начало работы хранимой процедуры, установление сессии и т. д. Текст выполняемой SQL-команды. Столбец может быть пуст, если команда неприменима к данному событию Использованное время процессора в миллисекундах

см. след. стр.

Анализ SQL-уровня

225

Табл. 8-1. (продолжение) Столбец

Описание

Reads

Число логических операций чтения для исполнения запроса Writes Число физических операций записи, выполняемых SQL-командой Duration Длительность события, например время исполнения хранимой процедуры StartTime Время начала события EndTime Время завершения события. Применимо к событиям, связанным с завершением операций NestLevel Глубина вложенности операции. Например, если одна хранимая процедура вызывает другую, то глубина вложенности вызывающей процедуры равна 1, а вызываемой -— 2. Соответствует значению глобальной переменной @@NestVa!ue Application Name Название приложения, установившего сессию с сервером HostName Название компьютера, на котором исполняется приложение, выдавшее команду SQL NTUserName Учетная запись пользователя Windows, в контексте которой исполняется клиентское приложение LoginName Либо имя пользователя Windows, либо регистрационное имя SQL Server — в зависимости от применяемого метода аутентификации Подробнее о «data columns» — в SQL Server Books Online. На вкладке Filters задаются фильтры для ограничения объема результатов трассировки. Например, если вас интересует определенное приложение, то можно задать фильтрование по его имени. События, генерируемые SQL Profiler, исключаются по умолчанию. Чтобы познакомиться со всеми доступными фильтрами, изучите вкладку Filters в диалоговом окне Trace Properties. При выборе фильтра внизу вкладки появляется его описание, Теперь, когда вы познакомились с тем, какие виды информации можно собрать, поговорим о том, как анализировать результаты трассировки. SQL Profiler позволяет сохранять результаты трассировки либо в файле, либо в SQL-таблице. На самом деле если вы решите сохранить данные в файле, то за вами сохраняется

226

Глава 8

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

СОВЕТ Вы также можете выполнять запросы непосредственно по содержимому файла трассировки с помощью системной функции fn_trace_gettabfe. Например, следующий запрос возвращает все события длительностью более 1000 миллисекунд из файла trace.trc в табличном формате: SELECT * FROM ::fn_trace_gettable('c:\trace.trc', default) WHERE Duration > 1000 Подробнее о «fn_trace_gettable» --в SQL Server Books Online. По нашему опыту, для анализа больших объемов трассировочных данных следует сохранять их в таблице и затем использовать запросы к последней для выборки такой информации, как первые N хранимых процедур, имеющих наибольшую длительность исполнений, или средняя длительность исполнения всех вызовов данной хранимой процедуры. Чтобы иметь возможность решать, медленно или нормально исполняется код, необходимо определить критерии понятия «медленно исполняющий запрос».

СОВЕТ Мы рассматриваем любой код, который в условиях минимальной нагрузки на приложение исполняется в течение секунды или дольше как предмет для дальнейших исследований и возможных улучшений. Выбор данного критерия основан на том, что при нагрузке длительность исполнения такого кода возрастет, в результате чего уменьшается пропускная способность приложения. Выполнив трассировку несколько раз, вы заметите, что всегда выбираете определенные события и фильтры. В SQL Profiler предусмотрено средство, облегчающее задание часто используемых параметров трассировки — шаблоны, содержащие значения таких параметров. Это позволит вам не задавать параметры для каждой новой трассировки вручную. Создать шаблон очень просто: выберите из меню File пункт Choose New Trace Template, no

Анализ SQL-уровня

227

которому отображается диалоговое окно Trace Properties, где вы можете выбрать события, столбцы и фильтры. Затем на вкладке General щелкните Save As. Пункт Open Trace Template меню File позволяет открыть сохраненный ранее шаблон. Затем его можно изменить и сохранить под другим именем, System Monitor SQL Server поддерживает ряд объектов производительности для System Monitor. Последний подробно рассматривался в главе 4, где говорится о счетчиках, связанных с общесистемными ресурсами, такими, как процессор, память, диск и сеть. В этой главе речь пойдет только о наиболее часто используемых нами счетчиках, характерных для SQL Server. Другие счетчики подробно описаны в источниках, перечисленных в начале главы. В зависимости от обстоятельств вам могут потребоваться и эти счетчики. Мы наиболее часто используем следующие счетчики производительности SQL Server: •

SQLServer:Buffer Manager о

Buffer cache hit ratio Процент страниц, которые были найдены в буферном пуле и которые не пришлось считывать с диска (выполнять физический ввод-вывод). Малые значения могут свидетельствовать о недостатке памяти или плохих индексах;

SQLServenGeneral Statistics Object о User Connections Число активных SQL-сессий. Этот информационный счетчик в отчете показывает уровень параллелизма в системе;

» SQLServer:Locks о Lock Requests/sec Количество запросов на блокировку в секунду. Оптимизация запросов для снижения числа операций чтения в некоторых случаях уменьшает значение данного счетчика; о Lock Timeouts/sec Число запросов на блокировку, завершившихся тайм-аутом в процессе ожидания предоставления блокировки. В идеале значение счетчика должно быть равно 0;

228

Глава 8 о Lock Waits/sec Число запросов на блокировку, которые не были удовлетворены немедленно, В идеале значение счетчика должно быть максимально близким к 0; о Number of Deadlocks/sec Число запросов, вызвавших дедлок. Дедлоки снижают степень масштабируемости приложения и создают дискомфорт для пользователя. Значение счетчика должно быть равно 0. Выполнив мониторинг экземпляров этих счетчиков, вы определите используемые типы блокировок и их вклад в общее значение счетчиков. Задав правильные индексы и, возможно, указания по блокировке (lock hint), вы уменьшите объем проблем, связанных с блокировками.

• SQLServer:Memory Manager о Memory Grants Pending Число процессов, ожидающих предоставления памяти рабочего пространства (workspace). Значение счетчика должно быть максимально близким к О, если это не так, вероятно, возникло «узкое» место, связанное с объемом памяти; • SQLServenSQL Statistics о Batch Requests/sec Число пакетных запросов к серверу rs секунду, показывает нагрузку на систему; о SQL Compilations/sec Число компиляций в секунду. В идеале значение счетчика должно быть мало. Близость значений этого счетчика и счетчика Batch requests/sec означает большое число произвольных fad-hoc) SQL-запросов; о SQL Re-Compilations/sec Число перекомпиляций в секунду. Значение этого счетчика также должно быть мало. В идеале хранимые процедуры должны компилироваться однократно с последующим многократным использованием полученных планов исполнения. Большое значение этого счетчика свидетельствует о необходимости изменения кода хранимых процедур с целью минимизации перекомпиляции. SQL Query Analyzer SQL Query Analyzer применяют в различных целях, например для исполнения SQL-сценариев при установке нового кода, для подсчета числа вставляемых или обновляемых строк, для анализа

Анализ SQL-уровня

229

планов исполнения запросов или для исполнения различных системных хранимых процедур. Среди всех программ, поставляемых з составе SQL Server 2000, Query Analyzer несомненно является инструментом наиболее часто используемым нашей группой. Вместо подробного описания Query Analyzer мы продемонстрируем конкретные приемы его применения для анализа блокировок и планов исполнения далее в этой главе.

Быстрый подсчет строк !

. Пру исследовании сценариев, выполняющих вставку строк - . в таблицы, подсчет числа строк до и после нагрузочного текаа полезен для определений пропускной способности, Однако для большой таблицы эта операция мо-жёт'потребовать много времени. Проще всего выяснить общее число =• строк в любой таблице посредством следующего запроса к у: системной таблице sysindexes:

SELECT о.паше, rows FROM sysoiajects о INNEfl JOIN sysintJexes i on o.ld * i.id1 = WHERE i.indid < 2 f ORDEfl BY o.rtatns {!

Обращение к sysindexes требует меньше "операций ввода* вывода по сравнению со сканированием большой таблицы, -•*'• ; содержащей тысячи или миллионы строк. Следовательно, , чем больше число строк, тем более выгоден запрос -к sysint/exes. Обратите внимание, что обычно прямое обращение ' ' к системным таблицам не рекомендуется. Таблицу sysindexes*\ следует использовать только тогда, когда необходимо сокра'' тить длительность подсчета строк в таблице.

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

230

Глава 8

не удастся установить на эту таблицу монопольную блокировку, пока сессия А не снимет свою блокировку. В зависимости от типа приложения блокирование возможно даже после тщательной оптимизации последнего; однако,, если частота возникновения блокирования удлиняет период ожидания, то производительность снижается. Устранение проблемы блокирования может дать огромные выгоды, и каждому, кто занимается настройкой производительности SQL Server, необходимо знать, как это делается. Повторимся, что обсуждение всех возможных способов выходит за рамки данной книги. Однако мы расскажем о некоторых способах выявления проблем блокирования. Определение блокирующих сессий Обычный признак «узкого» мест, связанного с блокированием, — низкое потребление системных ресурсов (процессора и диска) при максимальной пропускной способности SQL-уровня. Если вы подозреваете, что проблема кроется в блокировании, то прежде всего требуется выполнить запрос к таблице sysprocesses в базе данных master. В листинге 8-1 показан SQL-сценарий, возвращающий информацию о блокированных сессиях и последний оператор, исполненный корневым блокировщиком (root blocker). Листинг 8-1 - Возвращает информацию о блокировании из таблицы sysprocesses. SELECT spid, blocked, status, waittime, waittype, wait resource, db_name(dbid) DatabaseName, cmd, hostname, loginame FROM master..sysprocesses WHERE blocked != 0 DECLARE @spid int - Получить spid корневого блокировщика. SELECT @spid = A.spid FROM master..sysprocesses A INNER JOIN master..sysprocesses В ON A.spid = B.blocked WHERE A.blocked = 0 IF NOT @spid IS NULL BEGIN -- Возвратить последний оператор сессии.

Анализ SQL-уровня

231

DBCC INPUTBUFFER(@spid)

END

Сайт-пример IBuySpy, используемый в данной книге, не имеет проблем блокирования на SQL-уровне. Однако для моделирования блокировки при компиляции мы добавим новую хранимую процедуру, компилируемую заново при каждом вызове. Ниже приведен сценарий создания такой процедуры: CREATE PROCEDURE ProductCategoryList_Recompile WITH RECOMPILE AS SELECT CategorylD, CategoryName FROM dbo.Categories ORDER BY CategoryName ASC

GO Для получения блокировки при компиляции следует выполнить несколько вызовов этой процедуры одновременно. Как говорилось в главе 3, для моделирования нагрузки на SQL-сервер мы можем использовать ACT. Соответствующий сценарий ACT показан в листинге 8-2. Листинг 8-2 -- Сценарий ACT для моделирования одновременных вызовов хранимой процедуры. Dim oConn On Error Resume Next Set oConri = CreateObject{"ADODB.Connection") oConn.Open "driver={SQL Server};Server=SQLServer;" & _ "Database=Store;uid=user;pwd=user" If err.Number <> 0 Then Test.TraceC'Error Opening connection: " & _ err.number & ", " & err.description) ELSE oConn.ExecuteC'EXEC ProductCategoryList_Recompile")

232

Глава 8 If err.Number <> 0 Then

Test.TraceC'Error Executing: " & err.number & ", " & err.description) End If End IF

Установите число одновременных браузерных сессий в 10 и выполните тест в течение пяти минут. Во время выполнения нагрузочного теста запуск сценария листинга 8-1 вы получите информацию о блокированных сессиях и последнем операторе, выполненном корневым блокировщиком. В данном примере столбец waitresource блокированной сессии должен показывать блокировку компиляции: TAB: 7:1173579219 [[COMPILE]]

ПРИМЕЧАНИЕ Значение "7" после "TAB:" указывает базу данных Store, a "1173579219" указывает компилируемый объект. В нашем случае "1173579219" соответствует ProductCategoryLi$t_Recotnpile. Для получения этой информации достаточно выполнить запрос SELECT Object_Name(l 173579219) в базе данных Store. Имейте в виду, что формат поля waitresource может измениться в следующей версии или в следующем пакете обновлений, в результате чего данный метод определения базы данных и имени хранимой процедуры станет неприменимым. Последний оператор, выполненный корневым блокировщиком, должен отображаться KaKProductCategoryUst_Recompife. Запрос к таблице sysprocesses показал, что проблема связана именно с нашей процедурой, специально добавленной для создания блокировки. Излишне частая компиляция — лишь одна из множества причин блокирования. К другим причинам относится долго исполняющиеся транзакции, неверно выбранный уровень изоляции транзакций и плохо выбранные индексы. Рассмотренный в этом разделе метод можно использовать для выявления блокирующих хранимых процедур или произвольных запросов независимо от причины блокирования. После выявления блокирующего запроса следует проанализировать его, чтобы точно определить проблему.

Анализ SQL-уровня

233

Блокировки Глубокое знание типов блокировок, используемых SQL Server, совершенно необходимо для поиска и устранения проблем блокировавния. Мы настоятельно рекомендуем изучить разделы, связанные с блокировками, воспльзозавшись указанной в этой главе литературой. Только обладая необходимыми знаниями, вы сможете разрешать проблемы, связанные с тайм-аутами блокировок и дедлоками (взаимоблокировками). Если в приложении возникает SQL-блокирование, то обычно мы используем spjock для определения полученных и ожидаемых блокировок. Системная процедура spjock возвращает текущее состояние блокировок на момент ее исполнения, поэтому во время нагрузочного тестирования мы запускаем ее многократно, чтобы определить типовые конфигурации блокировок. Результаты работы spjock трудно читаемы и требуют дополнительной обработки для получения названий таблиц и .индексов. Поэтому для улучшения читабельности результатов мы используем собственную хранимую процедуру, аналогичную spjock_verbose, описанной в The Guru's Guide to Transact-SQL. А теперь мы снова создадим проблему блокировок в одной из хранимых процедур. Ниже приведен сценарий создания такой процедуры: CREATE PROCEDURE ProductCategoryList_XLOCK AS -- Транзакция используется для удержания монопольной блокировки, BEGIN TRANSACTION SELECT

CategorylD, CategoryName

FROM dbo.Categories (XLOCK) ORDER BY CategoryName ASC WAITFOR DELAY '00:00:01' -- Удерживать блокировку 1 секунду. COMMIT TRANSACTION GO

234

Глава 8

Исполнение spjock во время выполнения нагрузочного текста с помощью приведенной выше хранимой процедуры, даст примерно такие результаты: spid

dbid

Objld

Indld

Type Resource

Mode

Status

51 53 53

7 1

0 0

. J

i i '/ 7

1977058079 0 1977058079 0 1977058079 (i 1977058079 0 1977058079 1977058079 0

DB DB RID

S S • [X

GRANT GRANT WAIT GRANT GRANT GRANT GRANT GRANT

53 53 54 54 '..'I

;• J

1 89:0

PAG ГА1 i AB RII RID

I 89:2 !

:89:6

IX X •

(Результаты приведены частично) Нам интересны столбцы Objld, Type, Mode и Status. Например, в приведенных выше результатах показана монопольная блокировка типа RID (row identifier) для объекта «1977058079». Тип блокировки R[D используется вместо типа блокировки KEY в связи с отсутствием кластерного индекса на таблице Categories. Кроме того, как показывает значение WAIT в столбце Status, в данный момент ожидается предоставление монопольной блокировки. Для получения имени объекта можно выполнить запрос SELECT Object_Name(<Ob]Id>), и в данном случае «1977058079» соответствует таблице Categories. Использование результатов запроса к таблице sysprocesses для определения блокирующей сессии в сочетании с результатами вызова хранимой процедуры spjock для получения информации о блокировках упроьцает локализацию' проблемы с точностью до конкретного оператора. Дедлоки Ледлок возникает, когда две или несколько сессий блокируют друг друга, причем каждая из них ожидает некоторых ресурсов, заблокированных другой сессией. Например, сессия заблокировала строку А и ожидает получения блокировки строки В. Сессия В заблокировала строку В и ожидает получения блокировки строки А. Каждая из сессий ожидает другую и не может продолжить выполнение, чтобы завершить или отменить транзакцию. Этот тип дедлока называется циклическим. Другой возможный тип — дедлок преобразования. Он возникает, когда две или несколько

Анализ SQL-уровня

235

сессий удерживают разделяемые блокировки некоторых ресурсов и хотят преобразовать свои разделяемые блокировки в монопольные. Независимо от типа дедлока для поиска и устранения связанных с ним проблем мы используем флаги трассировки. Следующий оператор приводит к выводу трассировки дедлока (1204) в журнал ошибок SQL Server (3605) и устанавливает этот флаг трассировки для всех сессий (-1): DBCC TRACEOMC-1, 1204, 3605) После установки этих флагов трассировки вы можете перехватить событие ErrorLog с помощью SQL Profiler или просмотреть журнал ошибок средствами Enterprise Manager. В демонстрационных целях мы создали следующий сценарий, добавляющий хранимую процедуру, которая вызывает дедлок преобразования: CREATE CLUSTERED INDEX IXC.ModelName

ON dbo.Products (ModelName) GO

CREATE PROCEDURE ProductsUnitCostUpdate.DeadLock AS

BEGIN TRANSACTION SELECT * FROM dbo.Products (HOLDLOCK) WHERE ModelName = N'Bullet Proof Facial Tissue' WAITFOR DELAY '00:00:05' UPDATE dbo.Products SET UnitCost = UnitCost * 0.90 WHERE ModelName = N'Bullet Proof Facial Tissue' COMMIT TRANSACTION GO Для получения дедлока эту хранимую процедуру нужно запустить из двух разных окон SQL Query Analyzer с интервалом в несколько секунд. Ниже приведены данные трассировки, полученные путем установки флага 1204: Deadlock encountered .... Printing deadlock information Wait-for graph

236

Глава 8

Node:1 KEY: 7:2041058307:1 (a60421ba9ed3) CleanCnt:2 Mode: _ Range-S-S Flags: 0x0 Grant List:: Qwner:0x42be1340 Mode: Range-S-S Flg:OxO flef:0 Life:02000000 SPID:52 ECID:0 SPID: 52 ECID: 0 Statement Type: UPDATE Line #: 12 Input But: Language Event: ProductsPriceUpdate_DeadLock Requested By: ResTypeiLockOwner Stype:'OR' Mode: X SPID:51 ECID:0 Ec:(0x42f77568) Value:Ox42be1360 Cost:(0/0) Node:2 KEY: 7:2041058307:1 (a60421ba9ed3) CleanCnt:2 Mode: Range-S-S _ Flags: 0x0 Grant List:; Owner:Ox42be5240 Mode: Range-S-S Fig:0x0 Ref:0 Life:02000000 SPID:51 ECID:0 SPID: 51 ECID: 0 Statement Type: UPDATE Line *: 12 Input Buf: Language Event: ProductsPriceUpdate_DeadLock Requested By: ResTypeiLockOwner S t y p e : ' O R ' Mode: X SPID:52 ECID:0 _ Ec:(0x430b5568) Value:Ox42be1260 Cost:(0/0) Victim Resource Owner: ResType:LockOwner S t y p e : ' O R ' Mode: X SPID:52 ECID:0 _ EC:(0x43065568) Value:Ox42be1260 Cost:(0/0)

Флаг 1204 генерирует подробную информацию о каждом возникновении дедлока, мы же обычно исследуем только часть этих данных. Нас интересуют блокируемый ресурс «Key:», тип блокировки «Mode:» и имя хранимой процедуры либо произвольный запрос «Input Buf:». Имея эту информацию, удается ограничить область дальнейших поисков несколькими хранимыми процедурами или запросами. Более подробную информацию о борьбе с дедлоками и флаге трассировки 1204 см. в SQL Server Books Online u Inside Microsoft SQL Server 2000. Дополнительные ресурсы Ранее мы уже рассказывали о том, как бороться с проблемами блокировок вручную. Используя специальные сценарии, вы уменьшите влияние фактора человеческих ошибок. Эти сценарии поиска блокировок опубликованы в следующих статьях.

Анализ SQL-уровня

237

• «INF: How to Monitor SQL Server 2000 Blocking (Q271509)» no адресу http://support.microsoft.com/defaultaspx?scid = kb;enus;q271509; • «INF: SQL Blocking Due to [[COMPILE]] Locks (Q263889)» no адресу http://support,microsoft.com/default.aspx?scid = kb;enus;Q263889; • «INF; Troubleshooting Application Performance with SQL Server [Q224587)» no адресу http://support.microsoft.com/default.aspx?scid = kb;en-us;Q224587.

Настройка индексов Методы, обсуждавшиеся в предыдущем разделе, позволяют ограничить область поиска проблем конкретными запросами или хранимыми процедурами. Выявив SQL-команду, вызывающую проблему, вы сделаете большой шаг вперед на пути к ее решению. К сожалению, практически невозможно перечислить все проблемы, которые могут возникнуть при работе с SQL Server 2000. Каждый день наша группа обнаруживает новые сложные проблемы, и чем больше мы работаем с SQL Server, тем больше убеждаемся в том, что теоретических знаний, почерпнутых из книг и статей, недостаточно для того, чтобы стать экспертом по настройке производительности SQL Server, Поэтому, если вам не удалось решить конкретную проблему производительности сразу же по прочтении этой главы, не расстраивайтесь; просто поймите, что за один вечер нельзя научиться настройке приложений для SQL Server. Другая проблема, хорошо знакомая нам, — отсутствие необходимых индексов. Обычно мы используем сходные методы настройки индексов для каждой проблемной SQL-команды. Методы, которые мы применяем для настройки индексов, обсуждаются в следующем разделе.

Анализ планов выполнения Одним из способов выявления причин долгого исполнения запроса является анализ плана выполнения запроса и проверка метода выборки данных, использованного оптимизатором запросов SQL Server 2000. Для получения графического представления плана выполнения вы можете применять Query Analyzer.

238

Глава 8

Генерация данных Прежде чем начать, мы добавим 100000 строк в таблицу Orders и 1000000 строк в таблицу OrderDetails базы данных сайта-примера IBuySpy. Фактическое число строк для анализа SQL-уровня зависит от бизнес-требований и предполагаемых темпов роста базы данных. Мы выбрали число строк произвольно, только чтобы продемонстрировать, как выполнять анализ на больших наборах данных. В зависимости от числа строк и уникальности данных по столбцам SQL Server ведет себя no-разному; поэтому необходимо использовать для настройки базу данных соответствующих размеров. В листинге 8-3 показан сценарий генерации тестовых строк. Листинг 8-3 — Сценарий генерации тестовых данных, SET NOCOUNT ON - Отключить вывод сообщений о числе строк, DECLARE @Count int DECLARE eOrderlD int DECLARE £CustomerID int DECLARE @DateAdd int DECLARE @DateAdd2 int DECLARE ©Today DateTime DECLARE @SQL nvarchar(4QOO) -- Определить число строк перед вставками. SELECT Count(*) Orders FROM Orders SELECT Count(*) OrderDetails FROM OrderDetails SELECT Count(*> Customers FROM Customers SET @Today = GetDateO SET @Count = 1 -- Добавить 100000 строк в Orders и 10000 строк в Customers. WHILE @Count <= 100000 BEGIN - Каждые 10 строк вставлять нового клиента. IF ©Count К 10 = О OR @Count = 1 BEGIN INSERT INTO Customers

Анализ SQL-уровня

239

FullName, EMailAddress, Password ) VALUES

'TestUser_' + Cast(@Count as varchar(10)}, 'TestUser_' + Cast(@Count as varchar(10)) + '©test,com' 'password' SET faCustomerlD = ©^Identity END

-- Задать изменяющиеся значения для OrderDate и ShipDate. SET @DateAdd = (-1 * (©Count Л 365)) SET @DateAdd2 = (-1 - (©Count X 365)) + 1 INSERT INTO Orders

CustomerlD, OrderDate, ShipDate

VALUES ( ©CustomerlD, DateAdd(d, @DateAdd, ©Today), DateAddfd, @DateAdd2, ©Today) i SET @OrderID = ©©Identity SET @SQL = N'INSERT INTO OrderDetails С OrderlD, ProductlO, Quantity, UnitCost SELECT TOP 10

©OrderlD, ProductID, 1, UnitCost FROM Products '

- 4 разных сортировки для добавления разных товаров. IF ©Count I 4 = 1

240

Глава 8 SET @SQL = @SQL + N'ORDER BY CategorylO

IF ©Count % 4 = 2 SET @SQL = §SQL + N'ORDER BY ModelNumber' IF £Count JS 4 = 3 SET 9SQL = §SQL + N'ORDER BY ModelName 1 IF @Count X 4 = 0 SET @SQL = @SQL + N'ORDER BY UnitCosf EXEC sp_executesql @SQL, @OrderID = @OrderID

N ' e O r d e r l D int',

SET @Count = ©Count + 1

END - Число строк после вставок. SELECT CountC*) Orders FROM Orders SELECT Count(*) OrderDetails FROM OrderDetails SELECT Count(*} Customers FROM Customers

Просмотр плана выполнения После загрузки тестовых данных выполним процедуру ProductsMostPopular — одну из хранимых процедур, на работу которых значительно влияет увеличение размера базы данных. Для получения плана выполнения в Query Analyzer следует включить опцию Show Execution Plan (нажмите CTRL+K). План выполнения процедуры ProductsMostPopular показан на рис. 8-1. В этом относительно простом примере ProductsMostPopular выглядит так: CREATE Procedure ProductsMostPopular AS SELECT TOP 5

OrderDetails.ProductID, SUMfQrderDetails.Quantity) as TotalNum, Products.ModelName FROM OrderDetails INNER JOIN Products ON OrderDetails.ProductID =

Анализ SQL-уровня

241

Products.ProductID GROUP BY OrderDetails.Product ID, Products.ModelName ORDER BY TotalNurn DESC

Рис. 8-1. План выполнения хранимой процедуры ProductsM ostPopular Различных значков для представления физических операций, используемых при выполнении SQL-операторов, слишком много, чтобы перечислять их здесь все. Они подробно описаны в SQL Server Books Online, где, кроме того, подробно рассказано о том, как интерпретировать графическое представление плана. В этом разделе мы рассмотрим лишь те причины, которые значительно увеличивают время исполнения запроса. Из различных физических операторов следует уделить внимание относительно дорогим. Например, на рис. 8-1 больше остальных стоят операторы Hash Match/Aggregate и Table Scan: 54 и 46%

242

ГЛЭЕШ 8

соответственно. При наведении указателя мыши на каждый значок в плане выполнения на экране отображается всплывающая подсказка, содержащая подробную информацию. На рис. 8-2 показана такая подсказка для значка Table Scan.

Г able Stan Scanrcwsl'craliibte. PtiYiicd operation: Logkil opcnUon Row count: Mimalcd row it»:

I/O out:

CPU tosb humba of f iff tut ft1. Cost: Subtree oat: Estimated raw coin):

Table Scan Table Scan 1,013,819 27 1.12

0.557 L

3.96 1,013,819

Argument: OBJECT Distort], [do]. [OrdHDeti >D

j f ttatan «an

Рис. 8-2.

Всплывающая подсказка для значка Table Scan

В подсказке говорится, что оптимизатор запросов для считывания данных из объекта [store].[dboUOrderDetails] выбрал оператор Table Scan. В типичных случаях использование Table Scan и Index Scan увеличивает время исполнения по сравнению с Index Seek. Однако в нашем случае для определения пяти наиболее популярных товаров необходимо считывать всю таблицу OrderDetails. Использование Table Scan и Index Scan для небольших таблиц правомочно и в некоторых случаях более эффективно. Наличие таких операторов в плане выполнения не является основанием для немедленной реакции — создание дополнительных индексов для маленьких таблиц иногда не дает никакого результата с точки зрения времени исполнения запроса. Таким образом, помимо списка физических операторов для эффективной настройки индексов вам потребуется дополнительная информация.

Анализ SQL-уровня

243

ПРИМЕЧАНИЕ Сканирование применяется для таблиц без кластерных индексов. Следствием отсутствия кластерного индекса может быть плохая производительность. Подробнее о данной проблеме — в «PRB: Poor Performance on a Heap (Q297861)» на странице http://support. microsoft. com/default.aspx?scid = kb;enus;Q297861. Дополнительная информация для настройки SQL Server предоставляет полезные возможности сбора статистики, позволяющие определять объемы потребляемых ресурсов, например STATISTICS Ю. Комбинированный анализ плана выполнения запроса и статистики предназначен для определения таблиц, вызывающих проблемы производительности. Так как конечной целью является сокращение времени исполнения запросов, это время необходимо измерить. Для этого следует включить опцию STATISTICS TIME. Теперь на экране отображается время разбора и компиляции запроса, что позволяет определить длительность генерации плана выполнения. СОВЕТ Длительность исполнения запросов определяют с помощью SQL Profiler; однако, опция STATISTICS TIME позволяет просматривать длительность выполнения в том же окне, в котором исполняется запрос. Кроме того, предусмотрены две команды DBCC, очищающие буфер данных и кэш процедур: DBCC DROPCLEANBUFFERS дает возможность тестировать запросы при незаполненном буфере данных без необходимости перезапуска SQL Server, что позволяет получать сравнимые значения статистических параметров запроса, a DBCC FREEPROCCACHE предназначена для тестирования производительности запросов при заполненном и незаполненном кэше процедур. ПРЕДУПРЕЖДЕНИЕ При реальной эксплуатации приложения команд DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE следует избегать.

244

Глава 8

Рассмотрим показатели производительности, полученные при выполнении хранимой процедуры ProductsMosfPopular в Query Analyzer с помощью следующего сценария: DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE SET STATISTICS 10 ON SET STATISTICS TIME ON GO

EXEC ProductsMostPopular Объем информации, генерируемый командами DBCC и опциями STATISTICS, разнится в зависимости от сложности хранимой процедуры. Для ProductsMostPopular интересующая нас часть результатов приведена ниже: SQL Server parse and compile time: CPU time = 32 ms, elapsed time = 187 ms. (5 row(s) affected) Table 'Products'. Scan count 5, logical reads 10, physical reads 4, read-ahead reads 0. Table 'OrderDetails'. Scan count 1, logical reads 3800, physical reads 0, read-ahead reads 3801. SQL Server Execution Times: CPU time = 1813 ms, elapsed time = 1826 ms, (Результаты приведены частично) Значения статистических параметров различаются в зависимости от размера базы данных, версии SQL Server и конфигурации аппаратных средств. Полученные нами результаты показывают, что на разбор и компиляцию хранимой процедуры ProductsMostPopular затрачено 187 миллисекунд, а на ее выполнение — 1826 миллисекунд. Эта информация о временах исполнения получена включением опции STATISTICS TIME. Наиболее интересна та часть результатов, где указано значение «logical reads» для таблицы OrderDetails. Это число страниц, считанных из буфера; значение 3800 в сравнении с аналогичным значением для таблицы

Анализ SQL-уровня

245

Products подтверждает предположение о том, что использование оператора Table Scan для выборки данных неэффективно. Иногда также полезно значение параметра «scan count». Оно соответствует числу обращений к объекту и напрямую связано с типом используемого соединения (join). Например, значение «scan count» для запроса, использующего циклическое соединение (loop join) и возвращающего 100 строк, может быть равно 100, тогда как для того же запроса, использующего соединение слиянием (merge join), «scan count» может быть равен 1, В нашем случае значения данного параметра неинтересны, так как довольно малы. Значения «physical reads» и «read-ahead reads» зависят от того, считаны ли уже необходимые данные в буфер или нет. С точки зрения настройки производительности запросов эти два параметра не представляют интереса. На основании анализа плана плохо работающего запроса вы можете принять решение о добавлении, удалении или изменении индексов, изменении запроса или схемы базы данных. Наилучшим вариантом считается тот, который даст максимальный прирост производительности, и по нашему опыту, этого удается достичь настройкой индексов. Кроме того, этот способ обычно минимизирует риск внесения новых функциональных ошибок. Наши подходы к настройке индексов описаны в следующем разделе.

Индексы Если вы уже работали раньше с SQL Server, то, вероятно, слышали о кластерных и некластерных индексах. Глубокое понимание методов хранения и использования индексов совершенно необходимо для их правильной настройки. Подробное обсуждение индексов в SQL Server выходит за рамки данной книги. В табл. 8-2 приведена общая информация о каждом типе индексов. Табл, 8-2. Типы индексов SQL Server Типы индекса

Описание

Кластерный

Таблица физически сортируется по значениям столбцов индекса. Индексы этого типа содержат все данные таблицы. Кластерный индекс создается автоматически при создании первичного ключа, если явно не указано иное

см. след. стр.

Глава 8

246

Табл. 8-2.

(продолжение)

Типы индекса

Описание

Некластерный

Данные таблицы не содержатся внутри индекса, просто индекс содержит указатели на место расположения данных таблицы. При обращении к столбцу, не входящему в индекс, выполняется операция поиска по закладке (Bookmark Lookup) в таблице, организованной в виде «кучи», или в кластерном индексе

Правильный выбор индексов В реальной ситуации выбрать правильный индекс не так-то и просто. При этом нельзя ограничиться рассмотрением только плохо работающего запроса, гак как изменение индексов может повлиять на другие запросы, которые их используют. Например, если время исполнения запроса SELECT снижается при создании новых индексов, то время исполнения запросов INSERT, DELETE или UPDATE в некоторых случаях вырастает. Еще больше влияет на ситуацию создание индекса по часто изменяющемуся столбцу. При изменении столбца для сохранения порядка значений в индексе потребуется перемещение индексных записей, в результате чего возможны дополнительные задержки для больших таблиц. Транзакции, исполняющиеся длительное время, способны надолго захватывать монопольные блокировки, что приводит к возникновению «узких» мест в результате блокирования других сессий. По счастью, как мы уже упоминали в главе 3, реальные сценарии пользовательских действии можно записать и использовать з нагрузочных тестах. В этом случае вы можете легко выполнить повторные тесты и сравнить результаты после каждого изменения. Исполнение нагрузочных тестов позволит найти «узкие» места и снизить риск порождения новых проблем из-за изменений в индексах. Кроме того, вам удастся измерить общий прирост производительности в результате каждого изменения. В демонстрационных целях все наши примеры настройки индексов используют один запрос. Некластерный индекс Некластерный индекс не содержит все данные таблицы, а только копии данных из выбранных столбцов и указатели на положение остальных данных таблицы. Положение может быть ключом

Анализ SQL-уровня

247

кластерного индекса или идентификатором строки, если у таблицы нет кластерного индекса. Эти свойства некластерного индекса позволяют сделать его компактным, в результате чего сканирование всего дерева индекса требует небольшого числа операций чтения страниц, по сравнению со сканированием кластерного индекса. Следовательно, при выборке диапазона данных, если все требуемые столбцы входят в состав некластерного индекса, он работает быстрее кластерного. Нам часто приходилось наблюдать значительный прирост производительности в результате создания некластерных индексов. Хотя в нашу задачу не входит описание всех возможных вариантов применения некластерного индекса, мы рассмотрим покрывающие (covering) индексы, с которыми имеем дело чаще всего. Покрывающим называется индекс, содержащий все столбцы, используемые в запросе. При правильном применении, благодаря ликвидации необходимости поиска по закладке, покрывающие индекс существенно повышает производительность запроса. Так как некластерный индекс не содержит иных данных таблицы, помимо индексированных столбцов, то любое обращение к другим столбцам потребует выборки их данных либо из кластерного индекса, либо из кучи. Введение в индекс дополнительных колонок, не используемых в аргументах поиска (Searchable Arguments, 5ARG) или условиях соединения, позволяет получить все данные из некластерного индекса без дополнительного поиска. Покрывающий индекс: пример 1 Из приведенного ранее анализа плана выполнения хранимой процедуры ProductsMostPopular следует, что большинство логических операций чтения выполняется для таблицы OrderDetails. Сначала получим информацию об индексах этой таблицы, выполнив следующий оператор:

sp.helpindex OrderDetails Получим один некластерный индекс на столбцах OrderlD и ProductlD. Более того, поле index_description говорит о том, что это ограничение первичного ключа. На основании информации об индексе и запросе, используемом в ProductsMostPopular, можно построить табл. 8-3, которая позволит определить, какие столбцы и в каком порядке следует использовать.

248

Глава 8

Табл. 8-3. Слисок и порядок выбранных столбцов Таблица OrderDetails

Столбцы

Аргумент поиска (SARG) GROUP BY или ORDER BY JOIN Другие, используемые запросом, столбцы Существующий индекс

Нет Product! D ProductID Sum(Quantity)

Первичный ключ, некластерный индекс no (OrderfD, ProductID)

Быстрые клавиши запросов Хранимые процедуры или операторы SQL сохраняют средствами окна Customize, вызываемого из меню Tools. Далее хранимую процедуру можно вызывать,; применяя быстрые клавиши. Например, как показано на рис. 8-3, можно связать $p_heipindexc CTRL-f Ft.

Рис. 8-3. Окно Customize позволяет задавать быстрые клавиши для вызова хранимых процедур

Анализ SQL-уровня

249

Когда в следующий раз вы захотите вызвать spj)eipsndexf достаточно выделить имя интересующей вас таблицы и нажатс> CTRL + F1. Быстрые клавиши очень удобно использовать с spjiefpindex и s Как видно из табл. 8-3, некластерный индекс по столбцам РгоductlD и Quantity мог бы покрыть все столбцы. Кроме того, так как ProductID используется в выражении CROUP BY, то индекс, в котором ProductID следует первым, оказался бы более эффективным, чем тот, в котором сначала идет Quantity. Тем не менее создадим два индекса с разным порядком столбцов и посмотрим, какой из них окажется эффективнее. Используем следующий сценарий: CREATE INDEX IX_OrderDetallsJ»roductID_Quantity ON OrderDetails (ProductID, Quantity) CREATE INDEX IX_OrderDetailsJ3uantity_ProductID ON OrderDetails (Quantity, ProductID) Теперь, когда мы снова запустим ProductsMostPopular, оптимизатор запросов выберет другие операторы и покрывающий индекс по полям ProductID и Quantity. Сервер используем тот же самый: двухпроцессорный на базе 1 -гигагерцового Pentium. Новый план выполнения показан на рис. 8-4. Вместо оператора Table Scan теперь задействован Index Scan, a вместо Hash Match/Aggregate — Stream Aggregate. Для сравнения двух покрывающих индексов использован совет оптимизатору, который показан полужирным шрифтом в следующем фрагменте кода: SELECT TOP 5

OrderDetails. ProductID, SUM(OrderDetails. Quantity) as TotalNum, Products. ModelName

FROM

OrderDetails UNDEX=IX_QrderDetails_Quantity_ProductID) INNER JOIN Products ON OrderDetails. ProductlD = _ Products. ProductID

SROUP BY

Глава 8

250 OrderDetails.ProductlD, Products.ModelName ORDER BY

TotalNum DESC

Hrgumtnl: ЭВТСТ r([store].[dha] fOrd»rOatails]. [ [C«_OrderL :ails ProductlD.'."««vI. ITEMED - '-'.VASD

Рис. 8-4. План исполнения после создания покрывающих индексов для таблицы OrderDetails

ПРИМЕЧАНИЕ В большинстве случаев оптимизатор запросов выбирает наиболее эффективные индексы и операторы. Однако хорошей практикой считается проверка выбранного плана принудительным заданием альтернативных планов, после чего следует сравнить результаты. В данном примере рассматриваются три плана выполнения. Статистика для каждого из них показана в табл. 8-4. Как мы и предсказывали, первый покрывающий индекс по столбцам ProductlD и Quantity дает наилучшие результаты. Фактически при обратном порядке столбцов в покрывающем индексе за-

Анализ SQL-уровня

251

прос исполняется дольше, чем в отсутствие индекса. Как видите, каждое изменение индексов следует тщательно тестировать. Без этого настройка индексов может снизить производительность приложения. Табл. 8-4. Сравнение статистики планов выполнения запросов Покрывающий индекс по Первоначальный ProductID запрос и Quantity Относительная стоимость выбранных операторов Число логических операций чтения no OrclerDetails Длительность исполнения, мс

Покрывающий индекс по Quantity и ProductID

3800

Index Scan (51 %) Index Scan и Stream и Hash (38 %) Aggregate (49 %) Match/Aggregate (61 %) 2184 2370

1826

1021

Table Scan (46 %) и Hash Match/ Aggregate (54 %)

2095

В данном примере применение покрывающего индекса позволило сэкономить примерно 800 миллисекунд. В обычном случае мы продолжили бы анализ запроса, чтобы определить, нельзя ли еще повысить скорость исполнения запроса с помощью индексированного представления. Индексированные представления для кластерных индексов рассматриваются в разделе, посвященном кластерным индексам. Покрывающий индекс: пример 2 В этом примере мы рассмотрим хранимую процедуру Ordersiist. Запрос возвращает историю заказов клиента и требует CustomerlD в качестве параметра. Ниже приведен сценарий исполнения хранимой процедуры: DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE GO

SET STATISTICS 10 ON SET STATISTICS TIME ON GO

EXEC OrdersList @CustomerID = 10704

252

Глава 8

Следуя тому же методу, что и в примере 1, мы получаем статистику запроса, включив STATISTICS Ю и STATISTICS TIME, и рассматриваем план выполнения. Использование STATISTICS TIME позволяет установить, что запрос исполняется примерно 640 миллисекунд. Это не так уж долго по сравнению с ProductsMostPopuiar; однако план выполнения показывает, что используются операторы Table Scan и Bookmark Lookup, из чего обычно следует необходимость настройки индексов. Предположим, что OrdersList исполняется часто и требует настройки. Нам необходимо проанализировать, какие столбцы использует процедура OrdersList. При исполнении системной процедуры helptext с OrdersList в качестве параметра выводится следующий текст; CREATE Procedure OrdersList (

§CustomerID

int

' As SELECT

Orders.OrderlD, Cast(sum(orderdetails.quantity*orderdetails,unitcost) as money) as OrderTotal, Orders.OrderDate, Orders.ShipDate

FROM

Orders INNER JOIN OrderDetails ON Orders.OrderlD = OrderDetails.OrderlD

GROUP BY CustomerlD, Orders.OrderlD, Orders.OrderDate, Orders.ShipDate HAVING Orders.CustomerlD = ^CustomerlD На основании анализа кода OrdersList мы можем построить следующие таблицы, аналогичные табл, 8-5:

Анализ SQL-уровня

253

Табл. 8-5. Столбцы таблицы Orders используемые OrdersList Таблица Orders

Столбцы

Аргумент поиска (SARC) GROUP BY или ORDER BY

CustomerlD CustomerlD, OrderlD, OrderDate, ShipDate OrderlD Нет Нет

JOIN Другие, используемые запросом, столбцы Существующий индекс

Табл. 8-6. Столбцы таблицы OrderDetails используемые Orders List Таблица Orders Details

Столбцы

Аргументы песка (SARG) GROUP BY или ORDER BY JOIN Другие, используемые запросом, столбцы Существующий индекс

Нет Нет OrderlD SUM(Quantity*Unitcost) Первичный ключ, некластерный индекс по (OrderlD, ProductID)

СОВЕТ Настоятельно рекомендуем вам, особенно при анализе более сложных запросов, записывать все используемые столбцы каждой таблицы. Аналогично первому примеру с покрывающим индексом мы можем создать на основании табл. 8-5 и 8-6 следующие два покрывающих индекса; CREATE INDEX IX_Orders_CustomerID_Covered ON OrderDetails (CustomerlD,OrderlD, OrderDate, ShipDate) CREATE INDEX IX_OrderDetails_OrderID_Quantity_UnitCost ON OrderDetails (OrderlD, Quantity, Unitcost) Статистика, полученная до и после создания покрывающих индексов, приведена в табл. 8-7. Как видно из табл. 8-7, применение покрывающих индексов ускорило запрос почти в сто раз. Наш опыт показывает, что создание подходящих покрывающих индексов нередко позволяет до-

254

Глава 8

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

С покрывающими индексами

Относительная стоимость Table Scan no Index Seek no выбранных операторов Orders (22 %) Orders (42 %) Bookmark Lookup no Index Seek no OrderDetails (75 %) OrderDetails (51 %) Число логических Orders = 520 Orders = 3 операций чтения OrderDetails - 160 OrderDetails = 30 Длительность исполнения, мс

644

Кластерный индекс Так как кластерный индекс физически сортирует данные таблицы, то в таблице не может быть больше одного такого индекса. Подобные свойства кластерного индекса в ряде случаев весьма выгодны. Например, наличие в таблице кластерного индекса позволяет дефрагментировать ее. Кластерный индекс следует создавать для каждой таблицы, если нет веских оснований отказаться от него. При этом следует выбирать столбцы малого размера, так как все некластерные индексы будут содержать ключи кластерного индекса. Использование больших ключей кластерного индекса потребует дополнительного пространства для хранения некластерных индексов, что также увеличит число операций ввода-вывода. Средствами SQL Server легко создать кластерный индекс для каждой таблицы — по умолчанию при определении ограничения первичного ключа. Сложно выбрать подходящий набор столбцов кластерного индекса. Описание всех вариантов применения кластерного индекса выходит за рамки данной главы. Здесь мы рассмотрим только вопросы, которые, по нашему опыту, разработчики часто упускают из виду:

Анализ SQL-уровня •

255

параметр FILLFACTOR;

• кластерный индекс для представления, Рассмотрим каждый из этих случаев на конкретном примере. FILLFACTOR Параметр FILLFACTOR задает объем пространства, резервируемого на каждой странице. Например, значение 80 зарезервирует 20% свободного пространства, что примерно равно 1,6 кбайт. Это полезно для таблиц или индексов со множеством вставок и обновлений. Наличие дополнительного свободного пространства позволяет уменьшить частоту реорганизаций, или разбиения, страниц (page split), вызываемых операциями вставки или обновления на заполненной странице. Предположим, например, что в таблице'информации о клиентах имеется поле адреса, которое при создании записи о клиенте остается пустым. Если страница, содержащая такую запись, заполнена или почти заполнена, то обновление информации адреса потребует дополнительного пространства и вызовет разбиение страницы. Последнее, в свою очередь, чревато фрагментацией и уменьшением общей плотности хранения данных. Если из-за большого числа разбиений страниц они заполнены только на 50%, то для получения хранящихся в них данных потребуется вдвое больший объем операций ввода-вывода по сравнению со 100-процентным заполнением страниц. Резервирование свободного пространства на странице выгодно для приложений с большим числом вставок и обновлений, благодаря уменьшению числа разбиений страниц и степени вызванной этими разбиениями фрагментации. Так как FILLFACTOR гарантирует наличие свободного пространства только во время создания, необходим периодически мониторинг фрагментации таблиц и индексов, а также плотности страниц. Команда DBCC SHOWCONTIC позволяет получить информацию о фрагментации и плотности данных в таблицах и индексах. Чтобы продемонстрировать эффект фрагментации, мы немного модифицируем таблицу Orders в базе данных сайта-примера IBuySpy. Следующий код добавляет поле описания, допускающее значения NULL, и кластерный индекс по столбцу OrderlD: ALTER TABLE Orders ADD OrderDesc Varchar(SOO) NULL

256

Глава 8

CREATE CLUSTERED INDEX IXC_Orders_OrderID ON Orders (OrderlD) GO

Использовав код из листинга 8-4, мы можем измерить производительность запроса при разных уровнях фрагментации: Листинг 8-4 - Сбор производительности запроса при разной фрагментации. -- Очистка кэша буферов данных и планов выполнения. DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE GO

- Включить отображение статистики ввода-вывода и времени. SET STATISTICS 10 ON SET STATISTICS TIME ON GO - Запрос к таблице Orders. SELECT TOP 10 WITH TIES CustomerlD, _ MAX(DateDiff(hh, OrderDate, ShipDate)} MaxShippingDelay FROM Orders (INDEX=IXC_Orders_OrderID) GROUP BY CustomerlD ORDER BY MaxShippingDelay DESC, CustomerlD GO - Отобразить информацию о фрагментации для таблицы Orders. DBCC SHOWCONTIG('Orders') GO

Ниже показан фрагмент результатов работы кода из листинга 8-4: DBCC SHOWCONTI6 scanning 'Orders' table... Table: 'Orders' (2025058250); index ID: 1, database ID: 7 TABLE level scan performed. - Pages Scanned : 418 - Extents Scanned : 54 - Extent Switches ; 53 - Avg. Pages per Extent ; 7.7 - Scan Density [Best Count:Actual Count] ; 98.15* [53:54] - Logical Scan Fragmentation : 0.24Sf - Extent Scan Fragmentation : 1.85* - Avg. Bytes Free per Page : 25.2 - Avg, Page Density (full) : 99.69X DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Анализ SQL-уровня

257

Table ' O r d e r s ' . Scan count 1, logical reads 419, physical reads 0, read-ahead reads 0. 1

SQL Server Execution Times . CPU time = 297 ms, elapsed time = 302 ms. (Результаты приведены частично)

Наиболее интересной частью результатов работы DBCC SHOWCONTIC являются «Scan Density» (плотность сканирования) и «Avg. Page Density» (средняя плотность страницы). Плотность сканирования отражает смежность ссылок на экстенты: чем больше фрагментация таблицы, тем меньше плотность сканирования. Для выборки данных из менее фрагментированных таблиц потребуется меньше переключений экстентов. Чем ближе средняя плотность страницы к 100%, тем меньше операций ввода-вывода требуется на считывание данных из таблицы. Это связано с используемым SQL Server методом выборки данных со страницы; независимо от степени ее заполнения, вся 8-килобайтная страница считывается целиком. В нашем случае оба значения плотности оптимальны. Теперь посмотрим, что произойдет, если изменить содержимое столбца OrderDesc в каждой десятой строке таблицы Orders. Для этого выполним следующие операторы: - Использование функции REPLICATE здесь не вызвано необходимостью, но -- она может быть вам полезна для генерации тестовых данных. UPDATE Orders SET OrderDesc = 'Some description ' + REPLICATE('X', OrderlD X 10) WHERE OrderlD X 10 = 0

Снова выполним код листинга 8-4 и проанализируем производительность выполнения запроса и уровень фрагментации таблицы Orders. Результаты теперь будут такими: Table: 'Orders' (2025056250); index ID: 1, database ID: 7 TABLE level scan performed. - Pages Scanned : 834 - Extents Scanned : 110 - Extent Switches : 833 - Avg. Pages per Extent : 7.6 - Scan Density [Best Count:Actual Count] : 12.59* [105:834]

258

Глава 8

- Logical Scan Fragmentation : 50.00% - Extent Scan Fragmentation : 36.36* - Avg. Bytes Free per Page : 3768.9 - Avg. Page Density (full) : 53.44* DBCC execution completed. If DBCC printed error messages, _ contact your system administrator. Table ' O r d e r s ' . Scan count 1, logical reads 836, _ physical reads 0, read-ahead reads 0. SQL Server Execution Times: CPU time = 307 ms, elapsed time = 307 ms. (Result abbreviated) После того как мы искусственно вызвали фрагментацию, скорость исполнения запроса существенно не изменилась; однако количество логических операций чтения почти удвоилось: 836 против 419. В основном это связано с уменьшившейся средней плотностью страницы, которая с 99% снизилась до 53%. В данном случае длительность запроса измерялась для одного пользователя. С увеличением числа пользовательских сессий негативное влияние дополнительных операций записи проявится в дальнейшем росте времени исполнения запроса. Мы могли бы избежать фрагментации, если бы FILLFACTOR для кластерного индекса таблицы Orders был бы равен 90%. Известно несколько способов изменения FILLFACTOR. Можно удалить кластерный индекс и заново создать его, задав при этом значе ние FILLFACTOR равное 90, либо изменить FILLFACTOR с помощью DBCC REINDEX, Подробнее см. «DBCC DBREINDEX» и «CREATE INDEX» в SQL Books Online. Индексированные представления Индексированные представления относятся к новым средствам SQL Server 2000 Enterprise Edition. В предыдущих версиях SQL Server при каждом обращении к представлению в запросе серверу приходилось считывать данные из базовых таблиц представления. Однако при использовании индексных представлений результаты вычисляются до того, как представление использовано каким-либо запросом. В зависимости от степени накладных расходов, связанных с выборкой данных из базовой таблицы, мате-

Анализ SQL-уровня

259

риализованные наборы результатов могуть дать огромный прирост производительности запросов. В этом примере мы продолжим рассмотрение первого примера для некластерного индекса и продемонстрируем использование индексного представления. По нашему опыту, индексные представления дают существенный прирост производительности при использовании в запросах с такими агрегатными функциями, как SUM и COUNT. Кстати, функция SUM используется хранимой процедурой ProductsMostPopular приложения IBuySpy. Показанный далее запрос является фрагментом этой хранимой процедуры: SELECT TOP 5 QrderDetails.ProductID, SUMCOrderDetails.Quantity) as TotalNum, Products.ModelName FROM OrderDetails INNER JOIN Products ON OrderDetails.ProductID = _ Products.ProductID GROUP BY OrderDetails.ProductID, Products.ModelName ORDER BY TotalNum DESC На основании запроса, используемого в ProductsMostPopular, создадим представление и уникальный кластерный индекс, как показано на листинге 8-5. Листинг 8-5 - Установка опций, требуемых для создания индексированных - представлений. SET QUQTED_IDENTIFIER ON SET ARITHABORT ON SET CONCAT_NULL_YIELDS_NULL ON SET ANSI_NULLS ON SET ANSI.PADDING ON SET ANSI.WARNINGS ON SET NUMERIC_ROIINDABORT OFF

260

Глава 8

if exists (select * from dbo.sysobjects T where id = object_id(N [dbo].[ProductQrderCount]') and _ OBJECTPROPERTY(id, N'lsVieW) = 1) drop view [dbo].[ProductOrderCount] GO CREATE VIEW dbo.ProductOrderCount WITH SCHEMABINDING AS

SELECT od.productid, p.modelname, SUM(od.Quantity) OrderSum , COUNT_BIG(O RecordCount -- Требуется агрегирующая функция COUNT_BIG FROM dbo.orderdetails od INNER JOIN dbo.products p ON od.productid = p.productid GROUP BY od.productid, p.modelname

GO - Первый индекс на индексированном представлении обязан быть - уникальным и кластерным. CREATE UNIQUE CLUSTERED INDEX IXUC_ProductOrderCount ON dbo.ProductOrderCount (ProductID) При создании индексированного представления убедитесь в правильной установке значений пользовательских опций. Обязательные пользовательские опции показаны на рис. 8-5. Кроме того, представление необходимо создавать с атрибутом SCHEMABINDING. И наконец, первый индекс для представления должен быть уникальным кластерным индексом. После создания кластерного индекса, если требуется, можно создать дополнительные некластерные индексы. Более подробную информацию об индексированных представлениях и о связанных с ними требованиях см. в SQL Server Books Online. После создания индексированного представления мы можем снова выполнить процедуру ProductsMostPopular и посмотреть, как изменилась производительность. Параметры производительности сравниваются в табл. 8-8, Как из нее видно, использование индексированного представления ProductOrderCount существенно снизило длительность исполнения запросов и число логических операции чтения. На самом деле операции чтения теперь выполняются не для таблицы OrderDetails, но для представления ProductOrderCount. Ниже показаны результаты STATISTICS IO, полученные при исполнении РгоductsMostPopular.

Анализ SQL-уровня

261

(5 row(s) affected) Table 'ProductOrderCount'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0. (Результаты приведены частично) Табл. 8-8. Сравнение производительности при использовании индексированного представления Покрывающий индекс для Первоначальный Product! D Индексированное вариант и Quantity представление Относительная стоимость выбранных операторов

Table Scan (46 %) u Hash Match/ Aggregate (54 %)

(51 %) u Stream Scan (77 %} Aggregate (49 %)

u Sort (23 %)

Число логических операций чтения таблицы OrderDetails

3800

2184

Длительность исполнения, мс

1826

1021

Index Scan

Clustered Index

Если бы ProductsMostPopular оставалась единственной хранимой процедурой, исполняемой приложением, то можно было бы прийти к выводу, что индексированное представление является наилучшим решением. В реальных приложениях хранимая процедура обычно не одна. Индексированные представления способны радикально повысить производительность чтения, однако при этом зачастую также снижается производительность запросов, выполняющих обновление данных. Следовательно, прежде чем окончательно принять решение об использовании индексированного представления, необходимо провести дополнительное нагрузочное тестирование и убедиться в том, что общая пропускная способность приложения действительно возросла. В поставку SQL Server включен мастер Index Tuning, который в некоторых случаях поможет вам выбрать эффективные индексы. Интересно использовать мастер Index Tuning для анализа исполнения процедуры ProductsMostPopular. Для этого запустите

262

Глава 8

мастер из Query Analyzer (нажмите CTRL-f-l). Для ProductsMostPopular мастер порекомендует вам практически идентичное индексированное представление. Во многих случаях использование мастера Index Tuning сэкономит время и даст полезную информацию об индексах. Если вам раньше никогда не приходилось работать с этим мастером, рекомендуем за дополнительной информацией обратиться к соответствующим разделам SQL Server Books Online. Превосходная статься, посвященная этому мастеру, также опубликована в Microsoft TechNet. Примерами, приведенными в этой главе, ни в коей мере не исчерпываются все возможные случаи настройки индексов — мы хотели только продемонстрировать вам общее представление о важности правильной настройки индексов. Простая ошибка при создании индексов или отсутствие необходимых индексов может полностью парализовать работу сервера при больших объемах транзакций. Оценка всех индексов в базе данных, содержащей множество других объектов, весьма утомительное занятие, но она того стоит. В большинстве случаев база данных с правильно построенными индексами в перспективе создаст вам меньше проблем. При анализе «узких» мест в SQL мы настоятельно рекомендуем вам сначала исследовать индексы и только потом пытаться вносить изменения в запросы или устанавливать дополнительное оборудование.

Заключение В этой главе мы рассказали о способах выявления «узких» мест на SQL-уровне. Были рассмотрены инструментальные средства для мониторинга работы сервера и выявления «узких» мест, а также способы анализа и устранения часто возникающих проблем. Несомненно, для полного изучения SQL Server вам потребуется время и опыт, Прочитав эту глазу, вы не станете в одночасье экспертом, но несомненно узнаете, как выявлять «узкие>> места и быстро исправлять распространенные проблемы производительности на SQL-уровне.

Глава 9

По словам Джонатана Свифта, «необходимость — мать изобретения», но при планировании пропускной способности больше подходят слова Марка Твена: «Необходимость — мать риска». Почему? Потому что расчет пропускной способности — это искусство уменьшить вероятность того, что быстродействие Webприложения снизится из-за увеличения трафика или изменения его характера, и в то же время избежать дополнительных затрат на оборудование. Microsoft Transaction Cost Analysis (TCA) — анализ стоимости транзакции — это основанная на научных разработках методика, позволяющая оценить потребности Web-приложения в оборудовании. Но никогда нельзя быть абсолютно уверенным в том, как пользователи повлияют на работу вашего Webприложения. Будьте готовы к сюрпризам. Планирование пропускной способности — это не стремление к идеалу, а попытка обдуманно подготовиться к различным неожиданностям. Например, если ваша компания планирует провести рекламную акцию в Интернете во время Суперкубка, то с помощью ТСА удастся смоделировать потребности в ресурсах оборудования с учетом повышения пользовательского трафика, которое вы ожидаете при таком крупном маркетинговом мероприятии. Это избавит вас от необходимости тестировать производи-

264

Глава 9

тельность для каждого возможного сценария изменения трафика. Идея использования ТСА для расчета пропускной способности не нова. Она широко применяется со времен появления технологии «клиент — сервер». Однако методика ТСА, о которой речь пойдет в этой главе, специально адаптирована для Web-приложений и Web-сервисов Microsoft Она разработана в 1998— 1999 гг. группой инженеров из Microsoft, в которую вошли Хилал Аль-Хилали (Hilal Al-Hilali), Морган Ослейк (Morgan Oslake), Дэзид Гуимбеллот {David Cuimbellot), Перри Кларк (Perry Clarke) и Дэвид Хауэлл (David Howell). В то время имелось несколько экономических причин для разработки расчета пропускной способности на основе ТСА, которые актуальны и сегодня для среды .NET, Во-первых, такой подход представляет собой научный метод определения технических требований к серверу. Во-вторых, как уже упоминалось ранее, он позволяет владельцам Web-приложений моделировать пропускную способность сайта, исходя из возможного сценария «что, если», резко снижает количество итераций для тестов производительности, необходимых для определения потребностей в ресурсах оборудовании. Например, что произойдет с быстродействием вашего Web-приложения, если в качестве ответа на маркетинговую кампанию, проведенную через электронную почту, ваш сайт посетят незапланированные 10 000 пользователей? ТСА даст ответ на этот вопрос, избавив вас от необходимости проводить дополнительные тесты производительности. И, наконец, ТСА помогает разработчикам сконцентрироваться на оптимизации наиболее трудоемкого кода, связанного с использованием аппаратных ресурсов, в целях увеличения масштабируемости приложения с имеющимся оборудованием. Наша группа успешно использовала методику ТСА для Web-сайтов Microsoft, включая http://shop.microsoft.com. ТСА определяет связанные с пользовательскими сценариями затраты на ресурсы оборудования, которые необходимы для моделирования требуемого роста пропускной способности оборудования. Конечный продукт ТСА — это совокупная стоимость серверных ресурсов в зависимости от пользовательских операций, которую кладут в основу прогнозирования уровней максимального числа одновременных подключений для Web-приложения. Поскольку ТСА определяет максимальные уровни одновре-

Оценка эффективности US-уровня посредством ТСА

265

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

Одновременные подключения: термин без четкого определения Сколько одновременных подключений может поддерживать сайт? Именно этот вопрос чаще всего обсуждался в нашей команде при расчете производительности. Хотя этот вопрос — не редкость, термин одновременные подключения не имеет четкого определения и часто истолковывается неверно. Ответ на вопрос зависит от того, как понимать и трактовать слово одновременные. HTTP-протокол не сохраняет состояния. Он получает и отправляет информацию при запросе, но часто в перерывах между запросами пользователей он простаивает. Например, некоторые определяют одновременные подключения с помощью счетчика Current Anonymous Users. Однако это не совсем верно, поскольку один пользователь может установить соединение, отправив только один запрос, и затем отключиться, а другой отправит несколько запросов, которые будут считаться одним соединением. Представьте другой сценарий, когда тысяча пользователей просматривают страницу Web-приложения IBuySpy, включенного в примеры к .NET. Однако только часть из них отправляет запросы, которые одновременно обрабатываются на Web-сервере. Остальные находятся в так называемом режиме размышления (think time), т. е. они либо заполняют формы, либо просматривают данные, прежде чем получить новые данные или отправить данные на сервер, таким образом, дополнительной активности сервера в этот период не наблюдается, В этой ситуации для тысячи пользователей IBuySpy, взаимодействующих с сайтом в одном и том же интервале времени, сервер одновременно обрабатывает только подмножество из тысячи клиентских запросов.

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

266

Глава 9

собности необходим тщательный анализ соотношения количества запросов, одновременно обрабатываемых сервером, и общего количества пользователей, а не только конечное число одновременно работающих с вашим Web-приложением. Я хочу подчеркнуть, что необходимо принимать so внимание как процесс обработки одновременных запросов сервером, так и количество пользователей, поскольку пользователи вашего Web-приложения не всегда отправляют запросы, которые требуют одновременной обработки сервером. Чтобы лучше продемонстрировать это важное различие, представьте 50 клиентов, одновременно запрашивающих данные с сервера. Вероятность того, что эти запросы одновременно достигнут сервера, сильно различается в зависимости от ситуации. На прохождение запросов на сервер влияют скорость соединения клиента, задержки в сети, перегруженность каналов связи Интернета и количество сегментов сети на пути прохождения запросов. Если в любом из этих 50 запросов изменится хотя бы один из указанных параметров, то возможно значительное изменение общей активности на серверном уровне. Для пользователей, одновременно запрашивающих данные с сервера, соотношение между количеством пользователей и количеством запросов, одновременно обрабатываемых на сервере, не обязательно составляет «один к одному». Четко представляйте себе эти ограничения до того, как потратиться на планирование пропускной способности.

Одновременные подключения в ТСА Мы считаем, что крайне важно обсудить термин одновременные подключения, потому что средствами ТСА прогнозируется теоретически возможный максимальный уровень одновременных подключений и моделируется пропускная способность сайта. ТСА позволяет рассчитать затраты на аппаратные ресурсы для среднестатистических пользователей, одновременно работающих с зашим Web-приложением. Среднестатистический пользователь сайта вычисляется с помощью профиля пользователя, и это первый из пяти этапов методики ТСА. Одновременные подключения ТСА представляют уровень среднестатистических пользователей, обращающихся к ресурсам ваших серверов,

Оценка эффективности IIS-уровня посредством ТСА

267

Преимущества проведения ТСА Теперь, после того как мы постарались четко определить концепцию одновременных подключении, перед нами встает следующий вопрос: «Какой уровень серверных ресурсов необходим для вашего сайта?» Методика ТСА предоставляет научный подход при ответе на этот вопрос. Поскольку в ТСА основное внимание уделяется расходам на серверные ресурсы в зависимости от действий пользователей, эту методику разрешается применять независимо от того, основано ли ваше Web-приложение на архитектуре .NET или Windows DNA. В обоих случаях методика практически одинакова. Мы обнаружили только незначительные различия в работе счетчиков системного монитора для Windows DNA и для .NET в Web-приложениях. В табл. 9-1 кратко описаны счетчики и объекты для каждого конкретного случая. Обратите внимание, мы приводим не полный список счетчиков, которые вам необходимо отслеживать, а только те из них, которые изменили свое местоположение при переходе с Windows DNA к .NET. Табх 9-1. Счетчики производительности ТСА в Windows DNA и .NET Счетчик производительности

Объект в Windows DNA

Объект в .NET

ASP Requests/Sec (Запросов в секунду)

Active Server Pages (Страницы Active Server)

ASP,NET Applications

ASP Execution Time Active Server Pages (Время выполнения запроса) (Страницы Active Server)

ASP.NET

ASP Wait Time (Время ожидания запроса)

Active Server Pages (Страницы Active Server)

ASP.NET

Requests Queued (Запросов в очереди)

Active Server Pages (Страницы Active Server)

ASP.NET

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

268

Глава 9

Использование ТСА для снижения относительно зысоких затрат на операции на сайте не только повысит масштабируемость вашего сайта, но также значительно снизит совокупную стоимость владения для него — достаточно внедрить надежный метод моделирования потребностей в оборудовании для обеспечения пропускной способности в соответствии с развитием вашего сайта и ростом трафика. ТСА позволяет максимально использовать ресурсы существующего оборудования, рассчитать сроки внедрения дополнительного оборудования и спрогнозировать дополнительную пропускную способность исходя из того, сколько одновременных подключений данное дополнительное оборудование сможет должным образом обслуживать. Таким образом, расходы на оборудование удается тесно связать с общим числом пользователей. Следующий реальный пример показывает, как средствами методики ТСА удалось увеличить масштабируемость сайта Microsoft shop.microsoft.com.

Реальный пример — Shop.Microsoft.com - Весной 1999г. группа АСЕ Team провела тесты ТСАдлясабта - электронной коммерции компании Microsoft http://shop.microsoft.com версии 2.5. При этом обнаружилось, что наибольшие нагрузка и трафик приходятся на такие действия/как просмотр начальной страницы и просмотр товаров, которые',,. = характеризуются относительно высокой стоимостью ресурсов процессора (CPU), Это означает, что на пользователей, запрашивающих начальную страницу и страницы с описанием- продуктов, затрачивается больше серверных ресурсов. ; Определение этих дорогостоящих операций при помощи ТСА позволило разработчикам сосредоточиться на снижении загрузки центрального процессора,сайта. После прозе- •; дения ТСА для кода http://shop.rnicrosoft.com версии 4.5, мы обнаружили, что затраты на действия покупателей уменьшились на 25% по сравнению с предыдущими версиями, при ;; этом в том же процентном соотношении увеличилась пропускная способность для одновременно обслуживаемых покупателей. Это означало, что электронный магазин может должным образом обслуживать на 25% больше покупателей/; при той же конфигурации оборудования, используя код вер-

Оценка эффективности US-уровня посредством ТСА

269

cuu 4.5. Основное снижение обицих затрат пришлось на сни'-, жение расходов для начальной страницы и действуя по про- ? смотру товаров, на которые приходятся наибольшие нагруз\ ка и трафик, что и удалось определить при помощи методу- :: V ки ТСА для более ранней версии 2.5. В коде версии 4.5 Г уменьшили стоимость этих операций, поскольку при достижение гораздо более,высокого соотношения частоты за5 npocosASf в секунду и пропускной способности требуется .'• ! значительное увеличить загрузку центрального процессора,. Кроме того, наша первоначальная модель ТСА для версии • ! == 2.5 позволила разработчикам выполнить сценариич<что, " если» для последующих версий, быстро рассчитав влияние программных решений на общую пропускную способность сайта. Вывод очевиден: если правильно определить пользовательский трафик для Web-приложения и соответствующее ;: - потребление ресурсов оборудования, то оптимизацией кода . приложения, требующего больших затрат на ресурсы, уда- • ется повысить пропускную способность, не увеличивая затраты на оборудование,

Пять этапов ТСА Выполнение ТСА разделено на пять этапов. Первый и очень важный — определение профиля использования вашего Web-приложения. Почему профиль использования настолько важен? Потому что расчеты, назначенные для соответствующих действий на сайте, на этом этапе сильно влияют на расчет затрат на аппаратные ресурсы сайта и значительно повлияют на окончательный расчет пропускной способности. При неверных исходных данных вы получите неверный результат, поэтому не жалейте времени для самого тщательного анализа профиля пользователя. Второй шаг — непосредственное выполнение дискретных нагрузочных тестов на основе сценариев, определенных в профиле пользователя, — это позволит определить затраты на серверные ресурсы при максимальной загрузке. Третий шаг — проведение расчетов для определения величины затрат. Мы предоставляем вам электронную таблицу Microsoft Excel, которая поможет упростить эти расчеты. Файл электронной таблицы ТСА находится на компактдиске, прилагаемом к этой книге. На четвертом этапе выполни-

270

Глава 9

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

2. Нагрузочный тест для определения затрат на действия пользователя. • Проведение дискретных нагрузочных тестов по действиям для определения максимальной пропускной способности ASP и соответствующей загрузки процессора. 3. Расчет стоимости каждого действия пользователя. • Расчет затрат на каждое действие пользователя в секунду, используя данные этапов 1 и 2.

4. Оценка пропускной способности сайта. • Расчет затрат на каждое действие пользователя в секунду для предполагаемого количества одновременных подключений при максимальном количестве доступных ресурсов. 5. Проверка пропускной способности сайта. • Выполнение сценариев проверки для предполагаемого числа пользователей с заданием определенного интервала времени посещения сайта. • Сравнение результатов тестов и прогнозируемой загрузки ресурсов.

Рис. 9-1. Пять этапов методики ТСА

Этап 1: создание профиля пользователя Первый этап — создание профиля пользователя на основе доступных данных о существующем рабочем трафике. Для этого можно просмотреть хронологию файлов журналов вашего Webсервера (с помощью различных анализаторов журналов) или про-

Оценка эффективности US-уровня посредством ТСА

271

анализировать активность базы данных. Если данные о трафике отсутствуют, то можно предположить величину нагрузки, вызванной пользовательскоим трафиком, исследуя данные о трафике на аналогичных сайтах. Профиль пользователя понадобится для оценки стоимости отдельных транзакций на сайте на основе соотношения отдельных операций к общему трафику. Для Web-приложения IBuySpy на транзакции при просмотре товаров приходится около 61% трафика. Хороший источник информации о трафике на сайте — журналы производительности IIS. Однако по возможности следует автоматизировать процесс анализа данных журналов IIS, поскольку их объемы могут достигать нескольких гигабайт и на анализ потребуется много времени. Из множества анализаторов файлов журналов вы можете выбрать наиболее подходящий. При выборе журналов лучше всего использовать несколько журналов за максимально длительный период времени (как минимум за неделю, если такие журналы IIS доступны) для того, чтобы получить средние значения, наиболее приближенные к реальным. Чем больше данных о выработанном трафике вы получите, тем более достоверными окажутся показатели для профиля использования.

СОВЕТ При создании профиля исключите трафик, который чрезвычайно повышает среднюю статистику просмотра страницы. Убедитесь, что просмотр страницы был успешным, что код возврата для запроса равен 200, а не была показана сообщающая об ошибке страница, возвратившая успешный код возврата. В некоторых случаях для того, чтобы убедиться, что ваше Webприложение отвечает требованиям к пропускной способности независимо от пиков обращений, вам могут понадобиться журналы IIS для определения ключевых периодов трафика с наивысшей загрузкой (например, когда все совершают предпраздничные покупки). Это поможет спрогнозированным данным ТСА отразить наихудшие сценарии трафика для вашего Web-приложения. Если ваш сайт создан недавно и нет данных о его работе, то вы можете попытаться предугадать их. Для этого достаточно просмотреть открытую доступную статистику для аналогичных 10-566'

Глава 9

272

сайтов, включающую просмотры страниц, категории пользователей и демографические данные об основных пользователях. Определить один профиль, лучше всего представляющий трафик вашего сайта, так же важно, как и вероятность того, что распределение использования сайта будет включено а сценарии «что, если». Например, после анализа журналов IIS мы обнаружили, что действие по просмотру товаров имеет нормальное распределение со средним значением 60% и со стандартным отклонением в 10%. Это означает, что при определении операционных затрат для 95% возможного распределения просмотра вам придется рассчитать стоимость просмотра для двух стандартных отклонений или от 40% величины просмотров для нижнего предела до 80% величины просмотров для верхнего предела. В табл. 9-2 показан профиль пользователя, который мы создали для IBuySpy TCA. Табл. 9-2. Профиль пользователя IBuySpy TCA Средний процент Действия пользователя

Поиск Просмотр товаров Добавление в корзину Подключение и оформление заказа Регистрация и оформление заказа Всего

посещений (профиль пользователя), %

Стандартное отклонение, %

14,14

61,49 10,47

0 5

6,90

0,5

1,5

то

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

Оценка эффективности US-уровня посредством ТСА

273

Другой важный аспект настройки профиля пользователя — определение периодичности совершения транзакций, Например, мы установили среднюю длительность сессии для пользователя IBuySpy равной 10 минутам. Вы будете использовать данную.частоту транзакций для времени бездействия сценария контрольного нагрузочного теста (этап 5), чтобы проверить рассчитанную пропускною способность, определенную в модели ТСА.

Этап 2: нагрузочный тест для определения затрат на действия пользователя После создания профиля пользователя необходимо собрать данные о производительности транзакций, необходимые для измерения расходов на ресурсы для каждого действия пользователя. Для этого следует создать нагрузочный сценарий для тестового выполнения каждого из определенных действия покупателя. Цель — определение расходов на серверные ресурсы, таких, как загрузка центрального процессора при максимальной пропускной способности. Выполнить эту задачу вам поможет Microsoft ACT, средство для генерирования/эмуляции нагрузки, о котором говорилось в главе 3. Именно им мы воспользуемся на данном этапе ТСА. Несколько примеров сценариев ACT, которые мы использовали, записаны на компакт-диске, прилагаемом к этой книге. Цели и параметры нагрузочных тестов ТСА Выполнение сценария только для отдельной операции загружает IIS максимальным количеством запросов, что позволяет достичь максимального количества ASP-запросов в секунду. Наибольшую пропускную способность ASP удается зафиксировать непосредственно перед уменьшением количества ASP-запросов в секунду. Вам также следует удостовериться, что время операционной задержки резко не возросло. Мы советуем установить среднее время задержки ASP в 2 секунды. Для расчета операционной задержки используйте формулу: Среднее время задержки ASP = (Ср. время исполнения ASP * Ср. время ожидания ASP)

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

274

Глава 9

набора тестов производительности. Каждый тест должен продолжаться достаточно долго для достижения стабильного состояния (steady-state^. Это состояние достигается при завершении использования ресурсов, необходимых для запуска теста, установки сетевых соединений, заполнения кэша сервера соответствующим образом и периодического выполнения пакетных заданий или резервного копирования. Для проведения ТСА для IBuySpy мы выполняли нагрузочный тест в течение 10 минут, не считая времени запуска теста. Измерение таких ресурсов, как загрузка процессора и количество ASP-запросов в секунду, необходимо проводить все время стабильного состояния теста. Причина уменьшения количества ASP-запросов в секунду при увеличении нагрузки может крыться в контекстном переключении, интенсивном обращении к страницам памяти, вводе/выводе на диск, перегрузке сети или повышении нагрузки и падении производительности клиента. Например, при проведении ТСА для IBuySpy мы ежесекундно отслеживали контекстное переключение, чтобы удостовериться, что количество переключений в секунду не превышают 15 000. Контекстное переключение заключается в том, что поток больше не исполняется из-за того, что он заблокирован, ожидая физического или логического ресурса, или поток перешел в режим ожидания. О частых контекстных переключениях свидетельствуют низкая пропускная способность и высокая загрузка процессора, которые возникают при достижении уровня 15 000 и выше. Задокументируйте максимальное количество ASP-запросов в секунду, как только заметите признаки снижения быстродействия вашего приложения. Для этого тщательно следите за показаниями этих счетчиков производительности и убедитесь, что ограничение общей пропускной способности не связано с нехваткой ресурсов на клиенте. Более подробно об использовании системного монитора и его основных счетчиков рассказано в главе 4. Определение максимальной пропускной способности Применение ТСА для расчета пропускной способности полезно при вычислении расходов на любые ресурсы оборудования, такие, как память, диск или процессор. При проведении ТСА для IBuySpy мы измеряли загрузку процессора. Необходимо задоку-

Оценка эффективности US-уровня посредством ТСА

275

ментировать расходы на транзакцию с помощью системного монитора в точке, где достигается максимальное количество ASPзапросов в секунду. Для сравнения счетчиков Windows DNA и .NET см. табл. 9-1. Увеличение количества пользователей, выполняющих сценарий, должно увеличить число ASP-запросов в секунду. Если сайт был разработан должным образом с учетом производительности, то при увеличении нагрузки количество ASPзапросов в секунду и загрузка процессора будут расти,

Совет Постепенно увеличивая загрузку для вашего Web-приложения, отслеживайте количество ASPзапросов в секунду. Если вы заметите, что постепенное увеличение нагрузки не приводит к увеличению количества ASP-запросов в единицу времени, убедитесь, что ограничение пропускной способности не связано с производительностью клиента. Если же последний показатель снизился, уменьшите нагрузку на клиенте и увеличьте число клиентов, чтобы удостовериться, что действительно измеряете стоимость ресурсов сервера и максимальное количество ASP-запросов в секунду. Кроме того, отслеживайте очередь ASP-запросов на сервере. Если значение очереди превысит 1, значит, возникла блокировка. В этом случае снизьте уровень нагрузки. Если количество ASP-запросов в секунду продолжает расти, хотя загрузка процессора не достигла 100%, то данное количество ASP-запросов в секунду в данной точке является максимально возможным. Мы не рекомендуем увеличивать загрузку процессора до 100%, поскольку это может привести к увеличению времени задержки системы и появлению неточностей в расчетах ТСА. Для тестов с IBuySpy максимальная загрузка процессора составляла 90%. Минимизация количества страниц, необходимых для отдельного действия При проведении нагрузочных тестов стоимости операции важно уменьшить количество страниц, необходимых для успешного выполнения отдельного действия. При выполнении сценария

276

Глава 9

проверки для измерения стоимости действия «Добавление в корзину» (Add to Cart), включающего просмотр страниц товаров, часть расходов, которые вы задокументируете по результатам этого теста, будут относиться как к операциям просмотра (Browse], так и к действию «Добавление в корзину» (Add to Cart]. Наша цель — вычислить расходы на ресурсы сервера для отдельного действия. Для этого необходимо уменьшить количество страниц, требуемых для выполнения операции, до абсолютного минимума. Для этого может потребоваться включить в нагрузочный сценарий параметры динамических страниц, например содержащие идентификационные данные покупателя или идентификаторы товаров, чтобы пропустить страницы, которые пользователь обычно посещает в первую очередь.

Этап 3: расчет стоимости каждого действия пользователя Результат нагрузочного теста, выполненного на этапе 2, — это совокупность затрат ресурсов, измеренных в циклах процессора для каждого действия пользователя. Наш сервер IIS IBuySpy содержит два центральных процессора с тактовой частотой 1000 МГц. Стоимость транзакций для загрузки процессора была задокументирована в тот момент, когда было достигнуто максимальное количество ASP-запросов в секунду для данного действия. При этом средняя операционная задержка {время исполнения ASP + время ожидания ASP) составляла менее 2 секунд, значение очереди ASP — ниже 1, контекстных переключений в секунду — 15 000 и загрузка процессора в среднем не превышала 90%. Данные о производительности, полученные в результате теста, в ходе которого мы пытались достигнуть максимального количества ASP-запросов в секунду, показаны в табл.9-3. Эти данные не используются в расчетах расходов на каждую операцию, но позволяют убедиться, что достигнуто максимальное количество запросов ASP в секунду. Результаты тестов с повышенной нагрузкой и соответствующих расходов на операции описаны в табл. 9-4.

277

Оценка эффективности HS-уровня посредством ТСА Табл. 9-3. Результаты теста расходов на каждую операцию для IBuySpy Действия пользователя Поиск Просмотр товаров Добавление в корзину Подключение и оформление заказа Регистрация и оформление заказа

Время Время Средняя Переключений исполнения, ожидания, задержка контекста/с мс мс ASP, мс 62

118

1012

3,8

1015,8

8188 4415

350

355

3262

12,5

0,88

13,38

5287

600

130

730

8355

Табл. 9-4. Расходы на операцию IBuySpy

Действия пользователя Просмотр товаров Поиск Добавление в корзину Подключение и оформление заказа Регистрация и оформление заказа

Загрузка процессора при максимальном количестве ASP-запросов в секунду, %

Максимальное количество ASP-запросов/с

Стоимость (мегациклы)

Стоимость действия (мегациклы)

58,20

193,3

1164

6,02172

',',]

89,5

349,8 98,3

1680 1790

4,80722 18,20956

76,2

307,3

1524

4,95932

279,9

1780

6,35941

Первоначальный результат ваших нагрузочных тестов ТСА —это данные о расходах процессора на действие (последний столбец в табл. 9-4), рассчитанные в мегациклах или 1 МГц. При прозе-

278

Глава 9

genuu ТСА для IBuySpy был использован двойной процессор 1000 МГц с общей мощностью 2000 мегациклов. Зная максимальное количество запросов ASP 8 секунду, можно рассчитать расходы на действие следующим образом: Расход на действие = Использование процессора * количество процессоров * скорость процессора (в Мгц) / количество запросов ASP в секунду Например, когда мы повышали нагрузку для действия по просмотру товаров IBuySpy, то достигли величины 349,8 ASP-запросов в секунду при загрузке процессора 84%. Стоимость для каждой ASP-страницы составила 84% * 2 * 1000 / 349,8 = 4,80274 мегациклов. Прежде чем рассчитывать расходы на действие, необходимо знать количество ASP-страниц, задействованных в этой операции. В действии по оформлению заказа обычно вовлечено несколько ASP-страниц (страница персональной информации, страница кредитной карты, страница доставки, страница подтверждения и т. д.). Вы рассчитываете стоимость действия покупателя, нормализуя число всех необходимых ASP-страниц.

Совет Некоторые ASP-страницы, особенно те, что перенаправляют на другие страницы, обычно не видны клиентам, поскольку они содержат серверную логику и команды для перенаправления. Необходимо учитывать эти типы страниц при расчетах расходов на действие. Расчет расходов на каждое действие пользователя в секунду Активность пользователя Web-приложения носит случайный характер. Но на большом интервале времени использование Webресурсов статистически можно приблизить к усредненному поведению. Профиль пользователя, созданный на этапе 1, должен отражать усредненное поведение пользователя Web-приложения. Мы рассчитываем показатели результативности так же, как и стандартные отклонения, чтобы описать действия пользователя для трафика в сценариях «что, если». Таким образом, удается смоделировать влияние, которое различные распределения трафика оказывают на предполагаемую пропускную способность сайта. Это одно из преимуществ принципа ТСА. Мы рассчиты-

Оценка эффективности US-уровня посредством ТСЛ

279

паем количество действий покупателя в течение периода времени, равного 10 минутам, а затем число действий пользователя в секунду. Нам необходимо знать последний параметр, поскольку общее число расходов на операции выражено в тактовой частоте (скорость 1000 МГц процессора равна 1000 мегациклам в секунду). Стоимость каждого действия пользователя для IBuySpy при среднем распределении результативности детально описана в табл. 9-5. Толкование значений расходов на действие Ключевым в табл.9-5 является значение «Общая стоимость/сею; (0,11601 мегациклов на пользователя), представляющее общую стоимость профиля пользователя. Это значение показывает расходы среднестатистического пользователя на выполнение действий тем способом, который описан нашим средним профилем пользователя. Это число понадобится для расчета пропускной способности сайта на этапе 4 методики ТСА. В табл. 9-5 не только отражены расходы для среднестатистического пользователя, но также приведены данные, позволяющие оптимизировать масштабируемость сайта. Видно, что действия «Добавление в корзину» и «Подключение и оформление заказа» — наиболее дорогостоящие: 0,03394 и 0,03385 соответственно. Для операции «Добавление в корзину» высокие расходы на операцию пользователя в секунду являются следствием довольно высокой стоимости соответствующей операции (8,21 мегациклов). Это означает, что команде разработчиков стоит позаботиться об уменьшении расходов ресурсов серверного процессора, необходимых для проведения этой операции, чтобы увеличить общую масштабируемость сайта, Для операции «Регистрация и оформление заказа» высокие расходы на действие пользователя в секунду объясняются потребностью в довольно большом количестве ASP-страниц (в данном случае 13). А значит, стоимость операции [6,36 мегациклов} необходимо оценивать выше, чем стоимость других операций. Следует снизить стоимость этой операции или уменьшить число страниц, необходимых для ее совершения. При применениии любого их этих методов расходы на одного пользователя в секунду снизятся для операции «Регистрация и оформление заказа», а значит, увеличится масштабируемость,

Табл. 9-5. Расходы на каждое действие пользователя в сек. для IBuySpy (мегациклы)

со

Результативность (профиль пользователя), %

Мин. Aspстраниц

Норм. профиль пользователя

Профиль пользователя, операции

Профиль пользователя, операции Стоимость/ Стоивс действие мость/с

Просмотр товаров Поиск

61,49

0,61

2,18919

0,00365

4,80

0,01752

14,14

0,28

1,00684

0,00168

6,02

0,01010

Добавление в корзину Подключение и оформление заказа Регистрация и оформление заказа ВСЕГО

10,47

0,31

1,11827

0,00186

18,21

0,03394

6,9

0,90

3,19353

0,00532

6,36

0,03385

0,70

2,49217

0,00415

4,96

0,02060

100

Нет данных

2,81

10,00

Нет данных

Действия

0,1 1 601

Г1

си

го Си

^О

Оценка эффективности US-уровня посредством ТСА

281

Выполнение ТСА-сценариев «что, если» На этом этапе методики мы можем выполнить сценарии «что, если», которые обсуждались ранее. Если вы хотите определить влияние увеличения количества пользователей, выполняющих действие «Добавление в корзину», на общие расходы на транзакции на сайте в секунду и в конечном итоге на пропускную способность вашего сайта, просто соответствующим образом измените профиль пользователя, увеличив вдвое или более стандартное отклонение. На этапе 1 мы рассчитали, что стандартное отклонение для операции «Добавление в корзину» равно 1,5%. Следовательно, увеличение результативности этой операции, равное 2 стандартным отклонениям, означает, что на операцию «Добавление в корзину» теперь приходится 10,47% + (2*1,5%) = 13,47% трафика нашего Web-приложения. Если мы увеличим нагрузку на эту операцию, то соответственно нам придется уменьшить нагрузку на другие операции, Для данного примера предположим, что пользователи, увеличившие активность для операции «Добавления в корзину», уже нашли то, что искали, и, следовательно, просматривают меньше других товаров. Следовательно, мы уменьшили результативность просмотра на 3% и соответствующим образом увеличили результативность операции «Добавление в корзину». Общее влияние на затраты при увеличении нагрузки на нашу самую дорогостоящую операцию описано далее в табл. 9-6: Как видно из табл. 9-6, увеличение результативности для сценария «Добавление в корзину» привело к незначительному увеличению общей стоимости каждого действия пользователя в секунду с 0,11601 до 0,12227 мегациклов. На первый взгляд это незначительный прирост, но обратите внимание, как он повлияет на общую пропускную способность сайта на этапе 4,

Этап 4: оценка пропускной способности сайта На этапе 4 ТСА рассчитывается стоимость ресурсов оборудования (в нашем случае — загрузка процессора) по отношению к уровням одновременных подключений. Начните с составления таблицы, аналогичной табл. 9-7. Для нее необходимо взять значение стоимости на каждую пользовательскую операцию в секун-

Табл. 9-6. Стоимость действия пользователя в сек. (в мегациклах) для IBuySpy Средняя результативность (профиль пользователя), %

Просмотр товаров

Мин. ASPстраниц

Норм, профиль пользователя

Действия (профиль пользователя)

Профиль пользователя, операции вс

Стоимость/ Стоидействие мость/с

58,49

0,58

2,03883

0,00340

4,80

0,01632

Поиск

14,14

0,28

1,00684

0,00168

6,02

0,0101

Добавление в корзину

13,47

0,31

1,40860

0, 00235

18,21

0,03394

Регистрация и оформление заказа

6,9

0,9

3,19353

0,00532

6,36

0,03385

Подключение и оформление заказа

0,7

2,49217

0,0041 5

4,96

0,02060

ВСЕГО

100

Нет данных

2,81

Нет данных

Действие

0,12227

? fa со

ЧО

Оценка эффективности US-уровня посредством ТСА

283

ду, рассчитанное на этапе 3, и умножить его на предполагаемое количество одновременных подключений к Web-приложению. Средние данные о пропускной способности для профиля пользователя При расчете максимальной пропускной способности назначьте допустимый максимальный уровень для серверного ресурса (процессора, диска или памяти). В данном случае был выбран процессор. Как уже упоминалось з разделе, посвященном этапу 2, не следует допускать, чтобы сервер работал при загрузке процессора 100%. Для расчета пропускной способности сайта мы установим максимальную загрузку процессора для двухпроцессорного IISсервера равной 85%. При этом значение максимально доступного ресурса процессора составит 2 000 мегациклов * 83% = 1 700 мегациклов. В табл. 9-7 показан диапазон пропускной способности для одновременных подключений при использовании двухпроцессорного сервера IIS с тактовой частотой 1000 МГц относительно одновременных подключений. В табл. 9-7 показано, что максимальная пропускная способность нашего сервера IIS IBuySpy равна 14 654 пользователям при стоимости 1700,01 мегациклов. Это максимальное ограничение, поскольку 2 процессора с теоретически максимальной загрузкой 85% обеспечивают сайту пропускную способность в 1700 мегациклов. Для повышения пропускной способности при существующем оборудовании нам понадобится снизить расходы серверного процессора для более дорогостоящих операций — «Добавление в корзину» и «Регистрация и оформление заказа». Табл. 9-7. Данные по пропускной способности IBuySpy Одновременные подключения

Стоимость

14 300 Н 400 14 500 14 600 14 654

1658,94 1670,54 1682,15 1693,75 1700,01 (максимально доступные ресурсы процессора) 1705,35 1716,95

14 700 14 800

Глава 9

284

Данные о пропускной способности для сценария «что, если» при увеличении трафика для «Добавления в корзину» На этапе 3 мы показали, как увеличение активности среднестатистических пользователей для действия «Добавление в корзину» на 2 стандартных отклонения повлияло на общую стоимость операции в секунду. В результате стоимость увеличилась с 0,11601 до 0,12227 мегациклов. Насколько именно это небольшое изменение трафика, равное 3%, влияет на общую пропускную способность сайта? В табл. 9-8 показаны данные о пропускной способности при более высоких расходах на среднестатистического пользователя. Табл. 9-8. Данные по пропускной способности IbuySpy Одновременные подключения

Стоимость

13 500

1650,65

13 600

1662,87

13 700

1675,10

13 800

1687,33

13 903

1700,04 (максимально доступные ресурсы процессора)

14 000

1711,78

14 100

1724,01

Как показано выше, увеличение активности действия пользователя «Добавление в корзину» на 2 стандартных отклонения или на 3% снизили максимальный уровень одновременных подключений на наших серверах IIS с 14,654 до 13,903. Это произошло по причине небольшого изменения в распределении активности среднестатистического пользователя, причем для получения этих данных потребовалась только небольшая корректировка нашей модели. Сценарий «что, если» позволил показать значение ТСА для экономии времени. Теперь, когда мы довели до конца нашу модель ТСА, мы можем перераспределить пользовательский трафик сайта и выяснить возможное влияние на общую пропускную способность сайта. Если вы сравните время, необходимое для проведения ТСА, со временем, требуемым на проведение дискретных нагрузочных тестов для получения тех же данных по пропускной

Оценка эффективности US-уровня посредством ТСА

285

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

Этап 5: проверка пропускной способности сайта Последний этап проведения ТСА — проверка пропускной способности сайта при помощи нагрузочных тестов, результаты которых отражают распределение трафика и длительность сессии. Затем следует сравнить расходы на использование ресурсов, получаемые из этих тестов, с прогнозируемыми средствами модели ТСА. Действительные значения использования тестируемых ресурсов и прогнозы модели ТСА по ресурсам ограничьте возможной погрешностью. Цель данного этапа — подтвердить прогнозы модели ТСА о пропускной способности сайта. Не обязательно запускать контрольный тест для каждого уровня нагрузки. В общем-то, это сделало бы бессмысленным использование ТСА для прогноза использования ресурсов для различных уровней одновременных подключений. Мы советуем провести всего один тест, но тот, что позволит вам окончательно убедиться в прогнозах ТСА. Чтобы подтвердить нашу модель ТСА для IBuySpy, мы провели пять контрольных тестов в большом диапазоне уровней одновременных подключений. Результаты контрольных тестов для IBuySpy были получены с помощью тех же сценариев нагрузочных тестов, которые мы создали на этапе 2. Однако все их запустили одновременно. Кроме того, поскольку для нашей модели использовалась сессия продолжительностью 10 минут, наши проверочные сценарии включали 10-минутные периоды режима бездействия. Это означает, что каждому сценарию требуется 10 минут для совершения действий с IBuySpy, столько же, сколько необходимо среднестатистическому пользователю. В главе 3 более подробно описаны режимы бездействия в нагрузочных сценариях. На рис. 9-2 показаны результаты контрольных тестов для IBuySpy. Анализируя результаты контрольного теста, мы обращаем особое внимание на то, что расхождение в прогнозированных и полученных мегациклах не превышает 10%. Также необходимо проверить, что наши ASP-сценарии выполняются при соблюдении параметров максимальной задержки в 2 секунды. Результаты в

286

Глава 9

табл. 9-9 подтверждают, что каждый тест прекрасно укладывается в предел погрешности 10%. При проведении контрольных тестов не забывайте отслеживать средние ASP-задержки, превышающие 2 секунды. Как показано в табл. 9-9, в ходе наших проверочных тестов ASP-задержка не относится к числу факторов, ограничивающих пропускную способность. Общее количество мегациклов процессора » 2000

1000

100

200 1000 10000 14653 Одновременные подключения к IBuySpy

"] Прогнозируемые мегациклы Щ Полученные мегациклы

Рис. 9-2. Результаты контрольного теста Табл. 9-9. Проверка IBuySpy Одновременные подключения

Прогнозируемые мегациклы

Полученные мегациклы

Время ожида-

Время исполне-

Время задержки

ния ASP, мс

ASP, мс

100 200

11,60 23,2

11,54 23,8

0,238 0,769

1000 10000 14653

116,01 1160 1699

120,19 1147 1661

4,301 5,863 7,99

27,203 39,98

4,063 5,094 6,09 52,441 72,47

79,644 111,45

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

Оценка эффективности IIS-уровня посредством ТСА

287

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

Заключение Расчет одновременных подключений к сайту — это и искусство, и наука. Анализ активности на сервере, являющейся результатом деятельности различных пользователей, необходим для оценки часто встречающегося неправильного понимания термина «одповременные подключения». Тем не менее владельцам сайта приходится рассчитывать и максимально необходимый уровень пропускной способности оборудования сайта, чтобы быть готовым к экстраординарным всплескам трафика. ТСА — это научная методика для расчета необходимого уровня пропускной способности Web-приложения. Она состоит из пяти этапов: 1. создания профиля пользователя; 2. нагрузочного тестирования для определения затрат на транзакции; 3. расчета стоимости аппаратных ресурсов для каждого действия пользователя; 4. использования стоимости транзакций для прогнозирования потребностей Web-приложения в аппаратных ресурсах; 5. проверки точности модели ТСА. ТСА позволяет понять, как различные трафики Web-приложения влияют на необходимость уровень пропускной способности оборудования, а это в свою очередь, необходимо, чтобы более продуманно приобретать оборудование и при этом значительно сократить расходы компании.

Глава 10

производительности Анализ стоимости транзакции (Transaction Cost Analysis, TCA) представляет собой научный метод определения пропускной способности сервера: сначала выдвигается гипотеза, а затем для определения достоверности ожидаемых результатов прозодится эксперимент с существующим оборудованием и действительными или прогнозируемыми данными. Используя этот метод, планирование пропускной способности и оценку существующих систем в режиме реального времени можно выполнить с приемлемой достоверностью. Если для тестирования доступны данные об использовании, оборудование и сетевые ресурсы, методика ТСА также годится для прогноза изменения нагрузки и стоимости, а также для того, чтобы определить допустимые изменения с целью повышения производительности или снижения затрат, Если рабочая нагрузка сервера увеличилась до точки падения производительности, считается, что следует добавить ресурсы: дополнительная производительность процессора увеличит быстродействие. Несмотря на то, что это решение зачастую оказывается дорогостоящим, обычно это не считается большой проблемой. Система, достигшая предела производительности, как правило, приносит доход, или, как минимум, демонстрирует наличие высокого трафика. На первый взгляд расходы на оборудование оправданы, и его установка редко требует значительной перенастройки компонентов серверного ПО. Предполагается,

Моделирование: инструменты прогноза производительности 289 что перерыва з обслуживании пользователей не произойдет, возможно только уменьшение времени отклика. Однако подобное решение почти повсеместно осложняет работу программистов и сетевых администраторов, поскольку добавлением физических ресурсов не всегда удается устранить действительную проблему. Представьте себе сервер электронной коммерции, на котором заказы обрабатывается слишком долго и где появляются ошибки при размещении заказов отдельными пользователями. Специалисты по информационным технологиям в первую очередь предположат, что загрузка процессора близка к максимуму и задержка возникает из-за недостатка аппаратных ресурсов. Однако причина падения производительности может крыться в серверном приложении, если, например, приложение для обработки заказа было разработано только для определенного количества одновременных транзакций по вводу заказов. Если эти данные о приложении не использовались в ТСА-оценке, то в результатах ТСА не будет отражен тот факт, что увеличение скорости процессора никак не влияет на проблему.

Прогнозирование и оценка производительности с помощью ТСА ТСА имеет большое значение при оценке существующих систем и тонкой настройке посредством изменений в коде или модернизации оборудования. Легко делать прогнозы, просто изменяя параметры в электронной таблице Excel. Проведя ТСА-оценку предыдущей и новой версий программного обеспечения, как, например, описано во врезке к главе 9 «Реальный пример Shop.Microsoft.com», вы получаете количественные оценки изменений. ТСА позволяет оценить систему в целом, включая и оборудование, и программное обеспечение. Однако по причине зависимости от реальных или спрогнозированных данных и отклика системы этот метод оценки производительности не дает немедленных результатов. Если для общей архитектуры серверной системы требуется внести несколько изменений для повышения производительности,

290

Глава 10

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

Усложненное моделирование производительности Для решения этой проблемы необходим более изощренный метод моделирования производительности. Его цель — тестирование многочисленного оборудования и конфигураций сетевых ресурсов без обязательного присутствия всех ресурсов. Это позволит компании проводить продолжительные тесты, включая сценарии «что, если» для того, чтобы принять решение о приобретении физических ресурсов. Различия этих двух методов видны по их конечным результатам. Тесты ТСА определяют данные и существующие ресурсы для точки спада, определяющей физические пределы системы. Усложненное моделирование производительности оценивает возможные варианты конфигурации с большим количеством переменных, этот метод позволяет не только спрогнозировать физические пределы системы, но и заранее определить возможные улучшения — до того, как эти пределы будут достигнуты. Моделирование производительности также позволяет специалистам по программному обеспечению проводить тесты моделей своего кода до создания реального кода. Для этого следует определить назначение программы с помощью такого языка, как Universal Modeling Language (UML) — отраслевого стандарта формального описания системы.

Моделирование: инструменты прогноза производительности

291

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

Технология моделирования производительности Одна из целей моделирования производительности — проверить систему полностью, от оборудования и сетевых ресурсов до оптимизации кода, перед объявлением о готовности любого отдельного компонента. В этом разделе мы обсудим: • сценарии, использование которых для моделирования производительности может заменить другие методы оценки оптимизации производительности; • различные методы моделирования и случаи, когда их следует использовать; • краткий обзор инструментов моделирования производительности, доступных в настоящее время; • подробный обзор методов, в которых применяется инструментарий, представленный в проекте Indy компании Microsoft.

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

292

Глава 10

та, практически сразу начинается процесс улучшения доступных ресурсов. Простым добавлением оборудования, как уже говорилось во вводном примере, не всегда удается увеличить пропускную способность, а значит, производительность все-таки падает, а вместе с ней и прибыли компании. Результаты ТСА при планировании пропускной способности оказываются очень точными, если, прежде всего, данные в структуре ТСА точны. Однако их проверка все равно необходима, и, возможно, потребуются и дополнительные затраты для подтверждения спрогнозированных результатов. Более детальное определение пользовательской загрузки, оборудования и компонентов программного обеспечения системы позволит ликвидировать этап подтверждения и отыскать альтернативные способы повышения пропускной способности до того момента, когда они станут насущно необходимы. Анализ «узких» мест Оценка системы, которая неожиданно достигла пика, притом что модернизация оборудования не приносит результатов, оказывается трудным и неблагодарным делом. При использовании моделирования производительности для подробного описания каждой транзакции и связанных с ней требований к оборудованию удается выявить «узкие» места. Чтобы не допустить спада производительности, моделирование также рекомендуется применять для тестов с более высокой нагрузкой системы, что позволит спрогнозировать появление нехватки ресурсов, одновременно при этом показывая способы решения проблемы еще до ее появления. Конфигурация оборудования С помощью подробных моделей производительности можно очень точно спрогнозировать поведение предложенной модернизации оборудования, используя счетчики производительности и имитацию транзакций на виртуальном оборудовании. На вопрос, стоит ли тратить деньги на модернизацию двухпроцессорного сервера, добавляя еще два процессора, стоит все-таки применять метод моделирования производительности — для этого достаточно несколько раз щелкнуть мышью, — а не метод проб и ошибок.

Моделирование: инструменты прогноза производительности 293 Оценка архитектуры Еще один способ оценить производительность двух полностью различных архитектур — реализовать оба варианта и проверить действительные результаты. Однако это трудно сделать, когда приходится обслуживать множество клиентов. И затраты, и время становятся препятствием. ТСА предусмотрен для проведения расчетов, относящихся ко всей системе, на основе данных об аппаратной и сетевой архитектуре, но данная методика все еще требует проверки. По этой причине моделирование производительности поможет снизить как время, так и затраченные средства для оптимизации архитектуры с помощью различных уровней детализации в зависимости оттого, на какие архитектурные вопросы необходимо дать ответы. Пользовательские сценарии ТСА — это простой и эффективный инструмент, который позволяет проверить, что произойдет при увеличении пользовательской нагрузки на определенную систему. Но отследить эффект от изменений в обычном поведении пользователя с помощью ТСА гораздо труднее. Моделирование производительности дает возможность тестировать различные сценарии поведения пользователя, работая с моделями его дейспзий, а не с: реальными или заимствованными моделями данных.

Методы моделирования производительности Существуют три основных метода моделирования для прогнозирования, оценки и трактовки производительности в процессе создания системы: аналитический, статистический и имитационный. Чтобы верно выбрать метод для определенного задания, крайне важно понимать требования и результаты каждого из них. Аналитическое моделирование В процесс аналитического моделирования входит использование математических выражений, описывающих взаимодействия в системе. Для представления архитектуры системы используются такие математические нотации, как сети очередей и сети Петри. Обычно каждый компонент модели независимо от того, представляет ли он аппаратное устройство, сетевую транзакцию, фрагмент кода программного обеспечения или действие пользо-

294

Глава 10

вателя, представлен в основной системе в математических выражениях. Сложные уравнения, отражающие взаимодействия между этими компонентами, разрабатываются и затем решаются для определения намеченного значения определенной переменной в модели. Например, если у вас есть Web-сервер, передающий Интернетклиентам только простые HTML-страницы, то вам необходимо собрать информацию о конфигурации оборудования сервера (процессор, скорость диска и использование памяти), передаваемом содержимом (включая объем HTML, изображений и других элементов Web-страниц), пропускной способности сети на сервере (действительную величину полосы пропускания, доступную серверу) и различных сценариях действий клиентов (включая ситуации с высокой и низкой загрузкой и различной скоростью сетевых соединений на уровне клиента). Имея эти данные, вы проведете экстраполяцию с учетом всех элементов, непосредственно относящихся ко времени и к использованию ресурсов. В составленное контрольное уравнение {которое можно представить в виде электронной таблицы со встроенными расчетами) подставляют значения различных элементов — это позволит зам проследить, как это влияет на другие элементы, входящие в уравнение. Описанный способ и есть основная методика ТСА. Зная варианты типичного поведения системы и возможные изменения в поведении пользователя или в конфигурации оборудования (при условии, что значения данных были изменены таким образом, чтобы отражать пропускную способность нового оборудования и время отклика), вы с помощью ТСА прогнозируете производительность системы. Аналитический подход дает первоначальный прогноз производительности новых систем, но обычно его результаты распространяются на ограниченный набор сценариев «что, если». Для математического описания наиболее сложных вариантов, влияющих на производительность системы, таких, как задержка очереди и конкуренция ресурсов, необходима соответствующая основательная экспертиза специалиста по производительности.

Моделирование: инструменты прогноза производительности 295 Статистическое моделирование Статистическое моделирование основано на известных показателях производительности существующих систем. Вы можете использовать эти данные как основу для прогнозирования поведения новой, еще не созданной системы. Для этого достаточно проанализировать измеренные данные такими методами, как регрессивный анализ. Затем полученные статистические модели применяются для экстраполяции производительности системы в новой конфигурации. Например, у компании, специализирующейся на хостинге, может быть несколько работающих серверов электронной коммерции. Длл того чтобы порекомендовать новому клиенту оборудование и пропускную способность сети, следует проанализировать объединенные статистические данные по всем работающим серверам и выдать рекомендации: либо использовать подобные оборудование и полосу пропускания, либо применить иные элементы в новой системе большей производительности. Как и при любом статистическом анализе, точность окончательных расчетов увеличивается вместе с размером существующих данных. По этой причине в компании, специализирующейся на хостинге, стоит сначала измерить производительность нескольких систем, прежде чем перейти к среднестатистической модели. Одно из препятствий для использования статистического анализа в оптимизации производительности — недостаток либо количества, либо разнообразия существующих данных. Просматривая публикуемую статистику сайта со схожими характеристиками, компания-конкурент, специализирующаяся на электронной коммерции, получит ценные статистические данные о количестве посетителей и характере их трафика, но, скорее всего ничего не найдет об оборудовании сайта и пропускной способности сетевых соединений или о применяемом программном обеспечении. В этом случае для точной оценки производительности необходимо использовать сочетание статистических и аналитических моделей (вспомним ситуации, когда ТСА применяется для прогнозирования поведения новой службы). В статистические модели включены предположения о том, как именно экстраполируется производительность. Например, специ-

296

Глава 10

алист по производительности предполагает, что загрузка процессора увеличивается линейно вместе с нагрузкой. Хотя, возможно, это и верно для полученных измерений производительности, поведение загрузки процессора изменяется при насыщении. Избежать таких подводных камней удается только опытным путем. Имитация Известно два способа имитации. В первом случае создается предложенная система, и для оценки производительности ее подвергают имитационным образцам нагрузки. Точность моделирования при этом можно сравнить только с данными, полученными практическим путем, поскольку в качестве инструментария при тестировании используется реальное оборудование и программное обеспечение. Кроме того для генерации нагрузки стоит использовать такие коммерчески доступные инструменты генерирования трафика, как ACT. При проведении нагрузочного теста реальной системы удается не только обнаружить проблемы с производительностью, но и оценить результаты падения производительности. Представьте себе серверное приложение, которое обрабатывает телефонные звонки для системы IP-телефонии. Диапазон его требований к производительности — от самого быстрого времени отклика процессора до 100-процентной доступности полосы пропускания сетевого соединения, поскольку оно должно завершить все свои запросы к телефонной сети в пределах 20Омиллисекундного промежутка времени. Такая система способна безупречно работать при минимальной пользовательской нагрузке, но увеличение нагрузки, которое либо создаст очередь процессора, либо сетевой затор, сделает недоступной телефонную службу для ее пользователей. Моделируя нагрузку по обработке звонков на реальной системе до реализации, вы определите реальные ограничения системы и избежите перегрузки, установив строгие ограничения количества клиентов, использующих этот сервер для обработки своих звонков. Этот тип моделирования позволяет достичь точных результатов, но оборотной стороной является то обстоятельство, что все улучшения необходимо производить в завершенной или почти завершенной системе. В предыдущем примере единственный способ

Моделирование: инструменты прогноза производительности

297

избежать сбоев в работе служб на существующем сервере, обрабатывающем звонки, — ограничить возможное количество пользователей, обслуживаемых одновременно. В качестве альтернативы системные инженеры могли протестировать другие конфигурации оборудования или программного обеспечения, но для этого потребовались бы затраты на ресурсы или переписывание кода. Второй способ имитационного моделирования подразумевает создание программного обеспечения, которое точно представляет поведение аппаратных устройств и использование других программных инструментов для обработки существующего кода или смоделированного поведения программного обеспечения (такого, как UML) с помощью имитации аппаратных устройств. Таким образом исключаются затраты на оборудование, связанные с имитацией только загрузки системы, но при этом иногда требуется много времени, если специалисту по производительности необходимо разработать концепцию и приложения для имитации с нуля. Усложненное моделирование производительности V каждого метода моделирования есть свои достоинства и недостатки. На практике необходимо сбалансировать качество результатов тестирования со временем и затратами на его проведение. Такие инструменты усложненного моделирования производительности, как, например, Indy, о котором речь пойдет далее в этой главе, объединяют эти метода, демонстрируя гибкость и масштабируемость при низких затратах.

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

298

Глава 10

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

Indy: инфраструктура технологии оценки производительности В этом разделе для сравнения результатов, полученных с помощью ТСА (из предыдущей главы) и более усложненных видов моделирования производительности, мы воспользуемся примерами из проекта моделирования производительности под названием Indy. Indy разработан Microsoft для решения проблем производительности путем создания инфраструктуры технологии оценки производительности. Моделирование производительности многогранно, разные инструменты моделирования предъявляют различные требования к уровню детализации, техническому подходу к моделированию и потребителям. Ни один инструмент моделирования или статическое приложение не способно отвечать всем требованиям. Однако применение инструментария (набора инструментов) позволяет создавать специализированные инструменты из основной инфраструктуры вместе с нестандартными компонентами. Этот подход также допускает произвольный уровень сложности для этих инструментов и моделей. Таким образом, на простой вопрос: удается ответить быстро, а важный компонент системы — тщательно протестировать.

Концепции Indy В Indy для моделирования производительности используется имитационный подход, с аналитическими методами для повыше-

Моделирование: инструменты прогноза производительности 299 ния эффективности. При этом используются внутренние модели каждого из основных устройств моделируемой системы и имитируется поведение и взаимодействие этих устройств. После имитации производительность каждого устройства рассматривают очень подробно. Indy поставляется вместе со стандартной библиотекой моделей устройств. Каждая модель в свою очередь может иметь подмодели. Таким образом, модель Indy для фермы серверов представляет собой, например, различные модели серверов, объединенные моделью сети. Модели серверов в свою очередь состоят из моделей своих процессоров, дисков и сетевых интерфейсов. Затем экземпляры этих моделей оборудования объединяют в топологию системы, совпадающую с конфигурацией оборудования настоящей группы серверов. Рассматривая модель конфигурации системы, необходимо смоделировать для нее входную нагрузку (часто ее называют рабочей нагрузкой). Например, рабочая нагрузка на модель Indy для сайта электронной коммерции определяется тем, как часто на нее поступают запросы для различных страниц и действий на сайте. И, наконец, следует смоделировать, как различные компоненты системы будут реагировать на рабочую нагрузку, то есть надо определить поведение системы. Indy предлагает для этого несколько способов, но в данном случае мы сосредоточимся на языке сценариев на основе XML, который называется Transaction Modeling Language (TML). Сценарий TML определяет транзакции, которые будет поддерживать Web-сайт, в терминах действий их компонентов (таких, как вычисления, дисковые операции или сетевой трафик) и на каких устройствах эти действия будут выполняться.

Архитектура Indy На рис.10-1 показана архитектура Indy и его основные компоненты. Ядро В самом сердце Indy находится ядро, взаимодействующее и управляющее другими компонентами с помощью четко определенного API. Во всех инструментах, созданных с помощью инструментария Indy, должно присутствовать ядро. В него входит цен-

Глава 10

300

тральный механизм оценки, необходимый для выработки результатов имитации. Как уже упоминалось ранее, ядро Indy использует механизм оценки на основе событий, объединяющий прямое воспроизведение с некоторыми смешанными техническими приемами для повышения эффективности. Однако для других целей разрешается применять другие механизмы оценки, например, такой, который использует аналитические или статистические методы моделирования. и (DLL) оборудования

Библиотеки (DLL) рабочей нагрузки Определения интерфейса

Клиентские нсполняемые файлы

Рис. 10-1. Архитектура Indy Библиотеки оборудования Библиотеки оборудования реализуют модели отдельных устройств системы, таких, как процессоры и диски. Существуют библиотеки различных моделей, дополнительные модели легко добавляются. Для отдельного устройства иногда доступно несколько моделей, которые различаются тем, насколько детально в них рассматривается производительность модели. Подробная модель позволяет получить более точные результаты; а также учесть больше параметров, влияющих на производительность.

Моделирование: инструменты прогноза производительности

301

Однако во время исполнения для нее требуется больше информации, и при ее применении имитация занимает больше времени. Библиотеки рабочей нагрузки Библиотеки рабочей нагрузки предназначены для определения и воспроизведения событий при отдельной имитации. Как видно из рисунка, можно использовать различные библиотеки рабочей нагрузки. В этой главе мы расскажем о библиотеке рабочей нагрузки, которая интерпретирует сценарии TML для создания рабочей нагрузки. Другую библиотеку рабочей нагрузки применяют для интерпретации диаграмм UML или создания нестандартной рабочей нагрузки для специализированного инструмента. Определения интерфейса Информация о конфигурации других компонентов сохраняется ядром в метакаталоге. Например, различные версии одного основного диска могут использовать одинаковую модель оборудования, но с разными характеристиками производительности. Подобным же образом характеристики производительности, такие, как частота транзакций или вызванный ими объем сетевого трафика, разрешается корректировать, не переписывая код библиотеки рабочей нагрузки или сценария TML. Клиентские исполняемые файлы Клиентские исполняемые файлы объединяют ядро, библиотеки оборудования и рабочей нагрузки, а также метакаталог с соответствующим пользовательским интерфейсом. В рабочей среде можно экспортировать данные об имитации в электронную таблицу Excel или базу данных SQL. Однако в этой главе мы поговорим о графическом интерфейсе IndyView. Он предназначался специалистам по производительности, которым требовался более детальный доступ к информации о моделировании Indy. Примеры результатов мы покажем далее в этой главе.

IndyView Этот раздел посвящен элементам интерфейса IndyView, которые были использованы для оценки модели производительности Webсайта IBuySpy. Мы также рассмотрим соответствующий XML-код, применяемый для представления особенностей модели.

302

Глава 10

Топология системы Рассмотрим простую конфигурацию Web-сайта IBuySpy, показанную на рис.10-2. Локальная сеть

Сервер IIS

5Р

SQL сервер

Интернет

Удаленные клиенты

Рис. 10-2. Физическая топология Web-сайта на типичном примере IBuySpy Система состоит из сервера IIS и сервера SQL (вместе они и составляют Web-сайт IBuySpy), соединенные друг с другом через локальную сеть. Сервер IIS также соединен с Интернетом и обрабатывает запросы от удаленных клиентов. На рис.10-3 показан пример того, как эта простая топология для Web-сайта IBuySpy представлена с помощью интерфейса IndyView. Обратите внимание, что сервер IIS (iissrv) включает такие устройства, как сетевые карты и процессоры. Устройства, имеющие идентичные функции могут быть представлены как группа устройств. В сервер SQL (sqlsrv) входит сетевая карта, процессор и дисковые устройства. Хотя совершенно очевидно, что у настоя-

Моделирование: инструменты прогноза производительности 303 щего сервера 115 также есть жесткий диск, его производительность никак не влияет на тестируемую модель, и поэтому его не учли.

Рис. 10-3.

Топология Indy примера Web-сайта IBuySpy

На устройстве sqlsrv, ниже заголовка CPU x 2, имеются еще два устройства: счетчик производительности процессора и устройство CpuModel:Pentium 1000МГц, определяющие поведение этого конкретного типа процессора, в том числе и скорость его работы. Аналогично, ниже заголовка Disk x 1 расположен счетчик производительности диска и устройство DiskModel: HP NetRAID-4M, для которых заданы скорость доступа и другие факторы производительности. Для измерения производительности здесь не обязательно детально описывать конфигурацию оборудования клиента. Следовательно, клиентское устройство — это просто «черный ящик»; при транзакциях на него ссылаются как на запрашивающий или получающий данные. Устройства net и Ian, расположенные на том же иерархическом уровне, что и оба сервера, представляют свойства сете-

304

Глава 10

вых соединений соответственно для сегментов Интернета и локальной сети. Наконец, связи между каждым устройством компьютера и сетевым устройством подробно описаны, включая и то, какой интерфейс на каждом компьютере соединяется с отдельным сетевым устройством. Это позволит различить выходные результаты теста и активность различных устройств в момент транзакции. Следующий XML-код описывает диаграмму на рис.10-3: <?xml version="1.О" encoding="utf-8"?> <system name="IBuySpy"> <active_device type="computer" name="iissrv" count="1"> <active_device type="generic" name="lan_nic_send" count="1"/> <active_device type="generic" name="lan_nic_recv" count="1"/> <active_device type="generic" name="net_nic_send" count="1"/> <active_device type="generic" name="net_nic_recv" count="1"/> <active_device type="cpu" name="cpu" count="2"> <rct name="cpu"/> <use_template name="CpuModel:Pentium 1000MHz"/> </active_device> </active_device> <active_device type="computer" name="sqlsrv" count="1"> <active_device type="generic" name="lan_nic_send" count="1"/> <active_device type="generic" name="lan_nic_recv" _ count="1"/> <active_device type="cpu" name="cpu" count="2"> <rct name="cpu"/> <use_template name="CpuModel:Pentium 1000MHz"/> </active_device> <active_device type="generic" name="disk" count="1"> <rct name="disk"/> <use_template name="DiskHodel:HP NetRAID-4M"/> </active_device> </active_device> <open_device name="client"/> <passive_device type="network" name="net" ports="100"> <use_template name="NetHode!2:OptifnumCapacity"/> </passive_device> <passive_device type="network" name="lan" ports="100">

Моделирование: инструменты прогноза производительности 305 <use_template naroe="LanModel :Ethernet"/> </passive_device> <link active="client" passive="net" fromport="0" toport="0"/> <link active="iissrv[?].2" passive=" net" fromport="0" toport="99"/> <link active="iissrv[?].3" passive=" net" fromport="0" toport="99"/> <link active="iissrv[?].0" passive=" Ian" fromport="0" toport="99"/> <link active="iissrv[?].1" passive= Ian" fromport="0" toport="99"/> <link active="sqlsrv[?].0" passive= Ian" fromport="0" toport="99"/> <link active="sqlsn/[?],1" passive= Ian" fromport="0" toport="99"/> </system> Устройства, на которые ссылается TML-код, определены в метакаталоге конфигураций оборудования. При изменении основных свойств одного из этих устройств разрешается использовать этот же сценарий для тестирования различных параметров архитектуры. В то же время количество устройств можно изменять для проверки влияния на производительность таких факторов, как количество процессоров на сервере. Транзакция поиска вIBuySpy После создания нашей топологии можно определить, какие транзакции она будет поддерживать. Вот простой пример транзакции, написанной на TML для моделирования запроса и обработки страницы поиска в IBuySpy; <tml>

<!- BasicSearch Запрос aspx-файла и затем двух gif-файлов

306

Глава 10 <action name="net_msg_async_sync" connection="net" service="IIS" useserver="iisstate"> <param name="linkspeed" value="transaction.ClientSpeed" /> <param name="msgsize" value="BasicSearchSize" /> <!-- только размер страницы aspx -> <peer name="target" service="Client" useserver="clientstate" /> </action> <fork> <branch> <action name="net_msg_sync_async" connection="net" service="Client" saveschedule="clientstate"> <param name="linkspeed" value="transaction.ClientSpeed" /> <param name="msgsize" value="HttpRequestSize" /> <peer name="target" service="IIS" saveschedule="iisstate" /> </action> <action name="net_msg_async_sync" connection="net" service="IIS" useserver="iisstate"> <param name="linkspeed" value="transaction.ClientSpeed" /> <param name="msgsize" value="0.04" /> <!- 1x1.gif -> <peer name="target" service="Client" useserver="clientstate" /> </action> </branch> <branch> <action name="net_msg_sync_async" connection="net" service="Client" saveschedule="clientstate"> <param name="linkspeed" value="transaction.ClientSpeed" /> <param name="msgsize" value="HttpRequestSize" /> <peer name="target" service="IIS" saveschedule="iisstate" /> </action> <action name="net_msg_async_sync" connection="net" service="IIS" useserver="iisstate"> <param name="linkspeed" value="transaction.ClientSpeed" /> <param name="msgsize" value="1,52" /> <!- thumbs/ image.gif -> <peer name="target" service="Client" useserver="clientstate" /> </action> </branch>

Моделирование: инструменты прогноза производительности

307

</fork> </transaction>

Определение транзакции начинается с имени и относительной частоты транзакции. Затем действия транзакции перечисляются в том же порядке, в котором они происходят. В сценарии в этом примере, отдельные действия (каждое из которых начинается со action и заканчивается /action) таковы. 1. net_msg_sync_async: Отправить сообщение с HTTP-запросом из клиентской службы (представляющей все возможные компьютеры клиентов в Интернете) в службу IIS через Интернет, используя для скорости связи и размера сообщения изменяемые параметры. Сообщение отправляется синхронно (т. е. клиент ждет отклика), но принимается асинхронно (сервер может обрабатывать множество одновременных запросов}. 2. compute: Обработать HTTP-запрос на сервере IIS, при этом число необходимых операций процессора различно для разных запросов, 3. net_msg_async_sync: Отправить сообщение обратно из службы IIS в клиентскую службу через Интернет, используя изменяемые параметры скорости связи и размера сообщения. Если мы посмотрим на комментарии, то увидим, что значение BasicSearchSize совпадает с размером страницы ASPX, что означает, что переменная BasicSearchSize была ранее определена как параметр рабочей нагрузки, содержащий сетевой размер ASPX-файла. Затем эту переменную вы сможете легко изменить из IndyView. 4. Далее сценарий имеет две ветви, которые будут исполнены одновременно. Первая ветвь, содержащая действия net_msg_sync_async и net_msg_async_sync, отправляет запрос и получает ответ в виде GIF-файла (в комментариях он называется 1x1.gif) размером 0,04 кбайт. Вторая ветвь, содержащая действия net_msg_sync_async и net_msg_async_sync, отправляет запрос и получает ответ в виде

Глава 10

308

GIF-файла (з комментариях он называется thumbs/image.gif) размером 1,52кбайт. Явное кодирование значений параметров при таком способе приводит к тому, что сценарий приходится редактировать при изменении хотя бы одного значения. Для параметров, значения которых пользователи меняют довольно часто, мы советуем применять переменную рабочей нагрузки, как, например, для размера ASPX-страницы и затрат процессора. Перейдем к другому уровню детализации, чтобы посмотреть, какая информация встроена в одно из определений службы в сценарии: <service name="IIS"> <serverlist> <server name="iissrv" /> </serverlist> <actionscheduling>

<schedule action="compute" policy="roundrobin"> <target device="cpu" /> </schedule> <schedule action="net_msg_async_sync" connection="net" policy="random"> <target device="nic_send" /> </schedule> </actionscheduling> </service> Здесь видно, что для службы IIS следует использовать устройство iissrv (определенное в топологии системы). Для подустройств iissrv можно составить график действий. В этом сценарии, когда для транзакции требуется выполнение действия, целевым подустройством становится один из двух процессоров, выбираемых циклически. При выходе трафика в Интернет (сетевое устройство в сценарии топологии системы) целевым устройством будет сетевая карта, предназначенная для отправки. При обработке с помощью API ядра Indy, которое использует определения устройств в топологии системы, IndyView создает несколько различных визуальных представлений транзакции как целого или концентрируется на отдельных устройствах и на том, какое влияние на них оказывалось в потоке транзакции. Рис.10-4,

Моделирование: инструменты прогноза производительности 309 10-5, 10-6 и 10-7 — они все были созданы при использовании модели Web-сайта IBuySpy.

Рис. 10-4. Управляющая логика транзакции основного поиска После определения транзакции в TML мы можем использовать IndyView для ее визуализации с помощью диаграммы хода транзакции, как показано на рис.10-4. Этот простои просмотр позволяет проверить и отладить TML; обычно он используется специалистом по производительности на стадии разработки модели. Эта диаграмма хода поиска показывает порядок и зависимости каждого действия в транзакции. В последовательность действии входят; запрос клиентом Web-сервера, вычисления на Web-сервере, ответ от Web-сервера клиенту и затем параллельное получение двух изображений клиентом. Если щелкнуть одно из действий на диаграмме, то откроется окно, где будет предоставлена более подробная информация. На рис. 10-4 одно окно — это сообщение от сервера для клиента (на заднем плане), а другое — это вычисление на процессоре iissrv (на переднем плане}.

310

• ,ав,

.-в^-^.

•

*---

tl9>nifOOIIO].Nt4 llt*IVfiV>ll|>|.l>ro5

ЩЩ^Н

a Л il| . |"l 1-

оиямивтв vlattite «0136

»г

136

11*

ins

iisg

)iss

«6(

11II

117S

Рис. 10-5. Пространственно-временной анализ На рис.10-5 показано время и ресурсы, необходимые для событий, происходящих на всех устройствах системы. Этот график полезен специалисту по производительности для визуализации уровня использования отдельных устройств и определения возможных проблем с производительностью путем простой проверки детализированных событий. Время изменяется слева направо, и каждая линия представляет отдельное устройство (определенное в списке устройств слева на экране}, а события представлены полями. Карта цветов, соответствующая типу событий, показана на графике, расположенном ниже панели инструментов. Линии в окне соединяют события взаимодействия, когда оба участника взаимодействия видны в окне. Черные круги обозначают события взаимодействия, когда один участник взаимодействия не виден. Поскольку в этом просмотре клиенты не показаны, взаимодействия с ними отображены именно таким образом. Номера устройств слева заимствованы из сценария топологии. Наиболее часто используемые ресурсы на графике — это процессоры сервера IIS (iissrv[0000].0004-0005) и диск сервера SQL (sqlsrvf0000].0004).

Моделирование: инструменты прогноза производительности 311 Вместо того чтобы просматривать все события, происходящие во всей системе, мы воспользуемся средством просмотра Transaction Analysis IndyVievv, чтобы проверить, как долго длится каждое действие з отдельном экземпляре транзакции и какие ресурсы для этого необходимы (рис.10-6).

Рис. 10-6. Анализ транзакции поиска В верхней половине экрана показана управляющая логика транзакции поиска, растянутая для представления действительного времени, которое занимает каждое действие. В панели слеза отображается время запуска и имя каждой транзакции з данной имитации, что позволяет отдельно просмотреть каждую из транзакций. В нижней половине окна события, происходящие в течение выбранной транзакции, выделены зеленым цветом. На панели, которая находится слева от этого раздела, показаны устройства, которые участвуют в данной конкретной транзакции: HssrvfOOOOJ.0002, представляющее действие по отправке на сетевую карту, которая первой соединяет сервер IIS с Интернет; Hssrv[00001.0003,

312

Глава 10

представляющее действие по получению на том же сервере; и iissrvf0000].0004, представляющее первый из процессоров. Специалисту по производительности описанные информационные окна весьма пригодятся для создания и отладки модели производительности. Кроме того, дополнительные экраны IndyView полезны для оценки и анализа изменения производительности для различных сценариев. На рис.10-7 показан график, схожий с графиками, создаваемыми системным монитором Windows. На этом экране отображается прогноз использования процессора для сервера SQL {черная линия) одновременно с магистральной сетью (линия, выделенная синим цветом, примерно 5%}. Более подробно о счетчиках производительности рассказано з главе 4.

Рис. 10-7. Прогнозируемый счетчик производительности В IndyView входит механизм статистики, позволяющий пользователям проверить любые данные по производительности моделируемой системы, применяя либо встроенные графические инструменты или экспортируя данные в электронную таблицу Excel.

Моделирование: инструменты прогноза производительности 313 Две диаграммы на рис.10-8 показывают прогнозируемый средний размер очереди для различных событий в ходе пробного запуска IBuySpy для определенной топологии системы. На верхней диаграмме отображаются очереди событий на сервере IIS, а на нижней — очередь событий на сервере SQL. Из диаграмм видно, что «узкое» место системы — это процессор IIS, поскольку средний размер его очереди равен 21,4. Для сравнения: очередь его сетевой карты очень мала. Средние очереди сервера SQL также небольших размеров.

Рис.10-8.

Прогнозируемая длина очереди

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

314

Глава 10

ли, то проявится возможное «узкое» место в производительности системы.

Итоговое сравнение ТСА и моделирования производительности В главе 9 мы использовали контрольные тесты для подтверждения расходов, прогнозируемых с помощью модели ТСА. Для сравнения мы применили Indy, чтобы определить модель производительности пропускной способности IBuySpy для одновременных подключений, используя такие цифры, полученные из ТСА, как стоимость событий, В табл. 10-1 приведены оба результата. Табл. 10-1. Сравнение прогнозов ТСА и Indy Количество прогнозируемых Одновременные с помощью ТСА подключения мегациклов

Количество спрогнозированных Количество с помощью Indy измеренных мегациклов мегациклов

1000

115,8

120,2

10000

116,0 1160,0

1166,0

1147,0

14653

1699,0

1694,0

1661,0

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

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

Моделирование: инструменты прогноза производительности

315

Сценарий «что, если» №1: анализ «узких» мест На рис.10-9 показан пример возможного анализа «узких» мест с помощью Indy. График демонстрирует прогнозируемую производительность сайта электронной коммерции при изменении количества Web-серверов. Нагрузочный тест сайта проводился для того, чтобы показать максимально достижимую пропускную способность для транзакций при покупках. Как и ожидалось, увеличение количества Web-серверов увеличивает общую пропускную способность системы в отношении количества транзакций в секунду при покупках. Однако мы достигаем пика при семи Webсерверах — добавление дополнительных Web-серверов сверх этого числа не увеличит пропускную способность системы. Если мы используем Indy для просмотра смоделированных задержек в очереди в каждом из активных компонентов, то увидим, что сервер SQL достиг точки насыщения. После достижения этой точки, пропускная способность системы остается без изменений до тех пор, пока мы не увеличим количество серверов SQL или их производительность. 6000 т

-- 35 — • - Задержка события HS —•— Задержка события SQL • -о-- Транзакций/с

--зо | >ij - 25 * t,

. 20 ,s

' = 1•_ 10 ч £

5 6 7 Число серверов

Рис. 10-9. Анализ «узких» мест Получив это заключение, дальнейшие тесты с применением данного существующего набора транзакций следует проводить для определения улучшений в оборудовании серверов SQL или того, сколько SQL серверов можно добавить, не оказав влияния на работу других элементов, например на сетевую производительность.

ЗТ6

Глава 10

Сценарий «что, если» №2: улучшения в архитектуре Еще одной характерной чертой Indy является возможность моделировать влияние изменений в архитектуре на производительность системы. Предположим, у нас запущено приложение IBuySpy на сайте электронной коммерции с всего-навсего двумя старыми Web-серверами с процессорами 450 МГц со статической балансировкой нагрузки. Для стандартного набора пользователей, который мы здесь задали, мы можем применить Indy для определения максимальной пропускной способности, равной 46,8 транзакциям в секунду. Приближается Рождество (время подарков), и мы решили добавить третий сервер. Это более современный Web-сервер с процессором 1 ГГц. Несмотря на то, что мы больше чем вдвое увеличили количество процессорных «лошадиных сил» наших Web-серверов, прогноз Indy следующий: они будут поддерживать максимальную пропускную способность, равную 53,5 транзакциям в секунду. Проблема заключается в том, что мы все еще применяем циклическую балансировку нагрузки, и таким образом, только одна треть наших транзакций использует преимущество более быстрого процессора. При применении метода динамической балансировки нагрузки, который учитывает соответствующую серверную нагрузку, прогноз Indy будет таков: наша пропускная способность увеличится до 73,4 транзакций в секунду. Этот тип моделирования различных типов серверов, вместе с динамической балансировкой нагрузки во время исполнения в зависимости от поведения системы, невозможен в ТСА.

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

Моделирование: инструменты прогноза производительности

317

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

Предметный указатель

.NET managed code см. управляемый код .NET

A ACE 205 ACT (Application Center Test) 1 5, 32, 33, 148, 231 — Developer Edition 64 - SBC 36 — аутентификация 39, 40 — виртуальный пользователь 36 — динамический тест 36 — заголовок 39 — запуск 45 — нагрузочный поток 36 — отладка сценариев тестирования 62 — отчет 48 — пользователь 38, 43 — пользовательский интерфейс 45 — сценарии тестирования 46 — установка 34 — шифрование 39 ACT Team 93,98 Active Directory 146 ADO (ActiveX Data Objects) 57 ADO.NET 5,171 alert см. оповещение ANSI 189 API 72, 169 AppDomain см. домен приложения Application Center 2000 5 Application Expert 116, 118, 130, 131, 136 — анализ последовательностей 133 — диаграмма пакетов 132

— карта диалога 131, 136 — поиск задержек обработки 138 — трассировка пакетов 134 AppMetrics (AppMetrics for Transactions) 211 AppMetrics Manager 211 ASCII 149 ASCX 144 ASMX 144 ASP 3, Л 7, 142, 143, 167, 187 ASP.NET 5, 43, 142, 143, 144, 146, 166, 206 — кэширование 167 — результатов 167 — фрагментов 169 — счетчик производительности 163 — трассировка 157,1 58 ASPX 144,159 assembly см. сборка

В backend activity profile см. профиль, активности сервера bandwidth см. полоса пропускания batch см. пакет BizTalk Server 2000 5

С С#

186,206

ас- + 206

C++ .NET 186 САР 128 CAS (Code Access Security) 204 CLR [common language runtime) 5, 185, 188, 190 COM 36,189 COM+ 211 Commerce Server 2000 5

Предметный указатель Compuware Application Expert 109 cookie 38 cross-application calls см, именооание для межпрограммных вызовов CS 144 CSS 113

D DCOM 209 DevPartner Studio 205 Diagnostics Monitor 213 DLL 143,189 DNA 267 DNS 68 — сервер 121 — суфикс 121 DPC (deferred procedure call) 88 DSL 21 Enterprise Manager 235 Enterprise Services 5,211,215 Exchange Server 2000 5 Extensible Markup Language CM. XML FILLFACTOR 255 GIF (Graphics Interchange Format! 115 Clobal.asax 144

H Host Integration Server 2000 5 HTM 113 HTML 7, 113, 142 HTTP (Hypertext Transfer Protocol) 7, 9, 38, 113, 155, 161, 166, 209 hub см. концентратор I IIS (Internet Information Server) 24, 113, 123, 126, 142, 143, 148, 149, 154, 206

319 Index Tuning 261 Indy 298 " — библиотека оборудования 300 — библиотека рабочей нагрузки 301 — интерфейс 301 — клиентский исполняемый файл 301 — ядро 299 Indy View 301 INIM (Internet Native Integration Methodology) 8 Instrumentation Manager 206 Internet Security and Acceleration Server 5 IP-адрес 121,151 JIT (lust-in-Time Compiler) 186, 187 JS 113 IScript 36, 117, 206

M MAC-agpec 121, 129 machine.config 146 Microsoft .NET 4 Microsoft .NET Framework 3, 5 Microsoft .NET Passport 9, 10, 41 Microsoft US Log Format 149 Microsoft Internet Explorer 11 3 Microsoft Passport 39, 41 Microsoft SQL Server 1 23, 1 71 MMC (Microsoft Management Console) 70 Mobile Information Server 2001 j Mobile Internet Toolkit 5 MSIL (Microsoft Intermediate Language] 186, 188 N NCSA Common Log File Format 149 Network Monitor 109, 110, 116, 120, 121 — буфер данных 1 22 — настройка 122

Предметный указатель

320 — окно отображения данных 129 — окно перехвата 129 -сеть 122, 123 — фильтр анализатора 122 Network Monitor 2 Full 121 Network Monitor 2 Lite 121, 126 ngen.exe 188 NLB (Network Load Balancing) 183 NTLM (NT LAN Manager) 38, 39

О ODBC 149 OLE DB .NET Data Provider 1 71 Oracle 171 OSI (Open Systems Interconnection] 108

pathping 110 PDA (Personal Digital Assistant] 1, 6 Performance Logs and Alerts 70, 100 Performance Monitor 26, 70 PERL 36 ping 110 Production Monitor 215, 216

Query Analyzer 262

R Remote Network Monitor 125 Response Time Predictor 134 Robots Exclusion Standard 44 RPC (Remote Procedure Call) I RPS (requests per second) 48 SARC (Searchable Argument) 247, 253 SBC (simultaneous browser connection) 36, 38 SDL (Service Description Language) SMS (System Management Server) 121 SNMP 217

SOAP (Simple Object Access Protocol) 7, 8, 9, 42 SQL Profiler 26, 118, 138, 221 SQL Query Analyzer 221, 228, 235 SQL Server 2000 5, 96 SQL Server.NET Data Provider 1 71 SSL 41,42,180

TCA (Transaction Cost Analysis) 13, 263, 264, 266, 267, 273, 288, 289 TCP/IP 108 tracert 110 TTLB (Time To Last Byte) 48

и UDDI (Universal Description, Discovery and Integration] 8, 9 UML (Universal Modeling Language) 290 Unicode 189

V VB 144 VBScript (Visual Basic Script) 36, 11 7, 206 Visual Basic 205 Visual Basic .NET 9, 144, 186, 206 Visual С 206 Visual C# 9 Visual C++ 9,206 Visual Studio .NET 5, 34, 146 Visual Trace Route 110

w W3C Extended Log File Format 149, 150, 151 WAN-имитатор 139 WAP (Wireless Application Protocol) 1 Web.config 146, 159 Web-сервер 142 Web-сервис 9 Web-ферма 166 Win32 152

321

Предметный указатель Windows DNA (Windows Distributed interNet applications Architecture) 3 Windows Forms 5 WSDL (Web Services Description Language) 8

XML (Extensible Markup Language) 5, 1. 8, 9, 42, 144, 146, 177

анализ стоимости транзакции см. ТСА аргумент поиска см. SARG аутентификация 144 — Microsoft Passport 39, 41, 144, 145 -Windows 40, 144, 145 — базовая 39,40, 145 — дайджест 39, 40, 145 — интегрированная 145 — анонимная 39, 41 — формой 145,146

библиотека классов 5 блокировка 233

В верификация 187 время до последнего байта см. TTLB

дедлок 234 — преобразования 234 — циклический 234 декларация 186 домен приложения 188, 200

3 задержка обработки 109 запрос — режим размышления 265

зеркализация портов 124

И именование для межпрограммных вызовов 214 индекс 237, 245 — кластерный 245, 254 — некластерный 246 — покрывающий 247, 251, 253 инфраструктура технологии оценки произвопительности 298 исключение 194, 202 — неуправляемый код 196 — производительность 196

К код — неуправляемый 189, 196, 205 — профилирование 205 — управляемый 205 компилятор по требованию см. JIT компиляция предварительная 188 концентратор 125 корневой блокирозщик 230 куча 191 — уплотненная 191

м марииалинг 189 масштабирование — вверх 181, 182 — вширь 181 масштабируемость 166, 181 метабаза 114 метакаталог 301 методология естественной интеграции для Интернета см. INIM метрика 211, 21 3 модель оборудования 299 модуль фонового кода 144 мониторинг 72 — удаленный 84

322

О общеязыковая исполняющая среда см. CLR объект 71 —.NET CLR Exceptions 202 — NET CLR Loading 200 —.NETCLRLocksAndThreads 201 —.NET CLR Memory 197 —.NET CLR Security 203 — завершение 193 — закрепленный 189, 192 оповещение 72, 100, 101, 103 оповещения и журналы производительности см. Performance Logs and Alerts оснастка 70 отложенный вызов процедур см. DPC

п пакет 222 параллельная браузерная сессия см. SBC передаваемые данные 112 перекрытие 124 полоса пропускания 109 пользовательский сценарии 119 представление 223 — индексированное 258, 260 приложение — анализ роста производительности 23 — взаимоблокировка 26 — время отклика 109, 116, 118, 134, 138, 139 — готовность 123 — диагностика 214 — допустимое время отклика 20 — загрузка процессора 86 — загрузка сервера 28 — задержка обработки 28, 116 — контролируемая среда тестирования 68 — масштабируемость 123

Предметный указатель — метрика производительности 27, 29 — мониторинг 162, 215 — нагрузочное тестирование 32, 178 — нагрузочный сценарий 15 — нагрузочный тест 66, 273 — обращение 25 — параллельное соединение 36 — пользовательская активность 26 — пользовательский интервал простоя 36 — пропускная способность 16,21, 32 — просмотр страницы 25 — профилирование 149 — пул сессий 1 72 — размер пакета 1 73 — размер страницы 1 79 — распределенное 209 — сбор мусора 194 — сервер 123 — серверная ошибка 27 — сетевая производительность 108 — сетевой обмен 111,112 — состояние 165 — счетчик производительности 164 — таймер 11 7 — тест на задымление 15 — тестирование производительности 13 — тестовый сценарий 33 — «узкое» место 26 — утечка памяти 28 —- число одновременных пользователей 21 провайдер данных 1 71 просмотр страницы 109 простой протокол доступа к объектам см. SOAP протокол пересылки гипертекста см. HTTP

323

Предметный указатель профиль — активности пользователя — активности сервера 26 •— пользователя 270

расширяемый язык разметки см. XML

сбор мусора 190, 191 сборка 186, 201 — управляемая 188 сборщик мусора 189, 190 сессия — блокирование 229 — блокирующая 230 — состояние 166 сетевая задержка 109, 110 сетевой анализатор 120 сетевой обмен 109 сетевой переключатель 124 системный монитор 70, 78, 84, 92, 162, 227 сниффер 120 событие 222 соединение 245 — слиянием 245 — циклическое 245 состояние отображения 43, 1 70 страница — разбиение 255 страничный просмотр 109 счетчик 71, 85, 1 62 -#GC Handles 197 - # Gen 0 Collections 198 - # Gen 1 Collections 198 -#Cen 2 Collections 198 - # Link Time Checks 204 — # of Exceps Thrown 202 — # of Exceps Thrown /sec 203 - # Total Committed Bytes 1 99 -%TimeinCC 199 — % Time in RT checks 204

— ASP Execution Time 267 — ASP Requests/Sec 267 -ASP Wait Time 267 — Batch Requests/sec 228 — Buffer cache hit ratio 227 — Contention Rate/sec 202 — Current Queue Length 202 — Gen 0 heap size 199 — Gen 0 Promoted Bytes/sec 199 — Gen 1 heap size 199 — Gen 1 Promoted Bytes/sec 200 — Gen 2 heap size 200 — Lock Requests/sec 227 — Lock Timeouts/sec 227 — Lock Waits/sec 228 — Memory Grants Pending 228 — Number of Deadlocks/sec 228 — Requests Queued 267 — SQL Compilations/sec 228 — SQL Re-Corn pi lations/sec 228 -Stack Walk Depth 204 - Total # of Contentions 202 — Total AppDomains 200 - Total Assemblies 201 - Total Classes Loaded 201 - Total Runtime Checks 204 — User Connections 227 — дисковый 90 — журнал 104 — значение 76 — масштаб 74 — мониторинг 86 — оповещения 102 — производительности

- .NET" 196

— ASP.NET 163 -IIS 162 - SQL Server 227 -TCA 267 — удаление 104

Т таблица стилей 109 точка регистрации 41

Предметный указатель

324 транзакции анализ стоимости см. ТС А трассировка 117,222 трафик сетевой 127

шаблон трассировки

удаленный вызов процедуры см. RPC указание по блокировке 228 управляемый код .NET 185

Я язык описания Web-сервисов см. VVSDL

число запросов в секунду см. RPS Ш 222

Тодд Кацке Togg Кацке (Todd Kutzke} руководит в Microsoft группой Application Consulting and Engineering (АСЕ). Когда Тодд не пишет о тестировании производительности Web-приложений, то он либо висит на скале, либо плывет под парусом где-нибудь на севере тихоокеанского побережья США. До прихода в Microsoft Тодд работал старшим консультантом в Deloitte & Touche и финансовым аналитиком в банке ABN-AMRO Bank.

Вильям Эрик Моррис Вильям Эрик Моррис (William Eric Morris) занимается в Microsoft АСЕ тестированием Web-приложений. Свою профессиональную карьеру он начал в индустрии телекоммуникаций, до сих пор сохранил страсть к технологиям и техническим новинкам и вообще интересуется принципами работы различных устройств. Он занимал различные посты в разных компаниях, от фирм из списка Fortune 500 и до начинающих Интернет-компаний, в том числе работал инженером по сетям, Web-разработчиком, администратором сервера, Web-мастером, консультантом и аналитиком производительности. Он считает, что умеет творчески решать проблемы. Эрик имеет степень бакалавра психологии, полученную в колледже Уильяма и Мэри в Вирджинии. Вы можете связаться с ним по адресу eric@07734.org.

Стив Ли Стив Аи (Steve Lee) — MCDBA, MCSD, MCSE и CCNA — работает администратором баз данных в группе MSN компании Microsoft. Он занимается оптимизацией производительности и моделированием нагрузочной способности.

Брайан Д'Мелло Брайан Д'Мелло (Brian D'Mello) является членом Microsoft АСЕ Team и занимается тестированием Web-производительности для подразделений Microsoft. Ранее он в различных компаниях занимался тестированием и поддержкой программ. Интересуется Web-программированием и технологиями SQL-разработки.

Киав Менг Ли Киав Менг Ли (Khiaw Meng (K.M.) Lee) работает в Microsoft специалистом по анализу производительности. Гавайский Тихоокеанский Университет присвоил ему степень магистра информационных систем и магистра бизнес-управления. Он любит плавание, байдарки, фильмы и филателию.

Николаас Ф. Янсен Николаас Ф, Янсен (Nicolaas F. Jansen) выполняет функции аналитика производительности в Microsoft АСЕ Team. Он имеет степень бакалавра информатики. В свободное от работы время Николаас любит удить на муху в водах тихоокеанского побережья.

Джон Хопкинс Джон Хопкинс (John Hopkins) работает старшим аналитиком производительности в Microsoft АСЕ Team и имеет многолетний опыт в данной области. Джон любит проводить время на природе и порыбачить с друзьями и семьей.

Ирфан А. Чаудри Ирфан А, Чаудри (Irfan A. Chaudhry) — программный менеджер з Microsoft АСЕ Team. Занимается анализом производительности. На досуге з соавторстве с друзьями пишет книги: «MCSE Microsoft SQL Server 2000 Administration, Readiness Review. Exam 70-228» (Microsoft Press, 2001); «Microsoft Windows 2000 Performance Tuning Technical Reference» (Microsoft Press, 2000) и «Peter Norton's Complete Guide to Microsoft Windows 2000 Server» (Sams, 2000).

ЛИЦЕНЗИОННОЕ СОГЛАШЕНИЕ MICROSOFT ЭТО ВАЖНО — ПРОЧИТАЙТЕ ВНИМАТЕЛЬНО. Настоящее лицензионное соглашение (далее кСоглашение») является юридическим документом, оно заключается ^ежду Вами (физическим или юридическим лицом) и Microsoft Corporation (далее «корпорации Microsoft}.) на указанный выше продукт Microsoft, который включает программное обеспечение и может включать сопутствующие мультимедийные и печатные материалы, а также электронную документацию (далее «Программный Продукт»). Любой компонент, входящий в Программный Продукт, который сопровождается отдельным Соглашением, подпадает под действие именно того Соглашения, а. не условий, изложенных ниже. Установка, копирование или иное использование данного Программного Продукта означает принятие Вами данного Соглашения. Если Вы не принимаете его условий, то не имеете права устанавливать, копировать или как-то иначе использовать этот Программный Продукт. ЛИЦЕНЗИЯ НА ПРОГРАММНЫЙ ПРОДУКТ Программный Продукт защищен законами Соединенных Штатов по авторскому праву и международными договорами по авторскому праву, а также другими законами и договорами по праэам на интеллектуальную собственность. 1.

ОБЪЕМ ЛИЦЕНЗИИ. Настоящее Соглашение дает Вам право: ai Программный продукт. Bui можете установить и использовать одну копию Программного Продукта на одном компьютере. Основной пользователь компьютера, на котором установлен данный Программный Продукт, может сделать только аля себя вторую копию и и г пользовать ее на портативном компьютере. TJ) Хранение или использование в сети. Вы можете также скопировать или установить экземпляр Программного Продукта на устройстве хранения, например на сетевом сервере, исключительно для установки или запуска данного Программного Продукта на других компьютерах в своей внутренней сети, но тогда Вы должны приобрести лицензии на каждый такой компьютер. Лицензию на данный Программный продукт нельзя использовать совместно или одновременно на других компьютерах. cj License Pak. Если Вы купили эту лицензию в составе Microsoft License Pak, можете сделать ряд дополнительных копий программного обеспечения, входящего в данный Программный Продукт, и исполаэовать каждую копию так, как было описано выше. Кроме того, Вы получаете право сделать соответствующее число вторичных копии для портативного компьютера в целях, также проверенных выше. tlj Примеры кода. Это относится исключительно к отдельным частям Программного Продукта, заявленным как примеры кода (далее «Примеры»), если таковые входят в состав Программного Продукта. Г( Использование и модификация. Microsoft дает Вам право использовать и модифицировать исходный код Примеров при условии соблюдении пункта idllml ниже. Вы не uweeie права распространять в виде исходного кода ни Примеры, ни их модифицированную версию. И! Распространяемые файлы. При соблюдении пункта idKiii) Microsoft gaei Вам право на свободное or отчислений копирование и распространение и виде объектного кода Примеров или их модифицированной версии, кроме тех частей (или их модифицированных версий), которые оговорены в файле Readme, относящемся к данному Программному Продукту, как не подлежащие распространению. liil Требования к распространению файлов. Bui можете распространять файлы, разрешенные к распространению, при условии, что: а) распространяете их в виде объектного кода только в сочетании со своим приложением и как его часть; б'> не используете название, эмблему или товарные знаки Microsoft для продвижения своего приложения; в) включаете имеющуюся в Программном Продукте ссылку на авторские права в cociae этикетки и заставки своего при\ижения; ?'( согласны освободите or ответственности и взять на себя защиту корпорации Microsoft от любых претензий или преследований по закону, включая судебные издержки, если таковые возникнут в результате использования или распространения Вашего приложения; и gj не допускаете дальнейшем распространения конечным пользователем своего приложения. По поводу отчислений и других условий лицензии применительно к иным видам использования или распространения распространяемых файлов обращайтесь в Microsoft.

ПРОЧИЕ ПРАВА И ОГРАНИЧЕНИЯ • Ограничении на реконструкцию, декомпиляцию и дисассемблирование. Вы не имеете права реконструировать, декомпилировать или дизассемблировать данный Программный Продукт, кроме того случая, когда такая деятельность (только в той мере, которая необходима) явно ра.тpeujaeicsi соответствующим законом, несмотря на это ограничение.

" Разделение компонентов. Длинам Программный Продукт лицензируетси как единый продукт. Его компоненты нельзя отдел» и> друг от друга для использования более чем на одном компьютере. • Аренда. Д.шный Программный Продукт нельзя сдавать в прокат, передавать во временное пользование иди уступать для использования а иных целях, • Услуги по технической поддержке. Microsoft может (но не обязана) предоставить Ваму{луги по технической поддержке данного Программного Продукта (далее «Услуги»). Предоставление Услу? регулируется соответствующими правилами и программами Microsoft, описанными в руководстве пользователя, электронной документации и/или других материалах, публикуемых Microsoft. Любой дополнительный программный код, предоставленный о рамках Услуг, следует считать частью данного Программного Продукта и подпадающим под действие настоящего Соглашения. Что касается технической информации, предоставляемой Вами корпорации Microsoft при использовании ее Услуг, то Microsoft может задействовать эту информацию в делоаых целях, в том числе ПАЯ технической поддержки продукта и разработки. Используя такую техническую информацию, Microsoft но будет ссылаться на бас. • Передача прав на программное обеспечение. Вы можете безвозвратно уступить все права, регулируемые настоящим Соглашением, при условии, что не оставите себе никаких копий, передадите все составите част данного Программного Продукта (включая компоненты, мультимедийные и печатные материалы, любые обновления, Соглашение и сертификат подлинности, если таковой имеетсп] и принимающая сторона согласится с условиями настоящего Соглашения. • Прекращение действии Соглашения. Без ущерба для любых других прав Microsoft может прекратить действие настоящего Соглашения, если Вы нарушите его условия. В этом случае вы должны будете уничтожить все копии данного Программного Продукта вместе со всеми его компонентами. 1.

АВТОРСКОЕ ПРАВО. Все авторские права и право собственности на Программный Продукт (в том числе любые изображения, фотографии, анимации, оидео, аудио, музыку, теист, примеры кода, распространяемые файлы и апплегы. включенные в состав Программного Продукта) и любые его копии принадлежат корпорации Microsoft или ее поставщикам. Программный Продукт охраняется законодательством об автор; ких пр.шач и положениями международных договоров. Таким образом, Вы должны обращаться с данным Программным Продуктом, как с любым другим материалом, охраняемым авторскими правами, с тем исключением, что Эы можете установить Программный Продукт на один компьютер при условии, что храните оригинал исключительно как резервную или архивную копию. Копирование печатных материалов, поставляемых вместе с Программным Продуктом, запрещаемся.

ОГРАНИЧЕНИЕ ГАРАНТИИ ДАННЫЙ 11РОГРАММНЫЙ ПРОДУКТ (ВКЛЮЧАЯ ИНСТРУКЦИИ ПО ЕГО ИСПОЛЬЗОВАНИЮ) ПРЕДОСТАВЛЯЕТСЯ ЪИЗ КАКОЙ-ЛИБО ГАРАНТИИ. КОРПОРАЦИЯ MICROSOFT СНИМАЕТ С С.КБЯ ЛЮБУЮ ВОЗМОЖНУЮ ОТВЕТСТВЕННОСТЬ. В ТОМ ЧИСЛЕ ОТВЕТСТВЕННОСТЬ ЗА КОММЕРЧЕСКУЮ 1 ЦЕННОСТЬ ИЛИ СООТВЕТСТВИИ ОПРЕДЕЛЕННЫМ ЦЕЛЯМ. ВЕСЬ РИСК ПО ИСПОЛЬЗОВАНИЮ ИЛИ РАБОТЕ С ПРОГРАММНЫМ ПРОДУКТОМ ЛОЖИТСЯ НА ВАС НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ КОРПОРАЦИЯ MICROSOFT. ЕЕ РАЗРАБОТЧИКИ, А ТАКЖЕ ВСЕ, ЗАНЯТЫЕ В СОЗДАНИИ, ПРОИЗВОДСТВЕ И РАСПРОСТРАНЕНИИ ДАННОГО ПРОГРАММНОГО ПРОДУКТА, НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ЗА КАКОЙ-ЛИБО УЩЕРБ (ВКЛЮЧАЯ ВСЕ, БЕЗ ИСКЛЮЧЕНИЯ, СЛУЧАИ УПУЩЕННОЙ ВЫГОДЫ. НАРУШЕНИЯ ХОЗЯЙСТВЕННОЙ ДЕЯТЕЛЬНОСТИ, ПОТЕРИ ИНФОГМА1 (ИИ ИЛИ ДРУГИХ УЬ'ЫТКОВ) ВСЛЕДСТВИЕ ИСПОЛЬЗОВАНИЯ ИЛИ НЕВОЗМОЖНОСТИ ИСПОЛЬЗОВАНИЯ ДАННОГО ПРОГРАММНОГО ПРОДУКТА ИЛИ ДОКУМЕНТАЦИИ. ДАЖЕ 1-СЛИ КОРПОРАЦИЯ MICROSOFT БЫЛА ИЗВЕЩЕНА О ВОЗМОЖНОСТИ ТАКИХ ПОТЕРЬ, ТАК КАК В НЕКОТОРЫХ СТРАНАХ НГ РАЗРЕШЕНО ИСКЛЮЧЕНИЕ ИЛ И ОГРАНИЧЕНИЕ ОТВЕТСТВЕННОСТИ ЗА НЕПРЕДНАМЕРЕННЫЙ УЩЕРБ, УКАЗАННОЕ ОГРАНИЧЕНИЕ МОЖЕТ ВАС НЕ КОСНУТЬСЯ. РАЗНОЕ

Настоящее Соглашение регулируется законодательством штата Вашингтон (США), кроме случаен {и лишь в той мере, насколько это необходимо) исключительной юрисдикции того государства, па территории которого используется Программный Продукт. Если у Вас возникли какие-либо допросы, касающиеся настоящего Соглашения, или если Вы желай е связаться с Microsoft no любой другой причине, пожалуйста, обращайтесь в местное представительство Microsoft или лишите по адресу: Microsoft Sales Information Center, One Microsoft Way. Redmond. WA 98052-6399-

Microsoft Corporation

Тестирование производительности Web-приложении Microsoft .NET Перевод с английского под общей редакцией Редактор

В. Г. Вшивцева

Ю. П. Леонова

Технический редактор

Л. А. Панчук

Компьютерная верстка В, В. Хильченко Дизайнер обложки Е. В. Козлова Оригинал-макет выполнен с использованием издательской системы Adobe PageMaker 6.0

легальный пользователь

Главный редактор

РогоНТуре Д. И. Козлов

Подготовлено к печати издательством «Русская Редакция» 121087, Москва, ул. Заречная, д.9 тел.: I.095) 142-0571, тел./факс: (095) 145-4519 e-mait: info@rusedit.ru, http:// www.rusedit.ru

МРУССШ РЕЦНЦИЯ Подписано в печать 17.02.03 е. Тираж 3 000 экз. Формат 60x90/16. Физ. п. л. 22 Отпечатано в ОАО «Типография «Новости» 107105, Москва, ул. Фр. Энгельса, 46

Наши книги Вы можете приобрести • в Москве: Специализированный магазин •'Компьютерная и деловая книга» Ленинский проспект, строение 38, теп.: (095) 778-7269 «Библио-Глобус» ул. Мясницкая. 6. тел/ (095) 928-3567 «Московский дом книги» уп. Новый Арбат, 8. тел.: [095) 290-4507 "Домтехнической книги.> Ленинский пр-т, -О. тел.: (095) 137-6019 «Молодая гвардия» ул. Большая Полянка. £8, тел.: (095) 238-5001 »Дом книги на Соколе» Ленинградский пр-т 78. тел.: (095) 152-4511 «Дом книги на Войковской» Ленинградское ш.. 13 стр.1, тел.: (095) 150-6917 «Мир печати» ул 2-я Тверская-Ямская, 54, тел.: (095] 978-5047 Торговый дом книги ••Москва» ул Тверская, 8. тел.: (095) 229-6483

• в Санкт-Петербурге: СПб Дом книги, Невский пр-т., 2В тел.-(812) 318-6402 СПб Дом военной книги. Невский пр-т., 20 тел.: (812) 312-0563. 314-7184 Магазин «Подписные издания», Литейный пр-т., 57, тел.: (812) 273-5053 Магазин «Техническая книга», ул Пушкински. 2, тел.: (812)16-5-6565, 164-1413 Магазин «Буквоед», Невский пр-т., 13. тел,: (812) 312-6734 ЗАО ••Торговый Дом "Диалект», тел.: (812] 247-1483 Оптово-розничный магазин «Наука и техника», тел.: (812) 567-7025

• в Екатеринбурге: Магазин «Дон книгиуп Валека, 12, тел.: (3432] 59-4200

• в Великом Новгороде: «Наука и техника». ул. Большая Санкт-Петербургская, 44, Дворец Молодежи, 2-й этаж

• в Новосибирске: 000 -Ton-книга», тел.: (3832} 36-1026

• в Алма-Ате (Казахстан): чп Болат Амреев, моб. тел.. 8-327-908-28-57, (3272) 76-1404

• в Киеве (Украина): 000 Издательство «Ирина-Пресс», тел.: (+1038044) 269-0423 -Техническая книга на Петровке» теп : (+1038044) 268-5346

e d u c a t i o n

Ваш курс начинается завтра! Подготовка сертифицированных инженеров и администраторе Microsoft Авторизованные и авторские курсы по: в Windows 2000 / ХР * SunSoiarisS * Visual Studio .NET 9 Электронной коммерции

Microsoft Technical Education Center Учебный центр SoftUne 119991 г. Москва, ул. Губкина, д. тел.: (095) 232 00 23 e-mail; educ@softline.ru http://education.softiine.ru

* Безопасности информационных систем и еще более 40 курсов по самым современным компьютерным технологиям.

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

Дневные и вечерние занятия. Опытные преподаватели. Индивидуальные консультации.

- £аэ сагз •

В каждом из номеров нашего журнала - новости компьютерной индустрии - подробности о современных и перспективны! технологиях - тесты и обзоры аппаратных • программных продуктов - интернет и мультимедиа, игры и прикладные программы - консультации экспертов, встречи с интересными людьми - CD-приложение с полезными утилитами

НАШИ ИНДЕКСЫ: п Soft - 73140, Hard'n'Son + CD

•IIIIIIIIIIIIIIIIIIIIIM _

•

ПРОГРАММИСТ

Содержимое компакт-диск,

Как тестировать свои Web-приложения, чтобы их производительность и масштабируемость соответствовала лучшим мировым образцам? В этой книге специалисты Microsoft делятся собственным опытом, который они приобрели, протестировав и настроив сотни Web-сайтов и Web-приложений. Вы узнаете, как довести производительность Web-приложений до уровня традиционных приложений или более высокого, как применять лучшие инструменты для планирования и выполнения тестов производительности, как настраивать средства профилирования и анализировать данные о производительности Microsoft Internet Information Services, Microsoft ASRNET, управляемого кода и SQL-уровня.

• электронная версия книги с возможностью поиска (на английском языке); » сценарии методики анализа стоимости транзакции (Transaction Cost Analysis).

Об авторах: Группа Microsoft Application Consulting and Engineering (ACE) — специалисты Micro

Основные темы книги

«съевшие собаку» на анали

* Методология тестирования, применяемая для Microsoft.com, Xbox.com и других высокопроизводительных сайтов.

ний. Они знают все о прове

производительности прило

i Планирование тестирования производительности.

производительности сайтов

« Нагрузочное тестирование с применением Microsoft Application Center Test (ACT).

Microsoft, включая MSN.con,

-« Мониторинг производительности приложения посредством системного монитора.

знаниями со всеми. Члены э'и

и готовы поделиться своими

» Проверка защищенности Web-сайта.

команды могут похвастаться профессиональными навыка-,

* Анализ производительности работы в сети.

ми, необходимыми для плани-

« Анализ Web-уровня.

рования и проведения нагру-

« Анализ производительности управляемого кода.

зочных тестов, прогнозирована

* Анализ SQL-уровня. * Применение методики анализа стоимости транзакций (Transaction Cost Analysis).

пропускной способности сайте и определения «узких» мест в производительности.

ISBN 5-7502-0224-0

785750 202249

Web-узел издательства: www.rusedit.ru Интернет-магазин: www.ITbook.ru