Asp проверка быстродействия и масштабируемости

Тестирование производительности базы данных с помощью Apache JMeter

Обзор

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

Необходимые ресурсы

• Установите Java Development Kit.
• Установите Apache JMeter.

Пример использования

Выполним нагрузочное тестирование базы данных с помощью Apache JMeter. Чтобы измерить ее производительность, используем драйвер MySQL JDBC.

План тестирования базы данных

План тестирования описывает последовательность шагов, которые должен выполнить JMeter. Для его составления необходимы следующие элементы:

• Группа потоков.
• Запрос JDBC.
• Сводный отчет.

Добавление пользователей

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

Чтобы создать группу потоков, выполните следующие действия:

• В левой панели кликните правой кнопкой мыши по Test Plan .
• Выберите Add → Threads (Users) → Thread Group.

• Укажите имя группы потоков – « JDBC Users ».
• Нажмите кнопку Add и измените значения свойств, используемые по умолчанию, следующим образом:

• No. of Threads (users): 10.
• Ramp-Up Period (in seconds): 100.
• Loop Count: 10.

Примечание. Ramp-Up Period указывает время, необходимое для увеличения количества потоков до максимального значения.

Мы используем 10 потоков, а период разгона составляет 100 секунд. Каждый новый поток запускается через 10 секунд после начала предыдущего. Таким образом, запрос будет выполнен 10 (потоков) * 10 (циклов) = 100 раз. Аналогично, для 10 таблиц общее количество экземпляров составляет 100.

Добавление запросов JDBC

Чтобы добавить запрос JDBC, выполните следующие действия:

• В левой панели кликните правой кнопкой мыши по Thread Group .
• Выберите Add → Config Element → JDBC Connection Configuration .
• Настройте следующие параметры:
• Variable Name: myDatabase

Примечание . Это имя должно быть уникальным, так как оно используется JDBC Sampler для идентификации используемой конфигурации.

• Database URL: jdbc:mysql://ipOfTheServer:3306/cloud
• JDBC Driver class: mysql.jdbc.Driver.
• Username: имя пользователя базы данных.

Добавление сэмплера

Чтобы добавить сэмплер, выполните следующие действия:

• В левой панели кликните правой кнопкой мыши по Thread Group .
• Выберите Add → Sampler → JDBC Request .
• Укажите Variable Name: «myDatabase».
  • Введите запрос в поле SQL Query.

Добавление обработчика для просмотра и сохранения результатов теста

Чтобы просмотреть результаты теста, выполните следующие действия:

• В левой панели кликните правой кнопкой мыши по Thread Group .
• Выберите Add → Listener → View Results Tree/Summary Report/Graph Results .
• Сохраните план тестирования и нажмите Run (Start или «Ctrl + R»), чтобы запустить тест.
• Все результаты теста будут сохранены в обработчике.

Просмотр результатов теста:

Результаты можно просмотреть в древовидном формате:

В табличном представлении:

А также в виде диаграмм:

Показатели эффективности

С помощью JMeter можно увидеть различные показатели производительности.

Пропускная способность

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

В нашем случае пропускная способность составляет 61,566 / в минуту. Высокое значение пропускной способности указывает на хорошую производительность.

Задержка

Задержка при передаче сообщения. Меньшее значение задержки указывает на большой объем отправляемой / получаемой информации. В нашем примере задержка для первого потока составляет 24446.

Минимальное / максимальное время загрузки / время отклика / время выборки

Разница между временем отправки запроса и временем получения ответа. Время отклика всегда больше или равно задержке.

В нашем примере для всех запросов время отклика> = задержка.

Линия 90% (90-ый процентиль)

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

Ошибки

Общий процент ошибок, найденных в экземпляре запроса. Значение 0,00% указывает на то, что все запросы выполнены успешно и производительность хорошая.

Стандартное отклонение

Более низкое значение стандартного отклонения указывает на большую согласованность данных. Стандартное отклонение должно быть меньше или равно половине среднего времени для метки. Если значение больше, это указывает на недопустимое значение. В нашем случае это 2881.

Минимальное время

Минимальное время, необходимое для отправки запросов. Общее время равно минимальному времени для всех образцов. В нашем случае это 0 мс.

Максимальное время

Максимальное время, необходимое для отправки запросов. Общее время равно максимальному времени для всех образцов. В нашем случае это 23 234 мс.

Среднее время

Среднее время ответа на запрос

КБ / сек

Измерение пропускной способности в килобайтах в секунду. В нашем случае это 0.

Сэмплеры

Общее количество запросов, отправленных на сервер. В нашем случае это 100.

Заключение

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

Полученные в ходе тестирования показатели могут использоваться в Performance Tuning Engineer для выявления слабых мест производительности.

Данная публикация представляет собой перевод статьи « Database Performance Testing with Apache JMeter » , подготовленной дружной командой проекта Интернет-технологии.ру

Десять лучших способов улучшения производительности IIS 7.0

Посетителей: 11846 | Просмотров: 14496 (сегодня 2) Шрифт:

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

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

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

Скорее всего, просто переход на IIS 7.0 не выявит всех преимуществ нового веб-сервера, хотя в некоторых случаях и этого будет достаточно. Например, на узле Microsoft.com было отмечено 10-процентное улучшение эффективности использования ЦП (полный анализ доступен в блоге группы разработки Microsoft.com наgo.microsoft.com/fwlink/?Link >® (оба процесса теперь выполняются на уровне ядра), а также улучшение вертикальной масштабируемости на многопроцессорных и многоядерных машинах.

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

Экономичные веб-серверы

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

Полный набор функций веб-сервера IIS 7.0 состоит из 44 модулей, включая собственные модули IIS и ASP.NET, предоставляющие службы для интегрированного конвейера. В модулях реализованы такие функции, как проверка подлинности (модули проверки подлинности Windows и дайджест-проверки подлинности), поддержка инфраструктуры приложения (модуль FastCGI), службы приложений (модуль состояния сеанса), обеспечение безопасности (модуль фильтрации запросов) и производительности (модуль кэширования выходных данных). Однако минимальному веб-серверу, обслуживающему статические страницы, для работы требуется всего 2 модуля!

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

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

Рис. 1. Пропускная способность сервера при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

Кроме того, может снизиться объем занимаемой памяти и повыситься плотность веб-узлов, особенно в случае сред совместного размещения или при использования большого количества рабочих процессов. Это происходит за счет уменьшения количества библиотек DLL, загружаемых каждым процессом, а также количества запросов на выделение памяти, происходящих при инициализации модуля и обработке запроса. На рис. 2 изображено использование памяти (в байтах исключительного использования рабочими процессами IIS) в тестах пропускной способности, о которых говорилось выше. И, хотя приведенные в этом примере изменения не так заметны, они, тем не менее, соответствуют всем ожиданиям. Дело в том, что поддержка приложений ASP.NET требует больше служебных данных, чем можно высвободить удалением модулей.

Рис. 2 Использование памяти (в байтах исключительного использования рабочими процессами IIS) сервером при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

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

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

Использование экономичной операционной системы

В Windows Server ® 2008 реализовано выделение компонентов на уровне операционной системы, посредством чего можно дополнительно сократить контактную зону веб-сервера. Минимальным режимом установки Windows Server 2008 является режим «Server Core», который содержит минимальный набор основных подсистем операционной системы. Для экономичных веб-серверов на базе IIS 7.0 лучшим вариантом установки является именно Server Core.

Однако, рассматривая возможности Server Core, необходимо учитывать, какие его ограничения могут отразиться на работе вашего приложения. В Server Core отсуствует поддержка платформы Microsoft ® .NET Framework, то есть нет ASP.NET, расширений.NET для IIS и диспетчера служб IIS. Кроме того, решение задач местного управления потребует использования средств командной строки, поскольку консоль управления (MMC) также отсутствует. Между приложениями, работающими под управлением Server Core и полной версией Windows Server, не будет особых отличий в объеме занимаемой памяти и пропускной способности приложений, если уже были использованы преимущества компонентной структуры IIS. Работа, выполняемая IIS и вашими приложениями, одинакова на обеих платформах. Однако есть характеристика, где разница будет заметна: место, занимаемое сервером, как на жестком диске, так и в оперативной памяти.

В качестве примера на рис. 3 показана разница в занимаемом объеме после одинаковой статической рабочей нагрузки на серверы, работающие под управлением Windows Server 2008 в полной конфигурации и Server Core. Хотя IIS занимает в обоих случаях почти одинаковое место, общий объем места, занимаемого операционной системой Server Core меньше, что позволяет поддерживать ту же рабочую нагрузку, используя существенно меньший объем памяти. Из-за меньшего размер установки может появиться возможность использовать менее мощное аппаратное обеспечение для работы приложения. При этом основная мощность процессора будет тратиться на обработку запросов приложения, а не операционной системы, что делает Server Core отличным вариантом для виртуализированных сред.

Рис. 3. Память, занимаемая Windows Server 2008 в полной конфигурации и Server Core после выполнения теста на статическую нагрузку

Применение топологий, адаптированных для нужд приложения

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

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

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

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

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

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

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

Улучшенная поддержка приложения

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

При поддержке платформ приложений в IIS с помощью CGI или другого механизма можно улучшить производительность (а в некоторых случаях и стабильность) путем перехода на протокол FastCGI.

Первой платформой приложений, использующей преимущества этой поддержки, является PHP. Группа разработчиков IIS фактически напрямую работала с компанией Zend Technologies для обеспечения успешной работы реализации FastCGI IIS с PHP и улучшения производительности платформы PHP в Windows. (Более подробные сведения об этом проекте см. в моем блоге по адресу go.microsoft.com/fwlink/?Link >

Перенос PHP и других платформ приложений на IIS 7.0 и FastCGI позволит использовать преимущества различных функций IIS 7.0, в том числе интегрированный контейнер ASP.NET. Это предоставляет очень удобный способ улучшения платформ приложений при помощи служб ASP.NET без их преобразования в ASP.NET. Это также позволяет совместно работать приложениям, использующим различные платформы. Пример использования этого для улучшения существующих приложений при помощи функций и повышения производительности без изменения кода см. в моей статье «Улучшите приложения при помощи интегрированного конвейера ASP.NET» в журнале MSDN ® Magazine (доступна по адресу msdn.microsoft.com/magazine/cc135973.aspx).

Увеличенная плотность приложений

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

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

Обратите внимание на то, что службы IIS 7.0 теперь позволяют подготавливать на каждом сервере больше приложений, чем раньше — в нескольких внутренних тестах достигалась цифра в 100 000 узлов на одном сервере. Это обеспечивает возможность создания и настройки большого числа узлов и приложений.

В качестве предупреждения: для достижения высокоскоростной подготовки необходимо перейти на новые API настройки, поскольку старые API настройки не позволяют этого. Кроме того, не все API настройки IIS предоставляют одинаковые характеристики производительности, поэтому для обеспечения максимальной производительности необходим тщательный выбор API. При возникновении сомнений используйте параметры конфигурации, которые напрямую используют новые объекты настройки IIS, включая пространство имен Microsoft.Web.Administration, служебную программу командной строки AppCmd.exe и объекты настройки IIS COM, которые можно вызвать из сценария, кода .NET или C++.

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

Поскольку для каждого активного приложения необходим определенный объем памяти и рабочий процесс (при использовании рекомендуемой модели изоляции приложений), количество активных приложений сильно зависит от объема памяти приложения. Поэтому хотя для рабочего процесса одного приложения, выполняющего только обслуживание статического содержимого, требуется всего 3 МБ (подобные приложения часто могут использовать рабочий процесс совместно с другими приложениями, работающими со статическим содержим), для некоторых динамических приложений может требоваться 100 МБ ОЗУ или больше даже при низкой загрузке. Это обуславливает незначительную загрузку памяти самим рабочим процессом IIS по сравнению с местом, которое занимает приложение, при определении максимальной возможной плотности.

В типичном сценарии совместного размещения часто можно увидеть так называемое распределение 80/20, когда 80 процентов запросов выполняются к 20 процентам узлов. Результат – небольшой процент активных узлов в любой определенный момент времени. Для обеспечения большего количества активных узлов службы IIS 7.0 предоставляют активное управление временем существования. Это помогает высвободить память неактивных приложений, чтобы можно было разместить большее количество активных приложений.

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

Для обеспечения возможности размещения множества активных приложений также следует использовать преимущества 64-разрядной операционной системы, заключающиеся в возможности использования более 4 ГБ ОЗУ. На основе этого можно настроить рабочие процессы IIS для работы в 32-разрядном режиме (SysWoW64), в котором они используют меньше памяти, одновременно позволяя операционной системе работать с большим объемом памяти, чем возможно в 32-разрядной среде.

Сокращение занимаемой полосы пропускания за счет сжатия данных

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

Одним из наиболее эффективных способов уменьшения полосы пропускания, необходимой для доставки ответов приложения, является использование сжатия HTTP. Оно позволяет значительно уменьшить размер ответа, часто даже в 10 раз, для просто сжимаемого содержимого, такого как HTML. Лучше всего то, что сжатие HTTP поддерживают практически все обозреватели для настольных систем, а затраты на распаковку на оборудовании настольных систем минимальны по сравнению с неявной экономией отправки меньшего количества данных. А поскольку сжатие основано на согласовании кодировки содержимого, определенном в протоколе HTTP 1.1, включение этой функции безопасно для клиентов, не поддерживающих сжатие — эти клиенты просто получают несжатую версию содержимого.

Службы IIS 7.0 предоставляет две функции сжатия, представленные в их предшественнике: статическое сжатие и динамическое сжатие. Статическое сжатие выполняет предварительное сжатие статического содержимого и сохраняет его на диск, таким образом, позволяя будущим запросам работать напрямую со сжатым содержимым без затрат на сжатие. Динамическое сжатие выполняет сжатие ответов в реальном времени, и позволяет сжимать созданные приложениями ответы. Все платформы приложений на IIS 7.0 могут использовать преимущества динамического сжатия, включая ASP, ASP.NET и PHP.

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

Можно дополнительно оптимизировать загрузку сжатия, настроив уровень сжатия для достижения необходимого соотношения сжатия и загрузки ЦП. Но на этом все не заканчивается — также можно настроить приложение для поддержки кэширования сжатого содержимого, что устраняет загрузку сжатия на попадания в кэше благодаря работе с уже сжатым содержимым. Имейте в виду, что в кэши вывода ASP.NET и IIS включена дополнительная возможность кэширования сжатого содержимого для поддерживающих это клиентов, а также обработка запросов клиентов, для которых необходимо несжатое содержимое.

Регулировка полосы пропускания для мультимедийных файлов

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

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

Если среднее время просмотра ваших видео составляет всего 5 секунд, но за это время предоставляются (буферизируются) видеоданные длительностью 30 секунд, скорее всего, вы теряете более 80 процентов полосы пропускания!

Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4 ) и доступный в центре загрузок iis.net (iis.net/downloads/?tab >

Рис. 4. Регулировки скорости уменьшает использование полосы пропускания

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

Кэширование выводимых данных

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

До IIS 7.0, как IIS, так и ASP.NET предоставляли возможности кэширования в форме кэша ядра IIS и кэша вывода ASP.NET. Кэш ядра IIS обеспечивал максимальную производительность, но ограничивался преимущественно статическим содержимым. Кэш вывода ASP.NET был гораздо более полным решением для кэширования динамического содержимого, за исключением более низкой производительности и менее эффективного управления памятью. Новый кэш вывода в IIS 7.0 ликвидирует разрыв между кэшем ядра IIS и кэшем вывода ASP.NET.

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

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

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

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

Но выполнение этой сложной работы почти всегда оправдано. Реализация кэша вывода IIS 7.0 позволяет в несколько раз улучшить общую пропускную способность приложения и соответственно уменьшить нагрузку на базу данных и компоненты уровня предприятия.

Преобразование кода ISAPI в модули IIS 7.0

В IIS 7.0 появился новый серверный интерфейс API, на котором основаны все модули IIS 7.0. Он заменяет устаревшие интерфейсы API ISAPI Filter и ISAPI Extension, использовавшиеся в предыдущих версиях IIS. Для новых модулей, которым не требуется поддержка предыдущих версий, новые API более просты в использовании, позволяют улучшить надежность серверного кода и гораздо более эффективны.

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

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

Помимо этого, API модуля IIS позволяет модулям асинхронно выполнять длительные операции, такие как получение данных объекта запроса и отправка ответа. Асинхронное выполнение этих задач позволяет серверу масштабироваться до большого количества одновременно клиентов (десятки тысяч) вместо прежнего максимального количества в несколько десятков или самое большое нескольких сотен одновременных клиентов из-за ограничений количества потоков запросов. Асинхронная обработка также может устранить эффект обработки на других запросах и действиях в приложении, снизить загрузку памяти и обеспечить гораздо лучшее использование ЦП.

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

Для этого могут быть необходимы определенные эксперименты и прототипы для определения оптимальной архитектуры, наилучшим образом использующую улучшения перехода. Из-за фундаментальных архитектурных различий ISAPI и API модуля IIS 7.0 прямой маршрут переноса не всегда является верным. Хорошая новость заключается в том, что API модуля IIS 7.0 также более прост в использовании, чем ISAPI, что упрощает переход.

Расширяемость сервера

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

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

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

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

Заключение

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

Поиск причин низкого быстродействия Битрикс

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

Сервер

Администрирование — Настройки — Инструменты — Проверка системы. Здесь не должно быть значений выделенных красным цветом.

Администрирование — Настройки — Производительность — Сервер БД. Здесь не должно быть значений выделенных красным цветом.

Администрирование — Настройки — Производительность — Панель производительности — Вкладка Конфигурация — Тестировать конфигурацию. Здесь стоит обратить внимание на параметры ниже эталонных. Среди прочих в таблице есть строка «Конфигурация» в которой отображаются некие битрикс-попугаи они сильно зависят от сервера, а от Вашего проекта единственное, что может негативно повлиять, это плохо организованный init.php. Для серверов с PHP 5.6 и ниже этот показатель ниже 30 — признак плохо сконфигурированного сервера, для PHP7 и выше плохой уровень уже около 50 битрикс-попугаев.

Администрирование — Настройки — Производительность — Панель производительности — Вкладка Битрикс. Здесь не должно быть написано «Не оптимально»

Администрирование — Настройки — Производительность — Панель производительности — Вкладка Масштабируемость. Запустите тестирование. Показатели сильно зависят и от сервера и от качества разработки вашего проекта. Здесь обратите внимание на график. Если график имеет много глубоких провалов — это, скорее всего, показатель не качественного хостинга.

Настройки сайта

Администрирование — Настройки — Настройки продукта — Настройки модулей — Главный модуль — блок «Оптимизация CSS». Желательно, чтобы были включены все опции. Как правило, их отключают если в скриптах есть косяки. После включения проверьте работу функционала сайта.

Администрирование — Настройки — Настройки продукта — Автокеширование. Кеширование компонентов и управляемый кеш должны быть включены. Отключением этого функционала некоторые горе-разработчики скрывают ляпы разработки. Если вам разработчик заявляет «этот функционала сырой, глючный и ненужный», то сразу гоните его от своего проекта — это дилетант. Кеш не нужен только в одном случае — весь контент вашего сайта ежесекундно полностью изменяется. После включения проверяйте сайт — заходите по несколько раз на каждый тип страниц и смотрите весь ли контент на месте (включая заголовки страницы, meta-теги).

Администрирование — Настройки — Настройки продукта — Композитный сайт — Настройки. Этот функционал желательно включать. Иногда при включении проявляются косяки верстки (например не закрытые теги).

Модули

Данный блок лучше тестировать на копии сайта и перед повторением на боевом — не забывайте выполнять резервное копирование.

Администрирование — Настройки — Настройки продукта — Модули. При развертывании Битрикс активирует все модули, чтобы сразу работал весь функционал. На конкретном проекте некоторые модули могут не использоваться. На этой странице можно отключить не нужны. Только проверяйте работоспособность после отключения или пропускайте если не уверены в назначении.

Администрирование — Marketplace — Установленные решения. Здесь так же могут быть лишние модули, особенно на проектах с историей где сменилось много разработчиков. Оставшиеся модули так же стоит оценить на качество кода. К сожалению встречаются написанные крайне безграмотно.

Настройки компонентов и выявление тяжелых

Режим отладки. В публичной части сайта, авторизовавшись пользователем с правами администратора. На панели инструментов Битрикс нажмите «Отладка». Около каждого компонента и для все страницы будет отображено время выполнения и количество запросов. Запросы можно просмотреть. После этого сбросить кеш (кнопкой на панели), и опять оценить параметры. В первом случае, данные берутся из кеша, во втором кеш создается. Следовательно, тут можно оценить настройку кеширования. В первом случае запросов должно быть на страницу значительно меньше ем во втором. На компоненты с большим числом запросов и временем исполнения следует обратить внимание.

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

Администрирование — Настройки продукта — Настройки модулей — Монитор производительности. Включаете Вести журнал медленных запросов, предупреждения PHP. Запускаете тестирование чем дольше тем лучше — главное чтоб посетители были и сами пройдитесь по всему сайту. По прошествии времени можно оценивать результаты.

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

Администрирование — Настройки — Производительность — Кеширование. Здесь стоит обратить внимание на компоненты создающие большой по размеру кеш.

Администрирование — Настройки — Производительность — Ошибки PHP. Здесь желательно избавиться от всех ошибок. К сожалению среди записей много нотисов от ядра.

Анализ времени отдачи страницы

Администрирование — Настройки — Производительность — Скорость сайта. Здесь время работы сайта стоит оценивать в динамике. Утрировано говоря если у вас долго не было посетителей, а потом зашла 1000 из тундры с допотопных телефонов через GPRS. Скорость будет очень низкой. Более информативным на этой странице является график «Последние посещения сайта». Здесь можно увидеть на чем теряется время при загрузке странице в браузере посетителя. Так, например, большое время на «Обработку HTML» стоит уделить внимание оптимизации верстки.

Нагрузочное тестирование vs Тестирование производительности

Сегодня мы немного поговорим про теорию тестирования. Очень часто можно услышать вопрос: «Как же правильно говорить: Нагрузочное тестирование или Тестирование производительности? И чем одно от другого отличается?». В русскоязычной среде термины «Нагрузочное тестирование» и «Тестирование производительности» перепутаны, и не всегда понятно откуда что взялось.

Введение

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

Тестирование производительности (Performance Testing)

Считается, что тестирование производительности [1] — это то тестирование, которое не является функциональным. Существует множество видов тестирования производительности. Классификация видов тестирования производительности строится на основе того, какие цели преследует определенный вид тестирования. Как правило тестирование производительности преследует не одну, а несколько целей в связи с тем, многие типы тестирования в ходе его проведения совмещаются с другими целями или повторяются несколько раз в ходе цикла тестирования. Основное отличие тестирования производительности также заключается в том, что оно происходит только после полного функционального тестирования. Ошибки функциональности не исправляются в ходе тестирования производительности. Для данного вида тестирования чаще всего выделяется отдельный нагрузочный стенд, повторяющий копию промышленного стенда. В связи с массовым распространением Agile методологий тестирование производительности также интегрируется в жизненный цикл разработки программного обеспечения.

На рисунке ниже показана основная классификация видов тестирования производительности.

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

Нагрузочное тестирование (load testing)

Нагрузочное тестирование (load testing) — данный тип тестирования позволяет оценить поведение системы при возрастающей нагрузке, целью нагрузочного тестирования является также определение максимальной нагрузки, которую может выдержать система.

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

Рассмотрим его подробнее: В роли нагрузки может выступать количество пользователей, а также количество операций на сервере.

Производительность при этом определяется следующими факторами:

• скоростью работы программного обеспечения;
• скоростью работы аппаратного обеспечения;
• скоростью работы сети.

Во время тестирования могут осуществляться следующие операции, позволяющие более точно измерить производительность и определить «узкое место» системы [12]:

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

После нахождения максимальной производительности рекомендуется её «подтвердить». Для этого проводится дополнительный тест со следующим профилем:

Тестирование стабильности (stability testing)

Тестирование стабильности (stability testing) — позволяет проверить работоспособность системы на длительном интервале времени. При этом нагрузка может не достигать пиковых значений, а иметь средние значение, так же само время выполнения операций не являет основным фактором в оценке результатов тестирования.

В ходе тестирования основной акцент делается на измерение

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

Тестирование отказоустойчивости (failover testing)

Тестирование отказоустойчивости (failover testing) — данный вид тестирования производительности позволяет проверить поведение системы в случает сбоя серверов или при других неблагоприятных факторах. Такое тестирование особенно важно в системах, работающих в режиме 24/7, т.к. в случае их выхода из строя возможны потери клиентов, репутации, денег и т.п.

Во время тестирования проверяются следующие операции:

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

Тестирование восстановления (recovery testing)

Тестирование восстановления (recovery testing) — обычно неотъемлемо связан с тестированием отказоустойчивости и позволяет определить, как быстро система сможет восстановится после сбоя её программной или аппаратной части. Сам сбой производится тестировщиком путём отключения, например, одного из серверов или его перезагрузки. Тестирование не нацелено на проверку надёжности системы. При этом нагрузка на систему не уменьшается и имеет средние или пороговое значение.

В ходе тестирования измеряются следующие показатели:

• время, за которое система восстановится после сбоя;
• корректность восстановленных данных.

Стрессовое тестирование (stress testing)

Стрессовое тестирование (stress testing) — целью данного вида тестирования производительности является оценка производительности системы при пороговых значениях рабочей нагрузки или за её пределом. Также в ходе тестирования можно оценивать работу системы при изменении ресурсов доступных системе таких как процессорное время, память, ширина сетевого канала и т.д.

В ходе тестирования измеряется:

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

Тестирование объемов (volume testing)

Объемное тестирование (volume testing) — тестирование позволяет оценить производительность системы при увеличении объёмов данных как самого приложения, так и его базы данных. Основной вопрос, на который отвечает данный вид тестирования производительности: «Что будет завтра с этим приложением или через год при увеличении числа пользователей и/или увеличение хранимых пользовательский и системных данных?».

Во время тестирования измеряются следующие параметры:

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

Тестирование масштабируемости (scalability testing)

Тестирование масштабируемости (scalability testing)[13] — данное тестирование производится для проверки возможностей масштабирования приложения под любым видом нагрузки. Также необходимо проверять производительность системы во время масштабирования.

Виды масштабирования, которые проверяются в ходе тестирования:

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

Тестирование потенциальных возможностей (capacity testing)

Тестирование потенциальных возможностей (capacity testing) — является отчасти подвидом тестирования масштабируемости. Если в тестирование масштабируемости основной вопрос, который ставится: насколько хорошо справляется система с возрастающим количеством пользователей (нагрузки). То в данном случае вопрос звучит следующим образом: сколько пользователей (с какой нагрузкой) может работать с системой при этом время отклика и другие параметры производительности должны находится в пределах допустимых значений? Данный вид тестирования позволяет определить стратегию масштабирования и вообще понять, а стоит ли масштабировать систему?

Конфигурационное тестирование (configuration testing)

Конфигурационное тестирование (configuration testing) [14] — данный вид тестирования проверяет производительность системы на разных аппаратных и программных конфигурациях. В ходе тестирования измеряются основные показатели производительности системы при средних и пороговых значениях нагрузки. Данное вид тестирования производительности позволяет убедится, что на других конфигурациях аппаратного и программного обеспечения система будет работать с одинаковой производительностью.

Тестирования сравнения (compare testing)

Тестирования сравнения (compare testing) — позволяет сравнить производительности на разной конфигурации программной и аппаратной части системы. Данное тестирование помогает выбирать наиболее оптимальную конфигурацию аппаратного и программного обеспечения. В ходе тестирования производится проверка на разных конфигурациях, при этом профиль тестирования не изменяется от конфигурации к конфигурации и имеет среднюю или пороговую интенсивность нагрузки.

Тестирование позволяет ответить на такие вопросы как:

• какую СУБД выбрать?
• какое оборудование выбрать (платформа, производитель, цена и т.д.)?
• как повлияют на работу приложения обновления и патчи?

Выводы

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

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

Asp проверка быстродействия и масштабируемости

до 1.4

Ниже дано подробное описание условий тестирования и результатов по каждому тесту.

Производительность и масштабируемость при одновременной работе большого количества пользователей

В данном тесте оценивалась масштабируемость системы 1с предприятие 8 при одновременной работе большого количества пользователей, то есть ее способность справляться с поступающим объемом информации за приемлемое время.

При заданных условиях тестирования 1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности и масштабируемости по сравнению с 1С:Предприятием 8. Так пропускная способность системы при одновременной работе 200 пользователей выросла почти в 1.5 раза, а время записи и проведения документа составило менее 3.5 секунд.

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

Условия тестирования

Тестирование проводилось на примере документа РеализацияТоваровУслуг типовой конфигурации УПП 1.2. При помощи 1С:ТестЦентра был описан многопользовательский сценарий тестирования со следующими параметрами:

• Количество одновременно работающих пользователей: от 1 до 200
• Выполняемая операция: создание и проведение нового документа РеализацияТоваровУслуг
• Количество строк в табличной части «Товары»: 20
• Каждый тестовый пользователь создает документы со своим уникальным набором товаров, то есть все движения документов записываются параллельно, не приводя к блокировкам.
• Количество строк в табличной части «Услуги»: 0
• Пользователи вводят документы с паузой 60 секунд
• Расчет себестоимости списываемых товаров не производится (в выбранном режиме используется механизм регламентного расчета себестоимости).

Следует отметить, что смоделированная нагрузка на систему значительно превышает нагрузку, которая наблюдается в реальных условиях. По результатам опроса обычный пользователь вводит в среднем 300 строк документа в час. В данном тесте при одновременной работе 200 пользователей на 1С:Предприятии 8.1 тестовый пользователь вводил 965 строк в час, то есть интенсивность его работы была выше в 3.2 раза.

Во время проведения документа система выполняла следующие действия:

• Движения по разделам управленческого учета:
  • Взаиморасчеты с контрагентами: увеличение фактической задолженности контрагента
  • Продажи: увеличение объема продаж по предприятию
  • Списание товара со склада предприятия с контролем достаточности остатка товаров
  • Снятие резерва, выполненного под заказ покупателя с контролем достаточности резерва
• Движения по разделам регламентированного учета
  • Списание товара принадлежащего организации с контролем достаточности остатка товаров
  • Расчеты с контрагентами: увеличение оперативной задолженности контрагента
• Отражение списания товаров для целей партионного учета
• Движения по разделам бухгалтерского и налогового учета:
  • Движения по регистрам подсистемы НДС
  • Формирование проводок по бухгалтерскому и налоговому учету:
    • По выручке (бухгалтерский и налоговый учет)
    • По НДС (бухгалтерский учет)
    • По взаиморасчетам (бухгалтерский учет)
    • По суммовым разницам (бухгалтерский и налоговый учет)
    • По курсовым разницам (бухгалтерский учет)

При проведении тестирования измерялись следующие показатели производительности:

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

Тестирование проводилось на следующем тестовом стенде:

• Сервер 1С:Предприятия:
  • Процессоры: 2 * Intel Xeon MP, 2800 МГц
  • Оперативная память: 4 096 Мб
  • Дисковая подсистема: 2 * Ultra320 SCSI RAID 0 (stripe)
• Сервер MS SQL 2000 SP4:
  • Процессоры: 2 * DualCore Intel Xeon, 2666 МГц
  • Оперативная память: 8 192 Мб
  • Дисковая подсистема: 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)

Результаты

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

Рассмотрим диаграмму зависимости количества строк документов, обрабатываемых системой в единицу времени, от количества одновременно работающих тестовых пользователей для 1С:Предприятия 8 и 8.1:

При одновременной работе 200 тестовых пользователей на данном тесте пропускная способность системы на платформе 1С:Предприятие 8.1 составила более 190 000 строк документов в час, что почти в 1.5 раза выше соответствующего показателя для 1С:Предприятия 8.

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

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

При увеличении количества одновременно работающих пользователей в 10 раз (с 20 до 200) относительная пропускная способность системы на платформе 1С:Предприятие 8.1 уменьшается всего на 4.6%. То есть, подключение к системе новых пользователей практически не отражается на общей производительности системы.

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

Рассмотрим диаграмму зависимости среднего времени записи и проведения документа от количества одновременно работающих тестовых пользователей для 1С:Предприятия 8 и 8.1:

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

Таким образом, 1С:Предприятие 8.1 демонстрирует значительно лучшую масштабируемость по сравнению с предыдущей версией на тесте с параллельным вводом документов большим количеством пользователей.

Производительность и масштабируемость при пиковых нагрузках

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

В условиях пиковой нагрузки 1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности по сравнению с 1С:Предприятием 8. Пропускная способность системы выросла в 2.3 раза, а среднее время проведения одного документа сократилось в 2.4 раза.

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

Для оценки эффекта от использования кластера серверов, тестирование в условиях пиковой нагрузки было проведено для кластера из 2-х рабочих процессов 1С:Предприятия 8.1, расположенных на разных компьютерах. В этом тесте пропускная способность системы на платформе 8.1 по сравнению с 8 выросла в 3.8 раз, а время проведения документа сократилось во столько же.

Условия тестирования

Тестирование проводилось на примере документа РеализацияТоваровУслуг типовой конфигурации УПП 1.2. Параметры данного теста были идентичны предыдущему за следующими исключениями:

• Количество одновременно работающих пользователей: 20
• Пользователи вводят документы без паузы
• Количество строк в табличной части «Товары»: 5

Тестирование проводилось на следующем тестовом стенде:

• Сервер 1С:Предприятия (для работы без кластера и для процесса 1 в кластере):
  • Процессор: DualCore Intel Xeon MP, 3000 МГц
  • Оперативная память: 8 192 Мб
  • Дисковая подсистема: 4 * Ultra320 SCSI RAID 0 (stripe)
• Сервер 1С:Предприятия (для процесса 2 в кластере):
  • Процессор: 2 * Intel Xeon MP, 2800 МГц
  • Оперативная память: 8 192 Мб
  • Дисковая подсистема: 8 * Ultra320 SCSI RAID 0 (stripe)
• Сервер MS SQL 2000 SP4:
  • Процессоры: 2 * DualCore Intel Xeon, 2666 МГц
  • Оперативная память: 8 192 Мб
  • Дисковая подсистема: 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)

Результаты

Тестирование 1С Предприятие 8 на пиковых режимах позволяет оценить ее работоспособность и производительность в ситуации резкого увеличения нагрузки до предельных значений. Хорошо мастабируемая система в таких условиях должна демонстрировать устойчивую работу и приемлемое время выполнения операций.

Рассмотрим диаграмму фактической пропускной способности системы (строк документов в час) при использовании 1С:Предприятия 8, 1С:Предприятия 8.1 без использования кластера и 1С:Предприятия 8.1 с использованием кластера из 2 рабочих процессов.

Пропускная способность (строк в час)

Производительность и масштабируемость системы «1С:Предприятие»: от 7.0 до 8.next

Начав в 2003 г. активное продвижение следующего поколения решений «1С:Предприятие» 8 на относительно новом для себя рынке корпоративных клиентов, фирма «1С» (http://www.1c.ru) оказалась, на наш взгляд, в необычном для себя положении. До того компания традиционно выступала технологическим «локомотивом» для своих потребителей из сектора малого бизнеса: ее разработчики постоянно опережали (но не намного, чтобы не оторваться) текущие потребности клиентов. На среднем рынке ситуация иная — у заказчиков уже давно сформировались в целом высокие требования к ИТ, а к появлению новых поставщиков здесь относятся достаточно настороженно.

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

Если же говорить о технологических проблемах развития экономического ПО «1С», то, безусловно, одна из главных задач (хотя, конечно, далеко не единственная) — это повышение производительности и масштабируемости (ПиМ) ее прикладных решений. О том, что «1С» признает важность этих вопросов, говорит хотя бы тот факт, что сама фирма после выпуска четыре года назад платформы «1С:Предприятие» 8.0 начала регулярно официально знакомить ИТ-общественность с результатами тестирования в этой области. Показательно и то, что первое существенное технологическое обновление платформы «1С:Предприятие» 8, выпуск новой версии 8.1, было связано в значительной степени именно с решением задач масштабирования и производительности (см. статью «Платформа «1С:Предприятие 8.1» уже на подходе, «BYTE/Россия» № 9’2006).

Обсуждение хотелось бы начать с рисунка, который в целом иллюстрирует рост производительности платформы «1С:Предприятие», начиная с версии 7.x (рис. 1). Но прежде нужно сделать два существенных замечания.

1. На графике приведены значения АРПмакс: это не просто число работающих пользователей, а максимальное число активно работающих пользователей (подробнее об этом речь пойдет ниже).

2. Все оценки предельных показателей производительности «1С:Предприятие» разных версий — это личные оценки автора (а не фирмы «1С»), полученные путем обобщения имеющихся у него сведений. Анализ более обширного фактического материала может дать несколько иные результаты. Однако задача этой работы состояла не в том, чтобы определить абсолютные показатели сами по себе, а в том, чтобы проанализировать общую логику развития возможностей производительности и масштабирования платформы «1С:Предприятие».

Рис. 1. Рост производительности платформы «1С:Предприятие» (оценки автора).

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

Производительность и масштабируемость — общие соображения

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

Производительность

Понятие производительности ERP-систем связано со способностью выполнения транзакций в многопользовательском режиме. В этом плане важны две основные характеристики: общее число транзакций в единицу времени и время исполнения одной транзакции (имеется в виду, что транзакции выполняются параллельно)*. Однако обе эти характеристики динамические — они зависят от числа поступающих запросов на транзакции, а применительно к традиционным внутрикорпоративным ERP-решениям — от числа активно работающих пользователей (АРП)**.

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

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

Рис. 2. Общий характер роста производительности ERP-системы.

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

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

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

Рис. 3. Графики роста производительности при разной интенсивности запросов.

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

Рис. 4. Изменение производительности при подключении пользователей-аналитиков.

Следует также разобраться, что мы понимаем под термином «ERP-система», делая акцент на слове «система». Здесь возможны три основных варианта ответа:

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

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

Рис. 5. Диапазон производительности платформы — это результат статистической обработки данных, полученных в конкретных проектах.

Таким образом, нужно четко разделять два разных применения показателя АПРмакс: для конкретного ИТ-проекта и для базовых технологий. В первом случае он всегда имеет довольно узкий диапазон значений (например, 120—140), во втором — существенно более широкий (80—250).

Возвращаясь к теме ПиМ, отметим, что стратегическая задача состоит в расширении диапазона АПРмакс в рамках приемлемых стоимостных показателей — с точки зрения как вендора (это определяет спектр покрытия клиентского рынка), так и заказчика (в плане развития его конкретной системы). Мы сознательно не рассматриваем здесь вопрос о нижней границе применимости технологии: понятно, что с технической точки зрения она всегда равна 1. А с точки зрения заказчика она определяется чаще всего соображениями стоимости: можно в принципе поставить SAP R/3 для обслуживания одного человека, но мало кто в состоянии позволить себе такую роскошь.

Масштабируемость и масштабирование

Довольно часто, говоря о масштабируемости программной системы, на самом деле имеют в виду ее способность адекватно (линейно) повышать производительность в условиях увеличения потока запросов на обработку. Но такое представление неверно. Правильное определение звучит примерно так: «Масштабируемость — это способность системы увеличивать свою производительность за счет подключения дополнительных вычислительных ресурсов, как аппаратных, так и программных». Соответственно масштабирование — это способ повышения производительности системы за счет ее масштабируемости.

Проиллюстрируем эти положения на примере работы Web-сервера, вычислительные показатели которого также описываются графиком на рис. 2. Но отражает ли линейный участок роста его производительности (до АРПмакс) характеристику масштабируемости? Вообще говоря, нет: в этом случае речь идет не о подключении дополнительных ресурсов, а скорее о повышении КПД имеющегося оборудования. А вот когда наш Web-сервер подходит к пределу своей производительности в данной аппаратно-программной конфигурации, тут и встает вопрос о его масштабируемости — за счет наращивания памяти, числа процессоров, использования кластеров и т. д. Таким образом, применительно к программе масштабируемость подразумевает не столько увеличение производительности, сколько повышение предела производительности (т. е. того самого показателя АРПмакс).

В определении масштабируемости говорится об увеличении вычислительных ресурсов. Под ними мы чаще всего подразумеваем аппаратные компоненты системы (расширение памяти, увеличение мощности процессора и числа процессоров, создание кластеров и т. д.). Но не надо забывать и о возможности совершенствования программной части — как ее отдельных элементов (например, за счет применения более мощных СУБД), так и базовой платформы в целом (если вендор готов к подобному развитию своих технологий). Применительно к «1С:Предприятие» это может быть переход от файлового варианта к клиент-серверному, от платформы 8.0 к 8.1.

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

ПиМ для клиент-серверной архитектуры

Однако вернемся к ERP-системе, реализованной в клиент-серверной архитектуре (в данном случае на базе «1С:Предприятие»). Тут понятие масштабируемости выглядит несколько иначе: прежде всего нужно довольно четко разделять клиентскую и серверную части системы.

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

Но по мере своего развития (а иногда и на этапе ввода в эксплуатацию) система заказчика подходит к своему значению АРПмакс. Что же делать? К сожалению, порой только в этот момент заказчик задумывается: а что представляет собой его ERP-система в архитектурном плане? Например, как реально распределяется обработка запросов между клиентом и сервером? А следовательно — мощность каких вычислительных ресурсов нужно наращивать для преодоления достигнутого барьера? И есть ли реальная возможность повышения мощности аппаратуры, которое дало бы адекватный прирост производительности системы в целом?

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

Не только масштабирование

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

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

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

Мнение эксперта

Новые возможности платформы — новые требования к специалистам

Андрей Волков,
руководитель отдела типовых решений, ООО «ИТРП»

Компания «Институт типовых решений — Производство» (ИТРП, http://www.itrp.ru) работает на рынке средств автоматизации предприятий с 2000 г., специализируясь в области разработки и внедрения тиражных продуктов для производственных предприятий на основе различных версий платформы «1С:Предприятие». На базе версии 8 мы разработали успешно введенные в промышленную эксплуатацию продукты «ИТРП:Производственное предприятие 8. Стандарт», «ИТРП:Процессное производство 8», «1С:Производство строительных материалов».

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

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

Из всего сказанного следует, что повышение производительности разрабатываемых конфигураций предъявляет более высокие требования к программистам и внедренцам. В частности, они должны разбираться в особенностях архитектуры и реализации механизмов «1С:Предприятие 8», критичных с точки зрения поддержки работы большой информационной системы, в особенностях и новых возможностях версии 8.1, таких, как механизм управления блокировками. Необходимы также навыки использования ПО «1С:ТестЦентр» и наличие в команде разработчиков специалистов, имеющих аттестат «1С:Эксперт по технологическим вопросам». Со всем этим не раз сталкивались наши эксперты как в ходе разработки широко тиражируемых решений, так и в ходе конкретных проектов внедрения.

Технологии «1С» и средний бизнес

Тернистый путь наверх

В той или иной мере, но задача повышения ПиМ прикладных систем на базе «1С:Предприятие» в условиях роста нагрузки решалась всегда. Но в силу исторических причин ранее, до выхода версии 8.0, эта задача выполнялась фактически исключительно способами реинжиниринга, так как возможности масштабирования были минимальны. С выходом «1С» на корпоративный рынок в технологическом отношении на первом плане оказалась именно проблема повышения масштабирумости и более того — снижения зависимости от технологического реинжиниринга при реализации конкретных проектов.

Имея в виду стратегическую задачу выхода на более высокий уровень заказчиков, разработчики «1С» после выпуска версии 7.0 могли следовать сценарию эволюционного развития с учетом своих традиционных технологий или пойти путем создания решений для среднего бизнеса на какой-то качественно иной архитектурной базе. Вероятно, оба варианта могли оказаться успешными, но «1С» выбрала первый, жизнеспособность которого убедительно продемонстрировали в 90-х гг. Microsoft и Intel. И, естественно, столкнулась при этом с необходимостью решения тех же проблем, что и ее предшественники, — в частности, проблемы унаследованных архитектурных ограничений.

В новой версии платформы «1С» серьезно скорректировала архитектуру системы, пойдя на нарушение информационно-программной совместимости с версией 7.7. Но ключевой (на наш взгляд) идеологический подход остался прежним, и в контексте темы ПиМ тут стоило бы выделить два момента: выполнение основной вычислительной обработки на клиентской части, а также четкое деление системы ПО на две самостоятельные составляющие: технологическая платформа (среда исполнения и средства разработки) и прикладные решения на ее основе.

Конечно, подобное деление (платформа и решение) в том или ином виде имеется у любого разработчика крупной программной системы. Но только «1С» довела этот подход до логического конца: она полностью уравняла в возможностях разработки и модификации прикладных решений своих собственных и внешних разработчиков. Напомним также, что программные продукты «1С» всегда поставлялись в исходных кодах (отличная иллюстрация того, что open source и бесплатное ПО — это в общем случае две разные категории). Таким образом, все желающие (партнеры, заказчики) могут не просто дорабатывать прикладные решения, но и изменять их на уровне базовой бизнес-логики, а также создавать собственные «с нуля».

Став в свое время на этот путь, «1С» радикально решила вопрос гибкости настройки и расширения своих приложений, делегировав эти полномочия широким массам партнеров и клиентов. Но при этом нужно было помнить о другой стороне вопроса — обеспечении надежности и устойчивости работы программ, особенно учитывая тот факт, что средняя квалификация десятков тысяч специалистов в компаниях-франчайзи не столь высока, как в элитной команде разработчиков «1С».

Тут надо сказать, что уже много лет традиционный упрек ряда экспертов в адрес ПО «1С» (версии 7.x) заключается в использовании не слишком эффективного, с их точки зрения, механизма обработки параллельных запросов к базам данных, что создает очевидное препятствие для повышения мощности прикладных систем «1С» в целом. Мы не будем сейчас обсуждать технические аспекты этой темы, изначально неоднозначной и дискуссионной, но хотелось бы высказать одно соображение. Достаточно жесткий механизм блокировок доступа вполне оправдан с точки зрения надежности функционирования прикладного решения в условиях возможной коррекции его программного кода специалистами, квалификация которых на массовом рынке варьируется в довольно широком диапазоне.

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

И еще одно важное следствие: усиление мощности базовых технологий «1С» во многом связано с предоставлением более гибких и широких возможностей на уровне прикладного ПО. Это, в свою очередь, опять же повышает квалификационные требования к разработчикам и внедренцам.

Средний рынок — что тут нового

Вопросы ПиМ для фирмы «1С» непосредственно связаны с ее продвижением на корпоративный рынок средних и крупных заказчиков.

С точки зрения ИТ для характеристики «среднего рынка», наверное, лучше использовать подход (его придерживается, в частности, Microsoft), согласно которому к категории средних относятся предприятия с числом установленных ПК в диапазоне от 25 до 500 (midmarket). При этом выделяются две группы: 25—50 ПК (lower) и 50—500 (upper), что принципиально важно. В организациях первой группы, как правило, нет выделенного штатного ИТ-специалиста, и большинство ИТ-решений принимает непосредственно руководитель компании. У upper-компании уже есть хоть и небольшое, но выделенное ИТ-подразделение, которое в той или иной степени причастно к реализации проектов, а его руководитель напрямую участвует в выработке решений. ИТ-решения принимаются на основе долгосрочного планирования, в увязке с состоянием и перспективой развития ИТ-инфраструктуры предприятия в целом.

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

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

Что же касается проблематики ПиМ, то она крайне важна именно для среднего рынка в силу динамичности развития его игроков и соответственно расширения круга и масштаба решаемых ими ИТ-задач.

Динамика развития от 7.0 до 8.next

Версия 7.х, выход на средний рынок

Строго говоря, подготовка к выходу на lower-midmarket в «1С» началась 11 лет назад, когда летом 1996 г. фирма представила свой первый продукт нового поколения. Примечательно, что это была не традиционная «1С:Бухгалтерия», а «1С:Торговля», изначально ориентированная на многопользовательскую работу. Отметим и то, что ни о какой технологической платформе 7.0 тогда не было и речи — не потому что не было самой платформы, а потому что «1С» не хотела в те времена использовать подобные «громкие» слова, считая, что технические вопросы — это ее сугубо внутреннее дело. Тогда же впервые в дополнение к файл-серверному варианту системы появился двухзвенный клиент-серверный, реализованный на базе СУБД Btrieve, на смену которому два года спустя пришла система в составе «1С:Предприятие» 7.5 и Microsoft SQL Server 6.5. А за точку отсчета для начала серьезной работы на lower-midmarket, наверное, стоит принять лето 1999 г., когда на рынке появились «1С:Предприятие» 7.7 и Microsoft SQL Server 7.0 (известный в те времена проект «777»), для применения которых уже «созрели» и заказчики, и партнеры.

Однако примечательно, что вопросы ПиМ применительно к «1С:Предприятие» версии 7 сама «1С» никогда не поднимала. Даже говоря о достоинствах клиент-серверного варианта, специалисты фирмы осторожно советовали применять эту схему при числе пользователей более 10—15, но какие-то верхние пределы никогда не назывались. Никаких публичных сравнений показателей работы клиент-сервера и файл-сервера также не проводилось; более того, подчеркивалось, что преимущества первого варианта заключаются не столько в более высокой производительности, сколько в увеличении надежности системы.

Какие-то внутренние тестовые исследования производительности наверняка имели место, но все же основная стратегия «1С» в этом вопросе тогда сводилась скорее к «разведке боем» — проверке возможностей своего ПО путем практической реализации проектов партнерами. Этот опыт показал, что на базе «1С:Предприятие» 7 можно создавать системы с числом АРП примерно от 25 до 70. Но для этого требовались достаточно серьезные усилия со стороны внедренцев, и такие задачи были по силам уже далеко не всем партнерам.

Сама «1С» отмечает, что на базе «1С:Предприятие» версии 7 были реализованы и более масштабные проекты — с числом рабочих мест более 100 (есть пример на 370 рабочих мест). Правда, остается вопрос — это просто подключенные клиенты или «активно работающие»? Но в целом специалисты «1С» признают: реализация проектов на базе версии 7 с числом рабочих мест более 30—50 требовала от внедренцев достаточно серьезных усилий.

Ограничения роста производительности двухзвенной системы клиент-сервер были вполне понятными, так как фактически она представляла собой лишь более совершенный вариант файл-серверной системы. В принципе современные СУБД могут использоваться для исполнения бизнес-логики, но в силу архитектурных особенностей «1С:Предприятие» 7 эти возможности «1С» просто не могла задействовать. В этой ситуации даже повышение мощности сервера СУБД (например, за счет использования многопроцессорных компьютеров) не приводило к заметному изменению общей производительности системы.

Для понимания причин этого нужно иметь в виду, например, что «1С:Предприятие» 7 была изначально построена по схеме блокировок на уровне таблиц и реализации бизнес-логики обработки запросов к БД на клиентской части. Объяснить выбор такой простой архитектуры обмена данными довольно легко: в тот момент обеспечение надежной работы сложных прикладных решений на массовом рынке было важнее повышения производительности.

Впрочем, были, конечно, реинжиниринговые методы повышения производительности, которые уже выходят за рамки применения стандартной клиент-серверной схемы «1С:Предприятие» 7. Частый случай — использование терминального режима работы (Windows Terminal Server). Но, строго говоря, данный вариант предполагал не столько повышение производительности, сколько оптимизацию затрат на оборудование. Более радикальный подход — использование распределенных баз данных, когда единая система разбивается на несколько автономных подсистем (например, однородных, но географически распределенных или локальных, но неоднородных), которые могут работать в основном в автономном режиме, периодически взаимодействуя между собой и синхронизируя общие массивы данных. Однако нужно иметь в виду, что в этих случаях речь идет о реализации достаточно сложных проектов, в успехе которых ключевая роль отводится квалификации внедренцев. При этом применение методов реинжиниринга имеет свои очевидные ограничения.

Версия 8.0, переход на upper-midmarket

При создании платформы «1С:Предприятие» 8, в отличие от версии 7, задача повышения ПиМ уже была определена в качестве одной из главных. Вопросы ПиМ применительно к версии 8 довольно часто связываются с реализацией трехзвенной архитектуры и появлением сервера «1С:Предприятие» 8. Но такой взгляд не совсем верен. Возможности улучшения ПиМ в данном случае обеспечиваются за счет серьезной переработки внутренней архитектуры платформы, что и сделало реальностью создание сервера «1С:Предприятие» 8.

Говоря о платформе «1С», мы часто упоминаем о том, что ее развитие во многом определяется требованиями поддержки унаследованных решений, существенно ограничивающими свободу действий разработчиков. Но этот тезис требует уточнения. Дело в том, что при переходе от 7.7 к 8.0 «1С» как раз нарушила совместимость прикладных решений — как по данным, так и по программному коду, — но при этом сохранила верность некоторым базовым концепциям 7.7.

Могла ли «1С» пойти на более радикальные изменения ради более успешного продвижения в сегмент корпоративных клиентов (и нужно ли это было делать)? Это вопрос спорный, а главное, сегодня он уже носит сугубо теоретический характер. Но совершенно очевидно, что, принимая стратегические решения о путях развития своего ПО, руководство компании учитывало проблему «наследственности», выходящую за рамки чисто технических вопросов. Тут в первую очередь нужно иметь в виду готовность к подобным инновациям партнерской сети «1С», этого краеугольного камня бизнес-модели компании.

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

Собственно, именно в версии 8.0 впервые появился достаточно серьезный механизм управления данными, который можно было размещать либо на клиентской части (для файлового варианта), либо на сервере. Соответственно масштабирование серверной части (сервер + СУБД) обеспечивалось двумя взаимодополняющими вариантами: использованием многопроцессорных конфигураций (реализация многопотоковой обработки на сервере и на СУБД) и разнесением сервера и СУБД на разные компьютеры.

Появление «1С:Предприятие» 8 позволило «1С» начать публичное обсуждение вопросов ПиМ своих технологий. Эта тема была обозначена уже при объявлении бета-версии в марте 2003 г., когда были впервые представлены результаты проведенного нагрузочного тестирования, в том числе и для версии 7.7. Из рис. 6 хорошо видно, что для последней клиент-серверный вариант имеет не слишком большое преимущество перед файловым. Отметим также, что архитектурные новшества 8.0 проявляются именно для трехзвенной клиент-серверной конфигурации.

Рис. 6. Результаты тестовых испытаний на этапе бета-тестирования «1С:Предприятие» 8.0 (Источник: «1С», апрель 2003 г.).

Более детальное исследование ПиМ было выполнено фирмой «1С» уже после выпуска рабочей версии 8.0. В целом результаты испытаний (рис. 7) достаточно хорошо демонстрировали не только архитектурные преимущества 8.0 перед 7.7 в плане повышения производительности для одной и той же аппаратной конфигурации (см. графики для версий 7.7 и 8.0-1), но и существенные возможности масштабирования в версии 8.

Рис. 7. Зависимость скорости обработки документов при многопользовательском вводе и различной конфигурации серверов. Обозначения: 7.7 — используется версия 7.7; 8.0-1-x — Microsoft SQL Server и сервер «1С:Предприятие» 8.0 размещаются на одном компьютере с числом процессоров соответственно х = 1, 2, 4; 8.0-2 — Microsoft SQL Server и сервер «1С:Предприятие» 8.0 размещаются на разных компьютерах, соответственно четырех- и двухпроцессорном (источник: «1С», декабрь 2003 г.)

И наконец, данные еще одного нагрузочного тестирования были представлены в феврале 2006 г. Но теперь уже тестировали не платформу, а флагманский корпоративный продукт «1С:Управление производственным предприятием», и изучалось не масштабирование, а только производительность (для одной аппаратной конфигурации) в различных нагрузочных условиях.

За счет чего же достигается масштабируемость на уровне сервера «1С:Предприятие»? Для ответа на этот вопрос выделим три основные функции данного компонента:

• механизм взаимодействия клиентского приложения с СУБД;
• исполнение бизнес-логики прикладных решений;
• общее управление системой (администрирование, управление правами, обеспечение безопасности и т. п.).

Последняя функция связана с вопросами ПиМ в минимальной степени, поэтому рассмотрим первые две.

Во всех приведенных выше исследованиях фактически изучались возможности масштабирования механизма взаимодействия с СУБД. Дело в том, что в версии 8.0 впервые появилась возможность распределить исполнение бизнес-логики между клиентской и серверной частью. Уже сейчас в типовых прикладных решениях на сервер переведены некоторые «тяжелые» операции обработки, но все же основная бизнес-логика пока сосредоточена на клиенте (сказывается унаследованная специфика архитектуры). Отметим, что перераспределение бизнес-логики можно выполнять и при реализации конкретных проектов, но эффект от этого следует изучать отдельно в каждом случае.

Однако с использованием сервера связан также вопрос надежности работы системы в целом. Мы не будем обсуждать характеристики «1С:Предприятие» 8 в плане отказоустойчивости, но отметим, что это важный вопрос, который требует отдельного изучения. Кроме того, нужно понимать относительность результатов нагрузочных тестирований, которые демонстрируют лишь основные возможности технологий и общие тенденции их развития. Для более серьезного исследования вопроса требуется технический анализ применения этих технологий в реальных проектах; сведений о публичных работах в этом направлении применительно к «1С:Предприятие» 8 пока нет.

Тем не менее даже самая общая информация о выполненных проектах на базе «1С:Управление производственным предприятием» 8.0 говорит о возможности реализации достаточно крупных систем. Есть примеры использования одного сервера «1С:Предприятие» 8.0 для подключения более 200 АРП, хотя средний уровень проектов характеризуется диапазоном 120—150. Есть и более крупные проекты на основе платформы 8.0 (с числом клиентов до 500 и более), но они реализованы в виде нескольких подсистем (с отдельным сервером) — автономных или распределенных баз данных.

Версия 8.1 — кластерный сервер

Итак, в «1С:Предприятие» 8.0 достигнут существенный прогресс в направлении ПиМ, но все же он недостаточен для полного охвата потребностей среднего рынка. В то же время корпоративный заказчик смог оценить возможности платформы, поверил в них и требовал «продолжения банкета». Форсированный выпуск в конце 2006 г. версии «1С:Предприятие» 8.1, в которой ПиМ была уже не «одной из», а главной задачей, стал ответом на эти потребности рынка.

В плане ПиМ в версии 8.1 нужно выделить два направления работ: усовершенствование уже существующих механизмов платформы и реализацию качественно новых возможностей.

Первое направление включало оптимизацию исполнения кода, написанного на встроенном языке, внутренней параллельности сервера «1С:Предприятие», обмена данными между клиентом и сервером, алгоритма записи движения документов и ряда других средств. Тут нужно особо выделить новые варианты работы с управляемыми блокировками транзакций: фактически разработчики «1С» наконец решились предоставить возможность переноса управления блокировками с уровня СУБД на уровень прикладных решений. Но повышение параллельности потребует доработок прикладных решений, а значит, результат оптимизации будет больше зависеть от квалификации разработчиков последних.

Принципиальное новшество в «1С:Предприятие» 8.1 — переработанная архитектура клиент-серверного варианта, которая помимо прочего теперь строится на использовании протокола TCP/IP (вместо COM+). Именно это обеспечило работу сервера под управлением не только Windows, но и Linux, а также реализацию кластера серверов «1С:Предприятие».

Если сервер «1С:Предприятие» 8 представлял собой один рабочий (хотя и многопотоковый) процесс, то теперь кластер серверов поддерживает параллельное функционирование нескольких таких процессов, которые, в свою очередь, могут работать как на одном компьютере, так и на разных (рис. 8). Управление этой структурой идет через центральное серверное приложение (менеджер кластера), которое распределяет нагрузки (клиентские соединения) между рабочими процессами. Простейший кластер содержит один рабочий процесс, исполняемый на одном компьютере, — в этом случае используется термин сервер «1С:Предприятие» 8.1.

Рис. 8. Структура кластера серверов на базе «1С:Предприятие» 8.1. Обозначения: ragent — агент сервера «1С:Предприятие»; rmngr — менеджер кластера серверов «1С:Предприятие»; rhost — рабочий процесс сервера «1С:Предприятие», обслуживающий клиентов.

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

Один из представленных тестов показывает преимущества работы 8.1 по сравнению с 8.0 даже в случае использования одного компьютера-сервера (рис. 9). Поясним, что во всех нагрузочных тестах «1С» используется программная имитация работы пользователя, при этом темп работы «тестового пользователя» существенно выше, чем у реального среднестатистического (в данном случае соответственно 965 и 300 строк документа в час). Из рис. 9 видно, что у «1С:Предприятие» 8.0 при числе тестовых пользователей более 100 начинается заметная деградация общей пропускной способности системы, а при нагрузке более 150 пользователей этот показатель просто перестает расти. В то же время для «1С:Предприятие» 8.1 продолжается практически линейный рост производительности.

Рис. 9. Сравнение общей пропускной способности платформ «1С:Предприятие» 8.0 и 8.1 для односерверной конфигурации (источник: «1С», март 2007 г.).

В плане демонстрации масштабирования «1С:Предприятие» 8.1 за счет применения кластера представляют интерес тестовые испытания при пиковых нагрузках (здесь нагрузочные условия были несколько иные, чем в предыдущем случае). Его результаты показывают (рис. 10), что при использовании одного компьютера-сервера пропускная способность 8.1 возрастает в 2,28 раза, а в случае двух компьютеров — в 3,83.

Рис. 10. Сравнение общей пропускной способности платформ 8.0 и 8.1 для односерверной и кластерной конфигурации (источник: «1С», март 2007 г.).

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

Из других представленных на том же партнерском семинаре докладов по проблеме ПиМ отметим отчет об исследовании «1С:Предприятие» 8.1 для платформы Intel, которое было выполнено российским отделением корпорации. В нем показаны возможности масштабирования прикладных решений на платформе 8.1 за счет использования многоядерных процессоров, а также более современных микроархитектур ядра (рис. 11).

Рис. 11. Возможность масштабирования сервера «1С:Предприятие» 8.1 за счет использования многоядерных микропроцессоров Intel (источник: Intel, март 2007 г.)

По данным фирмы «1С» по состоянию на начало мая, анализ проектов, уже реализованных на платформе 8.1, подтверждает возможность увеличения числа АРП в реальных условиях в среднем до 200—300 даже для одиночного сервера. Что касается кластерных конфигураций, то компания, возможно, опубликует данные об их применении в «боевых условиях» в недалеком будущем.

Тут нужно подчеркнуть, что само появление версии 8.1 представляет собой пример масштабирования решений на базе «1С:Предприятие» 8.0 за счет смены базовой платформы: здесь полностью обеспечена совместимость приложений при переходе на новую версию. Эта возможность была проиллюстрирована на мартовском семинаре, где один из крупных клиентов рассказывал об опыте замены 8.0 на 8.1: физически для этого потребовалось остановить систему всего на два часа, после чего она смогла обслуживать более 200 пользователей вместо 100.

Следующий шаг: «управляемое приложение», версия 8.2?

Еще представляя в феврале 2006 г. перспективы развития «1С:Предприятие» 8, разработчики «1С» заявили, что у них есть ближние и дальние планы. Ближние планы были реализованы с выпуском 8.1, а на мартовском семинаре уже был представлен следующий шаг в виде проекта «Управляемое приложение». Какой номер получит новая версия платформы, пока неизвестно, но по предварительному графику ее бета-версия может появиться уже нынешним летом, а окончательная — к концу текущего года.

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

Рис. 12. Возможности перераспределения вычислительной нагрузки в версии 8.next.

Масштабированием нужно уметь пользоваться

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

Отметим также, что по мере роста сложности реализуемых проектов повышается актуальность проведения исследований для оптимизации создаваемых у заказчиков систем. До использования в таких работах инструментов типа HP Mercury, кажется, еще не дошло, но сама «1С» уже предлагает партнерам и клиентам собственные средства нагрузочного и функционального тестирования.

И наконец, нужно сказать, что проблемы роста системы «1С:Предприятие», конечно, не ограничиваются вопросами повышения производительности и масштабируемости. Это лишь необходимое, но не достаточное условие для успеха на корпоративном рынке.

Другие статьи из раздела

Другие статьи по схожей теме

• Новые инструменты в облачных ERP-системах Oracle
• Интеграционная платформа ДКИС ALP Group для ERP-систем
• Платформа ALP Group для сложных расчетов в системах управления холдингами
• Система управления внедрением ERP от ALP Group
• Платформа «1С:Предприятие», версия 8.3.15

Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.

NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …

компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …

МФУ Panasonic DP-MB545RU с возможностью печати в формате А3
Хотите повысить эффективность работы в офисе? Вам поможет новое МФУ #Panasonic DP-MB545RU. Устройство осуществляет

Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

Производительность и возможности масштабирования SQL Server и Windows Server для критически важных приложений

Дата публикации: июнь 2013 г.

Область применения: Microsoft SQL Server 2014 и SQL Server 2012

Резюме: Объем и сложность данных непрерывно возрастают, и организациям необходимы новые возможности для решения критически важных задач. В этом техническом описании рассматриваются новые реализованные в Microsoft SQL Server возможности, включая отвечающие требованиям крупных предприятий функции безопасности, доступности и производительности и поддержку полного набора сложных типов данных. Эти возможности определяют «критически важные улучшения», востребованные организациями при работе в условиях динамично развивающегося рынка. Кроме того, мы сравниваем отдачу от решений, которые обеспечивают изначально реализованную внутри ядра базы данных функциональность, и выгоду от решений с дополнительными платными компонентами

Содержание

• Критически важные улучшения.
• Запросы компаний..
• SQL Server
• Доступность данных.
• Высокая доступность важнейших систем: SQL Server AlwaysOn. 7
• Оперативные процедуры базы данных. 9
• Предсказуемая, эффективная и гибкая архивация данных.
• Преимущества запуска на Windows Server
• Производительность и масштабирование.
• Оперативная обработка транзакций в памяти: проект Hekaton.
• Хранение данных в памяти: индекс ColumnStore.
• Расширение буферного пула.
• Улучшения в обработке запросов.
• Частное «облако».
• Секционирование уровня 1: масштабирование до 15-КБ секций.
• Тестирование масштабирования реальных приложений: распределенное воспроизведение.
• Уменьшение размера и повышение производительности баз данных: сжатие данных и резервных копий
• Упреждающие диагностика и устранение неполадок: Performance Data Collector и Management Studio
• Преимущества запуска на Windows Serve
• Безопасность и соответствие нормам.
• Безопасность по умолчанию: снижение уязвимости.
• Встроенные средства обеспечения соответствия нормам: улучшения в аудите SQL Server
• Ограниченный доступ к данным на уровне строк: Label security.
• Управляемый доступ при пересылке данных: расширенная защита.
• Управляемый доступ к данным администраторов: определяемые пользователем серверные роли
• Управляемый доступ к данным средств бизнес-аналитики: Microsoft SharePoint и Microsoft Active Directory
• Встроенные возможности работы с любыми данными.
• Охват неструктурированных данных благодаря поддержке сложных типов данных.
• Высокая доступность неструктурированных данных.
• Незаметное подключение и анализ больших данных через коннекторы Hadoop.
• Незаметное подключение к разным платформам благодаря большей интероперабельности.
• Сравнение затрат на критически важные функции.
• Требования к базовым возможностям.
• Основные сведения о доступных вариантах.
• Заключение.

Увеличение объемов данных мы наблюдаем повсюду. Это влияет на все устройства, приложения и процессы, которые только можно себе представить, и мир полнится множеством цифровых и виртуальных взаимодействий и событий. Осталось в прошлом время, когда организации привычно обслуживали клиентов в свои рабочие часы в одном часовом поясе или географическом регионе. Сегодня услуги постоянно доступны клиентам за счет различных средств: от Интернета до сложных глобальных систем отслеживания операций, обеспечивающих высочайший уровень эффективности и удобства для потребителя. Больше нет перерыва на техническое обслуживание для профилактики и обновления ИТ-систем, и теперь выполнять необходимые работы стало проблематично. Потребители, находясь и дома, и на работе, ожидают непрерывного обслуживания и доступа к информации всеми удобными для них способами. Высокая скорость работы больше не является привилегией немногих, кто в состоянии приобрести и содержать системы Tier-1.

Лавинообразный рост данных вышел за пределы традиционных типов данных. Согласно исследованиям Gartner, общий объем данных в мире увеличивается на 59% в год. Кроме того, по оценкам Gartner, 70-85% данных не являются структурированными.[1] Стремительный переход от структурированных данных к неструктурированным вынуждает организации разрабатывать собственные решения, поддерживающие сложные типы и нетрадиционные источники данных (такие как Big Data), с тем же набором критически важных функций.

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

В наш цифровой век требования к наличию критически важных функций актуальны не только для обладателей дорогостоящих систем Tier-1. Организации требуют критически важных функций в следующих областях:

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

SQL Server — новый стандарт платформы для решения критически важных задач. Необходимые организациям показатели времени работоспособности и производительности достигаются при низкой совокупной стоимости владения. Безопасность уровня предприятия сочетается с поддержкой практически любых типов данных.

Доступность данных

Высокая доступность важнейших систем: SQL Server AlwaysOn

SQL Server 2014 обеспечивает обещанный уровень управляемости благодаря чрезвычайно высоким пользовательским качествам AlwaysOn , усовершенствованного решения высокой доступности. Это интегрированное решение обеспечивает избыточность внутри центра обработки данных и между центрами обработки данных, что позволяет быстро переключаться при отказе приложений в случае плановых остановок и незапланированных простоев. AlwaysOn предоставляет набор новых возможностей, объединенных в одном решении.

Рис. 1: Единое решение высокой доступности

Группы доступности SQL Server AlwaysOn — решение высокой доступности и восстановления после аварии корпоративного уровня, альтернативное зеркалированию баз данных. Группы доступности представляют собой интегрированный набор возможностей, в частности для автоматического или ручного перехода на другой ресурс в группе баз данных, поддержки до четырех вторичных реплик, быстрого переключения для приложений и автоматического восстановления страниц. Каждая группа доступности представляет собой контейнер для дискретного набора пользовательских баз данных, известных как базы данных доступности, которые перемещаются вместе. У группы доступности может быть много копий для переключения (также именуемых вторичными репликами). Более того, не составляет труда настроить вторичные реплики для доступа только на чтение к вторичным базам данных и для резервного копирования вторичных баз данных. Введение групп доступности устраняет необходимость в общем дисковом хранилище, например сети хранения данных (SAN) или хранилище, подключаемом к сети (NAS), для развертывания экземпляра отказоустойчивого кластера.

Экземпляры отказоустойчивого кластера SQL Server AlwaysOn расширяют возможности отказоустойчивого кластера SQL Server и поддерживают многосайтовые кластеры, охватывающие несколько подсетей, что помогает обеспечить переключение экземпляров SQL Server между центрами обработки данных. Более быстрое и предсказуемое переключение экземпляров — еще одно ключевое преимущество, обеспечивающее ускоренное восстановление приложений. Поддержка общих томов кластера Windows Server 2012 Cluster Shared Volumes позволяет дополнительно усовершенствовать процесс использования хранилищ SAN и управления ими, за счет незаметного переключения хранилища данных и устранения ограничений, связанных с необходимостью задавать буквенные обозначения дисков SAN.

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

Прослушиватель групп доступности SQL Server AlwaysOn обеспечивает быстрый перевод на другой ресурс клиентских соединений при наличии нескольких подсетей. Клиентские приложения быстрее переключаются между несколькими подсетями (до 64), а скорость при этом почти такая же, как при переходе на другой ресурс в одной подсети. В то же время доступ с правами «только чтение» позволяет организациям управлять типами приложений, которые выполняются на серверах высокой доступности.

SQL Server AlwaysOnдля Windows Azure Virtual Machine позволяет организациям добавлять вторичные реплики в виртуальную машину Windows Azure через мастер репликации Add Azure Replica Wizard. Затем они могут использовать реплики для восстановления после сбоя, подготовки отчетов и резервного копирования. При этом снижаются капитальные затраты, поскольку есть возможность отказаться от покупки дополнительного оборудования для вторичных экземпляров AlwaysOn.

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

Recovery Advisor позволяет оптимизировать взаимодействие с пользователем, предоставляя администраторам баз данных возможность восстановить базы данных в среде SQL Server Management Studio. SQL Server обеспечивает разнообразные типы резервного копирования, поэтому бывает сложно подготовить верную последовательность операций восстановления. Чтобы оптимизировать этот процесс, SQL Server Recovery Advisor помогает администраторам баз данных создавать наиболее эффективную последовательность восстановления.

Среди предлагаемых возможностей — шкала времени, на которой показана история операций архивации базы данных и доступные временные точки, для которых пользователь может восстановить состояние базы данных; алгоритмы, позволяющие оптимизировать процесс идентификации наборов архивных носителей, необходимых для возвращения состояния базы данных в конкретный момент, и диалоговое окно восстановления страницы в среде SQL Server Management Studio, позволяющее выполнить восстановление базы данных на уровне страниц.

Резервное копирование в Azure

SQL Server обеспечивает резервное копирование и восстановление непосредственно в службу BLOB-объектов Windows Azure. Эту функцию можно использовать для резервного копирования баз данных SQL Server в локально расположенный экземпляр или экземпляр SQL Server, размещенной в среде провайдера, такой как Windows Azure Virtual Machine. Преимущества резервного копирования в «облако»: доступность, удаленное реплицируемое хранение данных без ограничений и простота передачи и получения данных из «облака». Гибкость, надежность и неограниченный размер удаленного хранилища сочетаются с превосходным механизмом архивации резервных копий и практически полным отсутствием затрат на управление оборудованием.

Smart Backup

Построенный на механизме резервирования в Windows Azure, процесс Storage SQL Server Smart Backup реализует политику автоматического резервного копирования в Windows Azure Storage. Он учитывает текущую рабочую нагрузку и возможности ускорения, использует минимум настроек (для таких параметров, как период хранения) и обеспечивает возможности управления резервными копиями для всего экземпляра базы данных или для отдельных баз данных.

Развертывание базы данных на виртуальной машине Windows Azure

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

Интеграция хранилищ данных SQL Server и Windows Azure

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

Преимущества запуска на Windows Server

Поддержка Windows Server Core

SQL Server можно запускать на платформе Windows Server Core — самом компактном варианте развертывания Windows Server. Обслуживать Windows Server Core проще, а применяемых исправлений в данном случае меньше, поэтому число плановых простоев значительно уменьшается. В некоторых случаях процентное сокращение числа исправлений и перезагрузок операционной системы может достигать 50-60%, в зависимости от активных ролей сервера и типа применяемых исправлений.[2]

Поддержка Windows Server ReFS

SQL Server поддерживает использование файловой системы Windows Server ReFS (Resilient File System) для увеличения доступности, масштабируемости и целостности. ReFS обеспечивает экономически эффективную платформу, которая позволяет увеличить доступность данных, эффективно масштабируется для очень больших наборов данных при разнообразных рабочих нагрузках и гарантирует целостность данных благодаря устойчивости к сбоям (вне зависимости от того, что отказало — программное или аппаратное обеспечение).

Ускоренная динамическая миграция

Windows Server позволяет одновременно переносить сколько угодно виртуальных машин SQL Server. Это поможет организациям повысить доступность SQL Server, одновременно снижая плановые простои. Ускоренная динамическая миграция также способствует сокращению плановых простоев за счет миграции многих виртуальных машин SQL Server (с указанием приоритетов) в кластерной среде и использования каналов передачи данных с пропускной способностью до 10 Гбит.

Динамическая миграция для виртуальных машин без кластеров

Windows Server обеспечивает динамическую миграцию виртуальных машин SQL Server и без создания кластерных сред, как при наличии общего центрального хранилища виртуальных машин, так и без него. Это способствует снижению стоимости и сложности развертывания SQL Server в виртуальных средах с обеспечением доступности во время планового простоя.

Обновление с учетом наличия кластера

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

Динамический кворум

Динамический кворум отказоустойчивого кластера Windows Server Failover Clustering Dynamic Quorum дает возможность кластеру SQL Server AlwaysOn динамически настраивать число голосов кворума, необходимых для работы системы. Это позволяет упростить настройку на 80%. Кроме того, увеличивается доступность кластера SQL Server в сценариях высокой доступности как в виртуальной, так и в невиртуальной среде, за счет возможности пересчитать при необходимости кворум и сохранить работающий кластер.

Проект Hekaton (реализованная в SQL Server технология обработки транзакций в памяти) резко повышает производительность и снижает задержки в оперативной обработке транзакций (OLTP) в SQL Server. Проект Hekaton выполнялся для обеспечения функционирования самых требовательных приложений обработки транзакций. Корпорация Microsoft тесно сотрудничала с рядом компаний для проверки его характеристик. Проект Hekaton разработан в соответствии с перечисленными ниже архитектурными принципами.

• Оптимизация доступа к данным в основной памяти. Оптимизированные для хранения данных механизмы (такие как механизм OLTP в SQL Server) сохраняют рабочие данные в буферном пуле основной памяти в зависимости от частоты доступа. Однако доступ к данным и возможность внесения изменений основаны на том, что данные в любой момент можно выгружать или получать с диска. При использовании технологии Hekaton таблицы, применяемые на самых ответственных этапах обработки транзакций, размещаются в оптимизированных структурах основной памяти. Остальные таблицы приложения, такие как ссылочные данные или данные журнала, остаются в традиционных структурах, оптимизированных для хранения. Такой подход позволяет определить наиболее эффективные пути использования памяти без необходимости управлять несколькими механизмами. Структуры основной памяти проекта Hekaton удаляют избыточные и несоответствующие данные в оптимизированном для хранения представлении, одновременно обеспечивая их полную неразрывность, целостность, изолированность и устойчивость.
• Ускоренная обработка бизнес-логики. В рамках проекта Hekaton запросы и логика процедур, сохраненных в T‑SQL, компилируются непосредственно в машинный код за счет глубокой оптимизации на этапе компиляции. Следовательно, хранимые процедуры могут исполняться со скоростью базового программного кода.
• Гладкое масштабирование. В проекте Hekaton реализован высокомасштабируемый механизм управления параллелизмом. Для устранения традиционных блокировок используется ряд структур данных без блокировок. При этом гарантируется корректная семантика транзакций и обеспечивается целостность данных.
• Изначально в составе SQL Server. Самое впечатляющее достоинство проекта Hekaton заключается в том, что огромные возможности по обработке транзакций реализованы не в виде отдельного продукта для управления данными или новой модели программирования. Это по-прежнему SQL Server!

Индекс ColumnStore дополняет ядро базы данных технологией хранения столбцов в памяти. В результате SQL Server стал первым среди ведущих систем управления базами данных универсального назначения продуктом с отдельным хранилищем столбцов. В индексе ColumnStore сочетаются технология VertiPaq, разработанная в службах Analysis Services (и представляющая собой основание для PowerPivot), и новая парадигма исполнения запросов, именуемая пакетной обработкой ( batch processing ). С ее помощью достигается существенное увеличение скорости при обработке типовых запросов к хранилищам данных. В тестовых сценариях объединения типа «звезда» и похожих запросах достигается 100-кратное повышение быстродействия по сравнению с предшествующими версиями SQL Server.

Рис. 2: Индекс ColumnStore для хранилищ столбцов в памяти

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

Администраторы баз данных также могут обновить кластеризованный индекс ColumnStore с учетом запросов к хранилищу данных в реальном времени без необходимости удалять и восстанавливать индекс. Чтобы сэкономить место на диске, можно применить новый параметр, именуемый COLUMNSTORE_ARCHIVE. Благодаря ему повышается уровень сжатия, а экономия пространства для хранения данных увеличивается до 90%. Улучшения в глобальном пакетном агрегировании также приводят к повышению производительности и более эффективной обработке пакетных запросов при использовании пакетного режима вместо . Улучшения в глобальном пакетном агрегировании также приводят к повышению производительности и более эффективной обработке пакетных запросов при использовании пакетного режима вместо построчного (который потребляет меньше памяти).

SQL Server обеспечивает повышение производительности запросов, позволяя задействовать энергонезависимые устройства, такие как твердотельные накопители (SSD), чтобы сократить требования к памяти без риска потери данных. Настройка проста и может заметно увеличить производительность выполнения запросов.

Оценщик количества элементов

Оценщик количества элементов оптимизирует процесс обработки запросов и обеспечивает следующие преимущества.

• Согласованный, предсказуемый уровень производительности запросов: различные деревья операторов, которые представляют одно отношение, имеют одинаковые оценки количества элементов.
• Новая модель для лучшей производительности: важные изменения в модели обеспечивают более точную оценку количества элементов и выбор наилучшего плана.
• Упрощенная поддержка: процесс обработки запросов разделен на два этапа, принятия решений и исполнения . Благодаря трассировке облегчается поиск неисправностей.

Поэтапная статистика

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

Параллельная операция SELECT INTO

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

Изменения регулятора ресурсов

Регулятор ресурсов Resource Governor позволяет обеспечить стабильную производительность при параллельных и смешанных рабочих нагрузках в различных приложениях SQL Server и в частном «облаке». Администраторы баз данных могут задать проценты ресурсов процессора, памяти и ввода-вывода, потребляемых определенными рабочими нагрузками. Регулятор ресурсов в SQL Server дает возможность выполнять масштабирование с максимальным числом пулов ресурсов, равным 64; задавать параметры для указания минимальной и максимальной загрузки процессора, объема занимаемой памяти и числа операций ввода-вывода в секунду; создавать привязку пулов ресурсов к планировщикам процессоров и узлам доступа к неоднородной памяти Non-Uniform Memory Access (NUMA). Управление ресурсами ввода-вывода позволяет администраторам управлять числом физических операций ввода-вывода на пользователя путем добавления параметра максимального и минимального значения IOPS для тома в пулах ресурсов Resource Governor.

Sysprep для SQL Server

SQL Server поддерживает подготовку шаблонов виртуальных машин с помощью SQL Server Sysprep. Администраторы могут подготовить образы с нужными характеристиками, а затем разместить их в частном или общедоступном «облаке». SQL Server Sysprep поддерживает SQL Server Database Engine, SQL Server Reporting Services, SQL Server Analysis Services, SQL Server Integration Services и общие компоненты. При добавлении поддержки кластеров SQL Server Sysprep можно использовать в еще более разнообразных сценариях подготовки образов.

SQL Server поддерживает секционирование таблиц размером до 15 КБ. Это позволяет использовать большое скользящее окно просмотра ( sliding window ), и такие приложения, как SAP, которые делают десятки тысяч моментальных снимков данных в дневных или часовых секциях, могут существенно увеличить длительность хранения данных, прежде чем их приходится «выталкивать», освобождая место для новых данных. Таким образом проще управлять большими объемами данных. Администраторам также проще оптимизировать обслуживание больших наборов данных в файловых группах, когда необходимо включать и исключать данные в соответствии с потребностями хранилища данных.

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

Распределенное воспроизведение поможет упростить тестирование приложений и сократить количество ошибок из-за изменения приложений, настроек и обновлений. Многопотоковая утилита воспроизведения позволяет моделировать производственные нагрузки после обновлений и изменений настроек. В результате она поможет сохранить уровень производительности при внесении изменений. Кроме того, интеграция с SQL Server Upgrade Assistant позволит оценить последствия будущих обновлений SQL Server.

Многие организации стремятся повысить быстродействие и надежность, размещая больше данных на специализированных дисковых массивах или SAN, но им мешает высокая стоимость этих высокопроизводительных дисковых ресурсов. Сжатие данных и резервных копий в SQL Server позволяет освободить место, значительно сократив размер баз данных. Уменьшая размер данных, можно увеличить производительность. Благодаря дополнительному пространству удается сохранить больше данных в SAN. А поскольку хранилища на основе SAN надежнее, то повышается и доступность.

На практике вполне реально получить уровень сжатия от 20 до 60%. Кроме того, SQL Server обеспечивает сжатие данных в формате Юникод UCS-2. Таким образом, организации, хранящие данные на нескольких языках, могут также воспользоваться сжатием данных и получить соответствующие преимущества.

Упреждающие диагностика и устранение неполадок: Performance Data Collector и Management Studio

Чтобы добиться повышения производительности, организации стараются заранее принимать меры по проверке состояния своих систем и качества запросов. SQL Server располагает встроенным набором средств диагностики и настройки, предоставляемым без дополнительной платы. С помощью Performance Data Collector администраторы могут анализировать диагностические данные счетчиков производительности, динамических административных представлений, SQL Trace и других источников для сравнения базовых и исторических показателей. Во встроенных отчетах можно увидеть данные об активности сервера, использовании диска и числе запросов. Кроме того, SQL Server Profiler может собирать диагностические данные с сервера в реальном времени и сопоставлять данные трассировки со счетчиками производительности, помогая анализировать события и устранять неполадки. Динамические административные представления Dynamic Management Views и функции, передающие информацию о состоянии сервера, помогут ИТ-администраторам контролировать состояние экземпляров сервера, диагностировать причины неполадок и настраивать производительность. Мастер по настройке Database Engine Tuning Advisor позволяет администраторам выбирать и создавать оптимальный набор индексов, индексированных представлений и разделы. При этом не требуется глубоко вникать в структуру базы данных и внутренние механизмы SQL Server. Просто выберите базы данных, которые нужно поднастроить, и Database Engine Tuning Advisor выдаст рекомендации по индексации и секционированию.

Преимущества запуска на Windows Server

Мощные виртуальные машины

Мощные виртуальные процессоры и память большого объема в Windows Server позволяют развертывать критически важные приложения, использующие SQL Server, в виртуальной среде. Виртуальная машина SQL Server может задействовать до 64 виртуальных процессоров и 1 Тбайт памяти. Кроме того, поддержка 640 виртуальных процессоров и 4 Тбайт памяти обеспечивает развертывание критически важных приложений SQL Server в невиртуальной среде.

Кластер виртуальных машин высокой плотности

При запуске на Windows Server SQL Server может обеспечить более высокую плотность кластера для развертывания в виртуальной среде. Максимальное число виртуальных машин SQL Server в кластере — 8000.

Высокомасштабируемый кластер

Windows Server 2012 обеспечивает масштабируемость кластеров SQL Server вплоть до 64 узлов. Это в четыре раза больше, чем в предшествующих версиях Windows Server. Расширенные возможности дают ряд преимуществ, в том числе большую масштабируемость, усовершенствованные функции настройки и управления, и обеспечивают простоту обслуживания больших кластеров SQL Server в виртуальной и невиртуальной среде.

Качество обслуживания

Функции обеспечения качества обслуживания в Windows Server позволяют администраторам резервировать пропускную способность сетевого адаптера для нужных SQL Server компонентов, таких как виртуальные машины, хранилища, динамическая миграция и общие тома кластера Cluster Shared Volume. Это помогает снизить капитальные и эксплуатационные затраты благодаря пропуску сетевого трафика этих служб по одному сетевому адаптеру.

Объединение сетевых карт

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

Поддержка протокола Server Message Block

Запуск SQL Server на Windows Server позволяет задействовать протокол Server Message Block файлового сервера. SQL Server может хранить файлы данных в удаленных общих папках, использующих функции SMB Direct и SMB Multichannel и стандартные сетевые адаптеры. Эта возможность дает преимущества в хранении данных, в том числе снижение затрат, повышение доступности и высокую производительность при развертывании SQL Server в виртуальной и невиртуальной среде.

Поддержка Fibre Channel в виртуальных машинах

Виртуальные машины SQL Server могут подключаться непосредственно к каналам Fibre Channel с поддержкой функций N_Port ID Virtualization (NPIV), виртуальной SAN и многоадресного ввода-вывода (MPIO) для обеспечения непрерывности соединений. Эти изменения помогут повысить эффективность хранилища, его совместимость и общую производительность при развертывании SQL Server в виртуальной среде.

Пулы носителей

Организации получают возможность снизить затраты, используя стандартные хранилища при развертывании SQL Server в невиртуальной среде, а в некоторых случаях даже заменяя дорогостоящие решения SAN. Пулы носителей Storage Pools помогут повысить гибкость хранения данных SQL Server, добавляя функции зеркалирования, контроля четности и изоляции при обслуживании одним экземпляром приложения нескольких абонентов (ACL).

Корпорация Microsoft и команда разработчиков SQL Server относятся к безопасности очень серьезно. Более 10 лет назад корпорация приступила к реализации инициативы Trustworthy Computing. В рамках этой инициативы инженеры SQL Server должны регулярно проходить учебные курсы по информационной безопасности и внедрять меры безопасности на своем рабочем месте, независимо от группы, в которой они работают в данный момент. Цель поддержания строгой дисциплины в деле обеспечения безопасности и конфиденциальности в масштабе организации — создание программных продуктов, в которых изначально заложены меры защиты. Это позволит снизить общий уровень риска компрометации данных. По данным института National Institute of Standards and Technology (NIST), общественной организации, занимающейся проблемами безопасности, число уязвимых мест в SQL Server меньше, чем в продуктах любого крупного поставщика баз данных. Кроме того, продукт SQL Server признан «самой безопасной базой данных» советом Information Technology Industry Council (ITIC).[3

Встроенные средства обеспечения соответствия нормам: улучшения в аудите SQL Server

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

• SQL Audit(все редакции). Позволяет распространить преимущества SQL Server Audit из редакции Enterprise на все редакции SQL Server. Благодаря этому можно проводить более тщательный аудит в базах данных SQL Server, а также повысить уровень стандартизации, производительность и расширить функциональные возможности.
• Определяемый пользователем аудит. Позволяет любым приложениям записывать определенные администратором события в журнал аудита, что повышает гибкость хранения информации аудита.
• Фильтрация аудита. Обеспечивает высокую гибкость при отсеве ненужных событий из журнала аудита.
• Устойчивость аудита. Дает возможность восстанавливать данные аудита при сбоях временных файлов и сетевых проблемах, не позволяя потерять журналы аудита во время переключения ресурсов.

Ограниченный доступ к данным на уровне строк: Label security

Многим промышленным предприятиям и государственным учреждениям необходимо ограничить доступ к данным на уровне строк и ячеек, чтобы только доверенные лица могли обращаться к хранящимся там данным. С помощью SQL Server можно реализовать детализированный подход к защите с использованием набора средств SQL Server Label Security, предоставляемого без дополнительной платы. Набор средств будет полезен для создания ответственных приложений и защиты особых областей базы данных. При этом дополнительные компоненты приобретать не нужно. Набор, спроектированный и обслуживаемый инженерами Microsoft, доступен по ссылке http:///sqlserverlst.codeplex.com.

SQL Server обеспечивает шифрование данных при сохранении их на диск и расшифровку при считывании в память. Таким образом, организациям не требуется вносить изменения в приложения, чтобы защитить данные. Функции шифрования встроены в ядро базы данных, поэтому процесс незаметен для пользователей и приложений. Этот механизм реализован в редакции SQL Server Enterprise. Шифрование также работает при создании резервных копий базы данных, они шифруются автоматически.

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

Определяемые пользователем серверные роли User-Defined Server Roles повышают гибкость и управляемость, а также позволяют добиться соответствия нормам благодаря четкому разделению обязанностей. Серверные роли могут быть сформированы в соответствии с задачами различных компаний, которые делят административные обязанности между ролями. Роли могут быть вложенными, что позволяет гибко соответствовать иерархической структуре подразделений организации. Определяемые пользователем серверные роли также помогают избавиться от использования роли sysadmin для администрирования базы данных. Например, можно создать особую роль администратора базы данных для повседневного применения без доступа к данным пользователей.

Управляемый доступ к данным средств бизнес-аналитики: Microsoft SharePoint и Microsoft Active Directory

Корпорация Microsoft поставляет средства бизнес-аналитики для постоянно расширяющегося круга пользователей. Одновременно растут требования к безопасности из-за далеко идущих последствий при нарушении правил доступа. SQL Server помогает защитить аналитические данные конечных пользователей с применением встроенных элементов управления, в том числе новых моделей безопасности SharePoint и Active Directory для формирования отчетов пользователей, публикуемых и совместно используемых в SharePoint. Расширенные модели безопасности обеспечивают управление на уровне строк и столбцов.

В результате быстрого перехода от структурированных типов данных к сложным, новые критически важные приложения требуют, чтобы поддержка сложных типов данных была встроенной, а не добавлялась за отдельную плату. SQL Server поддерживает рост числа типов и объема сложных данных благодаря функциям FILESTREAM, удаленному хранилищу больших двоичных объектов Remote Blob Storage и поддержке пространственных данных. Усовершенствования дополняют мощные встроенные базовые функции и расширяют реляционные. В результате организации могут строить эффективные приложения для новых случаев применения без дополнительных расходов.

Таблица FileTable сервера SQL Server построена на основе FILESTREAM; она обеспечивает поддержку пространства имен Win32 и совместимость приложений с данными файлов, сохраненных в SQL Server. Огромное число приложений хранят данные в двух «мирах»: неструктурированном (документы, мультимедиа-файлы и другие неструктурированные данные на файловых серверах) и структурированном (реляционные, структурированные метаданные в реляционных системах). Благодаря FileTable снижается входной порог для компаний, которые в настоящее время используют файлы на серверах для запуска приложений Win32. Это позволяет экономить ресурсы, необходимые для обслуживания двух отдельных систем и их синхронизации.

В SQL Server обработке данных сложных типов уделяется такое же внимание, как обработке данных обычных типов. Можно использовать FILESTREAM для хранения и управления сложными данными различными способами, как если бы это была часть базы данных. Кроме того, с помощью SQL Server организации могут задействовать функции высокой доступности AlwaysOn для работы со сложными данными, управляемыми через FILESTREAM, даже если используются удаленное хранилище больших двоичных объектов и FileTable.

Коннекторы Hadoop для SQL Server и SQL Server Parallel Data Warehouse предназначены для компаний, имеющих лицензии SQL Server и SQL Server Parallel Data Warehouse. Эти коннекторы обеспечивают двусторонний обмен данными между SQL Server и Hadoop, поэтому пользователи могут эффективно работать как со структурированными, так и с неструктурированными данными. Кроме того, можно использовать ведущую платформу бизнес-аналитики Microsoft для анализа наборов данных Hadoop. Пользователи могут создавать гибридные веб-приложения с помощью знакомых инструментов, таких как Microsoft Excel и зарекомендовавшие себя клиентские функции бизнес-аналитики PowerPivot и Power View, чтобы выполнить всеобъемлющий и интерактивный анализ.

На практике многие организации управляют гетерогенными инфраструктурами. Чтобы получить наибольшую отдачу от вложений и успешно развиваться, им необходимы обеспечивающие взаимодействие инструменты и системы. SQL Server поможет расширить гетерогенную среду, давая возможность подключаться к приложениям SQL Server и Windows Azure SQL Database. Предоставляется поддержка для других стандартных интерфейсов API на разных платформах. Используя SQL Server, организации могут повысить отдачу от капиталовложений, одновременно переводя важнейшие унаследованные приложения на платформу данных SQL Server.

Рис. 3: Взаимодействие с использованием различных платформ и стандартов

Интероперабельность с SQL Server обеспечивают следующие компоненты.

• Драйвер Microsoft для PHPдля SQL Server: обеспечивает надежную, масштабируемую интеграцию с SQL Server для PHP-приложений, развертываемых на платформе Windows.
• Подключение для Java: обеспечивает безопасное подключение с высокой доступностью из корпоративных приложений Java к SQL Server.
• Драйвер JDBC Microsoftдля Linuxи UNIX: обеспечивает подключение к приложениям Linux и UNIX, что упрощает компаниям, работающим с приложениями на унаследованных платформах, переход на SQL Server.

Организации ожидают от поставщиков интуитивного понимания того, что означает для них термин «критически важный», а также удобных и экономически выгодных решений. Корпорация Microsoft стремится соответсвовать этим ожиданиям, предоставляя инструменты и функции, встроенные в платформу базы данных. SQL Server располагает критически важными функциями, необходимыми организациям, чтобы они могли конкурировать в динамичном цифровом мире. Все возможности, рассмотренные в этом документе, реализованы в редакции SQL Server Enterprise. Для построения на ее основе полной и современной базы данных не требуется дорогостоящих дополнительных компонентов.

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

Точно так же, как покупатели дома ожидают, что у него будут крыша, окна и двери, организации вправе ожидать от базы данных масштаба предприятия наличия встроенных функций высокой доступности, повышенной производительности и усиленной безопасности. На рис. 4 показаны различия между двумя схожими решениями для баз данных, Microsoft SQL Server и Oracle Database, и влияние на цену дополнительных компонентов, необходимых для того, чтобы достичь похожего конечного результата.

Рис. 4: Сравнение SQL Server и Oracle Database

Дополнительные компоненты

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

Таблица 1. Сравнение критически важных решений Microsoft и Oracle

Microsoft SQL Server

(показаны не все варианты)

Базовая лицензия Enterprise Edition (включает поддержку в течение 1 года)

Способы увеличения быстродействия программ

Современные ЭВМ обладают очень большой мощностью. Скорость работы процессора (ЦП) современных ЭВМ измеряется гигагерцами, объём оперативной памяти гигабайтами, а современные интерфейсы устройств обеспечивают скорость обмена данными порядка, как минимум, нескольких сотен мегабайт в секунду [1]. Производительность, которая ещё несколько лет назад казалась «сказочной» в настоящее время стала нормой жизни.

Однако параллельно росту мощности ЭВМ увеличивается и ресурсоёмкость приложений. У приложений совершенствуется функционал, интерфейс, возрастает объём обрабатываемых данных и как следствие системные требования. Поэтому вопрос об увеличении быстродействия приложений не теряет своей актуальности.

Общие вопросы быстродействия программ.

Быстродействие программ (ПО) зависит от многих факторов, но основными из них являются два:

• Соотношение между реальными системными требованиями ПО и существующей аппаратной конфигурацией ЭВМ;
• Алгоритмы работы ПО.

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

1. Увеличивается производительность hardware, а вовсе не быстродействие ПО;
2. Производительность hardware ограничена возможностями существующих в данный момент элементной базы и инженерных решений в данной области;
3. Большие финансовые затраты на модернизацию и настройку по причине высокой стоимости комплектующих ЭВМ и услуг специалистов требуемой квалификации.

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

1. Обеспечить работу нового ПО на уже существующем оборудовании;
2. Разработать масштабируемое ПО;
3. Значительно уменьшить финансовые и трудовые затраты при внедрении.

Вместе с тем и у этого пути имеется ряд недостатков:

1. Значительно усложняется процесс разработки ПО, так как более «быстрые» алгоритмы сложнее более «медленных» (на пример алгоритм бинарного поиска сложнее, чем алгоритм линейного поиска) [2];
2. Реализация более сложных алгоритмов, как правило, требует привлечения специалистов более высокой квалификации;
3. В случае работы с большими объёмами данных или выполнении задач требующих больших и сложных вычислений, ресурсоёмкость ПО всё равно остаются достаточно высокой. Несмотря, на какие либо способы увеличения быстродействия.

Таким образом, в общем случае обеспечение быстродействия ПО является комплексной задачей.

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

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

Увеличение быстродействия программ.

Как было показано в предыдущем параграфе, можно увеличить быстродействие ПО соответствующим образом реализовав его алгоритмы. Количественным показателем быстродействия алгоритма (а, следовательно, и ПО) является время его выполнения, измеренное по специальной методике, так называемого профилирования [2]. Таким образом, в общем случае выбор наиболее «быстрых» алгоритмов сводится к измерению времени их выполнения и сравнении полученных результатов между собой. Такой способ анализа быстродействия является наиболее объективным [2]. На протяжении многих лет программистами был накоплен большой опыт профилирования, который позволяет сделать определённые выводы относительно возможности оптимизации быстродействия ПО ещё на стадии написания.

Эти выводы были обобщены и представлены в виде определённых рекомендаций [2, 4]. Если программист будет следовать данным рекомендациям, то написанная программа вероятнее всего будет обладать большим быстродействием, чем в случае их игнорирования. Однако следует ещё раз подчеркнуть, что достоверные сведения о быстродействии может дать только профилирование. Это обусловлено тем, что быстродействие алгоритма определяет в первую очередь его конкретная реализация. Кроме того необходимо ещё раз отметить, что в отношении увеличения быстродействия ПО программная инженерия не всесильна (см. предыдущий параграф).

В чём же состоят выше упомянутые рекомендации? Их краткое содержание применительно к языку программирования Delphi приведено ниже.

1. При написании кода программ рекомендуется избегать процедур, состоящих из сотен строк. Практически всегда в них можно выделить блоки, которые лучше оформить в виде отдельной процедуры. Возможно, позже вы ей даже воспользуетесь где-то в другом месте. Не говоря уже о том, что это повышает понимание программы и вами, и другими программистами. К тому же так проще искать «узкие» места в программе.
2. Использование оператора case (switch) вместо многократных if… then… else (if… else). Во втором варианте компилятор будет выполнять проверку условия столько раз, сколько у вас вариантов. В первом проверка выполняется лишь однажды.
3. Некоторые действия могут быть довольно продолжительными, поэтому рекомендуется выносить за рамки цикла всё, что можно выполнить вне его, чтобы избежать большого числа повторений внутри цикла.
4. В циклах типа for нужно стараться, чтобы значение счетчика уменьшалось до нуля, а не наоборот — начиналось с нуля. Это связано с особенностями процессора. Сравнение с нулём выполняется гораздо быстрее, чем с другим числом.
5. Пользоваться типом Variant только при необходимости. Операции над этим типом сложнее, чем, например, над Integer или String.
6. Не злоупотреблять «программированием на компонентах». В частности не использовать компонент TTreeView для хранения древовидных структур данных — он работает очень медленно и предназначен только для визуального отображения. В случае работы со структурами данных лучше использовать алгоритмы, созданные самостоятельно на основе фундаментальных.
7. Сохранение и загрузка свойств компонентов с помощью методов ReadComponent и WriteComponent работает довольно медленно, поэтому по возможности рекомендуется сохранять и восстанавливать состояние программы между сеансами при помощи других способов.
8. Заменить простой в реализации алгоритм на более сложный, но с большим быстродействием. Например, если заранее известно, что в списке для поиска будет много элементов, лучше его отсортировать и применять бинарный поиск вместо линейного.
9. В критических с точки зрения быстродействия местах программы делать вставки на ассемблере. Команды ассемблера напрямую транслируются в машинный код. Таким образом, в отличие от высокоуровневых языков при компиляции отсутствует проблема синхронизации и ряд других негативных обстоятельств.

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

Особо следует отметить, что рекомендации 3 и 4 применяются не только для языков высокого уровня, но и для ассемблера. Помимо вышеуказанных для увеличения быстродействия программ написанных на ассемблере, в том числе и вставок, существуют следующие рекомендации [3]:

1. Замещение универсальных инструкций на учитывающие конкретную ситуацию, например, замена умножения на степень двойки на команды сдвига (отказ от универсальности).
2. Уменьшение количества передач управления в программе: за счет преобразования подпрограмм в макрокоманды для непосредственного включения в машинный код; за счет преобразования условных переходов так, чтобы условие перехода оказывалось истинным значительно реже, чем условие для его отсутствия; перемещение условий общего характера к началу разветвленной последовательности переходов; преобразование вызовов, сразу за которыми следует возврат в программу, в переходы («сращивание хвостов» и «устранение рекурсивных хвостов») и т.д.
3. Максимальное использование всех доступных регистров за счет хранения в них рабочих значений всякий раз, когда это возможно, чтобы минимизировать число обращений к памяти, упаковка множественных значений или флагов в регистры и устранение излишних продвижений стека (особенно на входах и выходах подпрограмм).
4. Использование специфических для данного процессора инструкций, например, инструкции засылки в стек непосредственного значения, которая имеется в процессоре 80286 и более поздних. Другие примеры – двухсловные строковые инструкции, команды перемножения 32-разрядных чисел, деление 64-разрядного на 32-разрядное число и умножение на непосредственное значение, которые реализованы в процессорах 80386 и 80486. Программа должна, разумеется, вначале определить, с каким типом процессора она работает!

Заключение.

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

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

Список литературы и источников.

1. Быстро и легко. Сборка, диагностика, оптимизация и апгрейд современного компьютера/ под ред. Печникова В.Н. Учебное пособие – М.: Лучшие книги, 2005;
2. Бакнелл Д. Фундаментальные алгоритмы и структуры данных в Delphi. М.: ООО «ДиаСофтЮП»; СПб.: Питер, 2006;
3. Дункан Р. Оптимизация программ на ассемблере./ Дункан Р.//PC Magazine/Russian Edition №1/1992;
4. Список пропускных способностей интерфейсов передачи данных;
5. Гапанович А. Как сделать свою программу быстрой./Компьютерра Online.

Проверка производительности сайта на соответствие заданному бюджету с Lighthouse

Дата публикации: 2020-06-21

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

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

Причиной этого было незнания того, какие именно цифры мне следует использовать для бюджетов, в сочетании с отсутствием различий между установкой бюджета и его проверкой / исполнением. Вот почему я была очень взволнована, когда в этом году на Google I/O команда Lighthouse объявила о поддержке бюджетов производительности, которые можно интегрировать с Lighthouse. Теперь мы можем определить простой бюджет производительности в файле JSON, который будет протестирован в рамках аудита Lighthouse!

Бюджет Lighthouse

Как мы знаем, существует бесчисленное множество показателей производительности. От ориентированных на пользователя, таких как Время до первого взаимодействия, до ориентированных на ресурсы метрик, таких как размер файлов JavaScript.
Бюджет производительности, который мы можем установить для Lighthouse, ориентирован на последнее и основан исключительно на исходных значениях активов и ресурсов вашего сайта. Мы можем создать два типа бюджетов:

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Размер данного ресурса — например, бюджет, который задает, что данная страница загружает только 500 КБ JavaScript

Asp проверка быстродействия и масштабируемости

Применимо к: SharePoint Server 2010

Последнее изменение раздела: 2020-11-30

Обзор. В этой статье приводятся рекомендации по планированию загрузки для разных развертываний систем поиска Microsoft SharePoint Server 2010, включая малые, средние и крупные фермы SharePoint Server 2010.

В этой статье приводятся рекомендации по планированию загрузки для сред совместной работы в развертываниях систем поиска SharePoint Server 2010. В ней представлены следующие сведения для трех примеров конфигурации ферм поиска:

Спецификации тестовой среды, например, оборудование, топология фермы и конфигурация

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

Набор данных тестовой фермы, включая контент и размер баз данных

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

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

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

После изучения этого документа вы узнаете, как выполнять следующие процедуры:

Определение целевых показателей производительности и загрузки для среды.

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

Разработка физической и логической топологии для обеспечения максимальной степени надежности и эффективности.

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

Мониторинг ключевых индикаторов производительности среды.

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

Характерный для баз данных контент

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

Репозитории для обхода содержат преимущественно контент SharePoint Server.

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

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

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

Точность измерений в фермах зависит от состояния сети и среды; допускается погрешность до 10%.

При выборе подходящего сценария рекомендуется руководствоваться следующими вопросами:

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

Доступность Каковы требования к доступности? Требуется ли решение, способное сохранить работоспособность в случае отказа отдельного сервера?

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

Пропускная способность Как много пользователей будут одновременно выполнять поиск контента? В их число входят пользователи, вводящие запросы в поле поиска, скрытые запросы веб-частей на автоматический поиск данных, а также компоненты Microsoft Outlook 2010 Social Connector, запрашивающие в системе поиска веб-каналы активности, URL-адреса которых требуют фильтрации по ролям безопасности.

Основываясь на ответах на эти вопросы, выберите один из следующих сценариев:

Малая ферма Содержит одно приложение-службу поиска, которое использует некоторые общие ресурсы в одной ферме SharePoint Server. Для малых развертываний объем контента, включаемого в индекс, обычно ограничен (менее 10 миллионов элементов). В зависимости от установленных показателей актуальности добавочный обход контента может выполняться в рабочие часы.

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

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

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

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

Полный обход контента (по-возможности выполняется параллельно).

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

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

Обслуживание индекса Основной этап жизненного цикла фермы. Характеризуется следующим образом:

Периодически выполняется добавочный обход всего контента.

При обходе контента SharePoint Server большинство изменений связаны с изменениями в системе безопасности.

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

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

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

Источник контента или начальный адрес удаляется из приложения-службы поиска.

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

Из-за небольшого размера фермы некоторые серверы выполняют одновременно несколько ролей. Рекомендуется объединять компонент запросов с интерфейсным веб-сервером. Это позволит избежать размещения на одном сервере компонентов обхода контента и запросов. В этой конфигурации используется три сервера приложений и один сервер базы данных:

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

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

В соответствии с рекомендациями, индекс, содержащий менее 10 миллионов элементов, должен иметь один раздел. На каждом сервере развернут один основной компонент запросов из раздела индекса. Такая конфигурация компонента запросов в режиме «активный/активный» позволяет обеспечить работоспособность даже в случае отказа одного из компонентов поиска, когда нагрузка по обработке запросов переносится на оставшийся компонент. При отказе одного из компонентов система поиска пересылает запросы на следующий доступный компонент запросов (используется алгоритм циклического перебора).

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

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

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

1 четырехъядерный процессор с тактовой частотой 3 ГГц

Windows Server 2008 R2 64-разрядная

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД1

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД2

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Тип службы балансировки нагрузки

Версия программного обеспечения

SharePoint Server 2010 (предварительная версия)

Службы, запущенные локально

Все службы, включая службу параметров сайтов и запросов поиска

1 четырехъядерный процессор с тактовой частотой 3 ГГц

1 четырехъядерный процессор с тактовой частотой 3 ГГц

Windows Server 2008 R2 64-разрядная

Windows Server 2008 R2 64-разрядная

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД1

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД2

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID0:БД

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Тип службы балансировки нагрузки

Версия программного обеспечения

SharePoint Server 2010 (предварительная версия)

SharePoint Server 2010 (предварительная версия)

Службы, запущенные локально

Служба поиска SharePoint Server; служба параметров сайтов и запросов поиска

Служба поиска SharePoint Server

2 четырехъядерных процессора с тактовой частотой 3 ГГц

Windows Server 2008 R2 64-разрядная

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID0:БД

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID0:ЖУРНАЛЫ

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Версия программного обеспечения

Microsoft SQL Server 2008 Enterprise

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

Высокоуровневое описание рабочей нагрузки

Среднее число запросов в минуту

Среднее число параллельных пользователей

Общее число запросов в день

В этом разделе описывается набор данных тестовой фермы, включая контент и размер баз данных, индексы поиска и внешние источники данных.

Размер индекса поиска (число элементов)

Размер базы данных обхода

Размер файла журнала базы данных обхода

Размер базы данных свойств

Размер файла журнала базы данных свойств

Размер базы данных администрирования поиска

Размер активных разделов индекса

38,4 ГБ (всего 76,8 ГБ в связи с применением зеркалирования индекса)

Общее число баз данных поиска

Другие базы данных

SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

В этом разделе описываются данные о работоспособности и производительности для тестовой среды.

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

Задержка запросов Эти измерения были выполнены в процессе тестирования на задержку запросов. Средством тестирования был отправлен набор стандартных запросов от имени одного пользователя, после чего была определена итоговая задержка. Во время тестирования обход контента не выполнялся.

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

Среднее значение использования ЦП SQL Server

Среднее значение использования ЦП интерфейсного веб-сервера

Среднее значение использования ЦП сервера запросов

Сбои интерфейсного веб-сервера

Сбои сервера приложений

Коэффициент попадания в кэш (SQL Server)

Операций блокировки SQL Server: среднее время ожидания (мс)

Операций блокировки SQL Server: время ожидания блокировки (мс)

Операций блокировки SQL Server: взаимных блокировок в секунду

Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)

Компиляций SQL Server в секунду

Статистика SQL Server: повторных компиляций SQL Server в секунду

Средняя длина дисковой очереди (SQL Server)

Длина дисковой очереди: операций записи (SQL Server)

Обращений чтения с диска в секунду (SQL Server)

Обращений записи на диск в секунду (SQL Server)

Средняя длина дисковой очереди (сервер запросов)

Длина дисковой очереди: операций записи (сервер запросов)

Обращений чтения с диска в секунду (сервер запросов)

Обращений записи на диск в секунду (сервер запросов)

Средний объем использования памяти (сервер запросов)

Максимальный объем использования памяти (сервер запросов)

Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)

Средний объем использования памяти (интерфейсный веб-сервер)

Максимальный объем использования памяти (интерфейсный веб-сервер)

Число успешных запросов

Задержка пользовательского интерфейса запросов (75 процентиль)

Задержка пользовательского интерфейса запросов (95 процентиль)

Пропускная способность запросов

3,29 запроса в секунду

22,4 запроса в секунду

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

Среднее значение использования ЦП SQL Server

Среднее значение использования ЦП индексатора

Сбои интерфейсного веб-сервера

Сбои сервера приложений

Коэффициент попадания в кэш (SQL Server)

Операций блокировки SQL Server: среднее время ожидания (мс)

Операций блокировки SQL Server: время ожидания блокировки (мс)

Операций блокировки SQL Server: взаимных блокировок в секунду

Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)

Компиляций SQL Server в секунду

Статистика SQL Server: повторных компиляций SQL Server в секунду

Средняя длина дисковой очереди (SQL Server)

Длина дисковой очереди: операций записи (SQL Server)

Средняя длина дисковой очереди (сервер обхода контента)

Длина дисковой очереди: операций записи (сервер обхода контента)

Средний объем использования памяти (сервер обхода контента)

Максимальный объем использования памяти (сервер обхода контента)

Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)

Средний объем использования памяти (интерфейсный веб-сервер)

Максимальный объем использования памяти (интерфейсный веб-сервер)

Число успешных запросов

Скорость обхода контента портала (элементов в секунду)

Скорость обхода контента привязки (элементов в секунду)

Общая скорость обхода контента (элементов в секунду)

В этом разделе описываются данные тестов, демонстрирующие производительность фермы. Рекомендации по повышению производительности фермы см. в разделе Оптимизация этой статьи.

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

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

На следующем графике показана пропускная способность запросов для этой фермы по мере увеличения нагрузки (данные получены в ходе тестирования пропускной способности запросов).

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

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

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

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

Для повышения производительности в такой ферме рекомендуется предпринять следующие шаги:

Переместите процессы интерфейсного веб-сервера на собственный сервер (добавьте дополнительный интерфейсный веб-сервер для обеспечения избыточности).

Увеличьте объем ОЗУ на обоих серверах запросов. Рекомендуемый объем ОЗУ для сервера запросов: 33 процента от величины раздела индекса активного компонента запросов плюс 3 ГБ для операционной системы и других процессов.

Добавьте массивы запоминающих устройств, что позволит разделить базы данных на сервере базы данных.

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

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

Два сервера приложений используются для обхода контента и администрирования. Это означает следующее:

На одном из серверов приложений создается центр администрирования и компонент администрирования поиска.

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

Оставшиеся четыре сервера приложений используются для обработки запросов. В стандартной конфигурации индекс размером до 40 миллионов элементов должен содержать 4 раздела. Избыточность функций обработки запросов достигается благодаря следующей архитектуре компонентов запросов: для каждого сервера развернут один активный компонент запросов из одного раздела индекса и резервный из другого раздела. Также в этом примере показаны действия, которые следует предпринять, если планируется увеличение размера индекса свыше 40 миллионов элементов. Для начала используется 8 разделов индекса (каждому соответствует один активный компонент и один резервный компонент обхода) на 4 серверах приложений, что позволяет свести к минимуму объем операций по разделению индекса. Предполагается, что каждый сервер приложений соответствует следующим требованиям, обеспечивающим размещение на нем 4 компонентов:

Достаточные объем ОЗУ и число операций ввода-вывода в секунду.

На каждом сервере используется более шести ядер ЦП для обработки:

Четыре ядра ЦП для двух активных компонентов запросов.

Два ядра ЦП для двух резервных компонентов запросов.

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

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

2 четырехъядерных процессора с тактовой частотой 2,33 ГГц

Windows Server 2008 R2 64-разрядная

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Тип службы балансировки нагрузки

Версия программного обеспечения

Microsoft SharePoint Server (предварительная версия)

Службы, запущенные локально

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

2 четырехъядерных процессора с тактовой частотой 2,33 ГГц

2 четырехъядерных процессора с тактовой частотой 2,33 ГГц

Windows Server 2008 R2 64-разрядная

Windows Server 2008 R2 64-разрядная

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

4 жестких диска по 300 ГБ SAS 15000 об/мин: RAID10:БД

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС/БД

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Тип службы балансировки нагрузки

Версия программного обеспечения

SharePoint Server 2010 (предварительная версия)

SharePoint Server 2010 (предварительная версия)

Службы, запущенные локально

Служба поиска SharePoint Server; служба параметров сайтов и запросов поиска

Служба поиска SharePoint

Развернуто два сервера баз данных. Первый сервер содержит базы данных администрирования поиска, свойств и другие базы данных SharePoint Server. На втором сервере размещены две базы данных обхода контента. Обратите внимание, что объем создаваемых хранилищ оптимизирован в соответствии с характеристиками существующего оборудования, на базе которого проводилось тестирование.

2 четырехъядерных процессора с тактовой частотой 3,2 ГГц

4 двухъядерных процессора с тактовой частотой 2,19 ГГц

Windows Server 2008 R2 64-разрядная

Windows Server 2008 R2 64-разрядная

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД

6 жестких дисков по 450 ГБ SAS 15000 об/мин: RAID10: БД СВОЙСТВ

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1: БД АДМИНИСТРИРОВАНИЯ ПОИСКА, БД SharePoint

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛЫ

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД

2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД

6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД1 ОБХОДА КОНТЕНТА

6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД2 ОБХОДА КОНТЕНТА

2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ1 БД ОБХОДА КОНТЕНТА

2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ2 БД ОБХОДА КОНТЕНТА

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Версия программного обеспечения

SQL Server 2008 Enterprise

SQL Server 2008 Enterprise

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

Высокоуровневое описание рабочей нагрузки

Среднее число запросов в минуту

Среднее число параллельных пользователей

Общее число запросов в день

Мониторинг работоспособности поиска — трассировка событий; отчет по журналу обхода контента; задание анализа работоспособности; поиск и обработка

В этом разделе описывается набор данных тестовой фермы, включая контент и размер баз данных, индексы поиска и внешние источники данных.

Размер индекса поиска (число элементов)

Размер базы данных обхода

Размер файла журнала базы данных обхода

Размер базы данных свойств

Размер файла журнала базы данных свойств

Размер базы данных администрирования поиска

Размер активных разделов индекса

316 ГБ (79 ГБ на каждый активный компонент).

Общее число баз данных

Другие базы данных

SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

В этом разделе описываются данные о работоспособности и производительности для тестовой среды.

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

Задержка запросов Эти измерения были выполнены в процессе тестирования на задержку запросов. Средством тестирования был отправлен набор стандартных запросов от имени одного пользователя, после чего была определена итоговая задержка. Во время тестирования обход контента не выполнялся.

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

Среднее значение использования ЦП SQL Server (сервер базы данных свойств)

Среднее значение использования ЦП интерфейсного веб-сервера

Среднее значение использования ЦП сервера запросов

Сбои интерфейсного веб-сервера

Сбои сервера приложений

(сервер базы данных свойств)

Коэффициент попадания в кэш (SQL Server)

Операций блокировки SQL Server: среднее время ожидания (мс)

Операций блокировки SQL Server: время ожидания блокировки (мс)

Операций блокировки SQL Server: взаимных блокировок в секунду

Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)

Компиляций SQL Server в секунду

Статистика SQL Server: повторных компиляций SQL Server в секунду

Соотношение чтение/запись (операций ввода/вывода для базы данных)

Средняя длина дисковой очереди (SQL Server)

Длина дисковой очереди: операций записи (SQL Server)

Обращений чтения с диска в секунду (SQL Server)

Обращений записи на диск в секунду (SQL Server)

Средняя длина дисковой очереди (сервер запросов)

Длина дисковой очереди: операций записи (сервер запросов)

Обращений чтения с диска в секунду (сервер запросов)

Обращений записи на диск в секунду (сервер запросов)

Средний объем использования памяти (сервер запросов)

Максимальный объем использования памяти (сервер запросов)

Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)

Средний объем использования памяти (интерфейсный веб-сервер)

Максимальный объем использования памяти (интерфейсный веб-сервер)

Число успешных запросов

Задержка пользовательского интерфейса запросов (75 процентиль)

Задержка пользовательского интерфейса запросов (95 процентиль)

Пропускная способность запросов

2,38 запроса в секунду

27,05 запроса в секунду

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

Среднее значение использования ЦП SQL Server (серверы баз данных обхода контента и свойств)

Максимальное значение использования ЦП SQL Server (сервер базы данных обхода контента и свойств)

Среднее значение использования ЦП индексатора

Сбои интерфейсного веб-сервера

Сбои сервера приложений

(серверы баз данных обхода контента и свойств)

Коэффициент попадания в кэш (SQL Server)

Сбор не выполнялся

Операций блокировки SQL Server: среднее время ожидания [мс]

Операций блокировки SQL Server: максимальное время ожидания [мс]

69 919,500; 1 081 703

55 412,000; 304,500

Операций блокировки SQL Server: среднее время ожидания блокировки [мс]

339,658; 10 147,012

Сбор не выполнялся

Операций блокировки SQL Server: максимальное время ожидания блокировки [мс]

598 106,544; 234 708 784

Сбор не выполнялся

52 711,592; 23,511

Операций блокировки SQL Server: взаимных блокировок в секунду

Сбор не выполнялся

Операций кратковременной блокировки SQL Server: среднее время ожидания [мс]

Операций кратковременной блокировки SQL Server: максимальное время ожидания [мс]

Компиляций SQL Server в секунду: в среднем

Сбор не выполнялся

Компиляций SQL Server в секунду: максимум

Сбор не выполнялся

Статистика SQL Server: повторных компиляций SQL Server в секунду: в среднем

Сбор не выполнялся

Статистика SQL Server: повторных компиляций SQL Server в секунду: максимум

Сбор не выполнялся

Соотношение чтение/запись (операций ввода/вывода для базы данных): максимум

Сбор не выполнялся

Средняя длина дисковой очереди (SQL Server)

Максимальная длина дисковой очереди (SQL Server)

Длина дисковой очереди: операций записи (SQL Server): в среднем

Длина дисковой очереди: операций записи (SQL Server): максимум

Обращений чтения с диска в секунду (SQL Server): в среднем

Сбор не выполнялся

Обращений чтения с диска в секунду (SQL Server): максимум

Сбор не выполнялся

Обращений записи на диск в секунду (SQL Server): в среднем

Сбор не выполнялся

Обращений записи на диск в секунду (SQL Server): максимум

Сбор не выполнялся

Средняя длина дисковой очереди (сервер обхода контента)

Длина дисковой очереди: операций записи (сервер обхода контента)

Обращений чтения с диска в секунду (сервер обхода контента)

Сбор не выполнялся

Обращений записи на диск в секунду (сервер обхода контента)

Сбор не выполнялся

Средний объем использования памяти (сервер обхода контента)

Максимальный объем использования памяти (сервер обхода контента)

Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)

Средний объем использования памяти (интерфейсный веб-сервер)

Максимальный объем использования памяти (интерфейсный веб-сервер)

Число успешных запросов

Скорость обхода контента портала (элементов в секунду)

Скорость обхода контента привязки (элементов в секунду)

Общая скорость обхода контента (элементов в секунду)

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

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

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

На следующем графике показана пропускная способность запросов для этой фермы по мере увеличения нагрузки (данные получены в ходе тестирования пропускной способности запросов).

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

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

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

Дополнительные затраты ресурсов на эффективное выполнение обхода источника контента для сайта SharePoint влекут за собой снижение общей скорости обхода контента в ферме.

В этой ферме практически максимальная загрузка ОЗУ на серверах обработки запросов.

Для повышения производительности в такой ферме рекомендуется предпринять следующие шаги:

Увеличьте объем ОЗУ на обоих серверах запросов. Рекомендуемый объем ОЗУ для сервера запросов: 33 процента от величины раздела индекса активного компонента запросов плюс 3 ГБ для операционной системы и других процессов.

Увеличьте объем ОЗУ на сервере, на котором размещается база данных свойств. В этой конфигурации размер таблицы ключей составляет около 92 ГБ (с учетом индексов), что предполагает наличие около 30 ГБ ОЗУ. Тем не менее, на сервере базы данных доступно всего 32 ГБ ОЗУ для обслуживания баз данных свойств, администрирования поиска и других баз данных SharePoint Server.

Добавьте массивы запоминающих устройств, что позволит разделить базы данных на сервере базы данных.

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

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

В предполагаемой конфигурации используется 1 веб-сервер, 13 серверов приложений и 3 сервера баз данных:

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

Три сервера приложений используются для обхода контента и администрирования. Это означает следующее:

На одном из серверов приложений создается центр администрирования и компонент администрирования поиска.

На каждом сервере присутствует два компонента обход контента. Каждый из этих компонентов присоединен к отдельной базе данных обхода контента.

Оставшиеся 10 серверов приложений используются для обработки запросов. Рекомендуется создать 10 разделов индекса. На каждом сервере развернут один основной компонент запросов из одного из разделов индекса, а также резервный компонент из другого раздела.

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

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

В этом разделе описывается топология тестовой среды.

В этом разделе описывается используемое при тестировании оборудование.

2 четырехъядерных процессора с тактовой частотой 2,33 ГГц

Windows Server 2008 R2 64-разрядная

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Тип службы балансировки нагрузки

Версия программного обеспечения

SharePoint Server 2010 (предварительная версия)

Службы, запущенные локально

В ферме развернуты 13 серверов приложений. 10 серверов используются для обработки запросов; 3 сервера обеспечивают обход контента.

2 четырехъядерных процессора с тактовой частотой 2,5 ГГц

2 четырехъядерных процессора с тактовой частотой 2,5 ГГц

Windows Server 2008 R2 64-разрядная

Windows Server 2008 R2 64-разрядная

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

4 жестких диска по 300 ГБ SAS 15000 об/мин: RAID10:БД

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС/БД

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Тип службы балансировки нагрузки

Версия программного обеспечения

SharePoint Server 2010 (предварительная версия)

SharePoint Server 2010 (предварительная версия)

Службы, запущенные локально

Служба поиска SharePoint Server; служба параметров сайтов и запросов поиска

Служба поиска SharePoint

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

2 четырехъядерных процессора с тактовой частотой 3,2 ГГц

4 двухъядерных процессора с тактовой частотой 2,19 ГГц

Windows Server 2008 R2 64-разрядная

Windows Server 2008 R2 64-разрядная

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД

6 жестких дисков по 450 ГБ SAS 15000 об/мин: RAID10: БД СВОЙСТВ

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1: БД АДМИНИСТРИРОВАНИЯ ПОИСКА, БД SharePoint

2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛЫ

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС

2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД

2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД

6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД1 ОБХОДА КОНТЕНТА

6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД2 ОБХОДА КОНТЕНТА

2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ1 БД ОБХОДА КОНТЕНТА

2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ2 БД ОБХОДА КОНТЕНТА

Число сетевых адаптеров

Скорость передачи данных сетевого адаптера

Версия программного обеспечения

SQL Server 2008 Enterprise

SQL Server 2008 Enterprise

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

Задержка запросов Эти измерения были выполнены в процессе тестирования на задержку запросов. Средством тестирования был отправлен набор стандартных запросов от имени одного пользователя, после чего была определена итоговая задержка. Во время тестирования обход контента не выполнялся.

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

Среднее значение использования ЦП SQL Server (сервер базы данных свойств)

Среднее значение использования ЦП интерфейсного веб-сервера

Среднее значение использования ЦП сервера запросов

Сбои интерфейсного веб-сервера

Сбои сервера приложений

(сервер базы данных свойств)

Коэффициент попадания в кэш (SQL Server)

Операций блокировки SQL Server: среднее время ожидания (мс)

Операций блокировки SQL Server: время ожидания блокировки (мс)

Операций блокировки SQL Server: взаимных блокировок в секунду

Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)

Компиляций SQL Server в секунду

Статистика SQL Server: повторных компиляций SQL Server в секунду

Соотношение чтение/запись (операций ввода/вывода для базы данных)

Средняя длина дисковой очереди (SQL Server)

Длина дисковой очереди: операций записи (SQL Server)

Обращений чтения с диска в секунду (SQL Server)

Обращений записи на диск в секунду (SQL Server)

Средняя длина дисковой очереди (сервер запросов)

Длина дисковой очереди: операций записи (сервер запросов)

Обращений чтения с диска в секунду (сервер запросов)

Обращений записи на диск в секунду (сервер запросов)

Средний объем использования памяти (сервер запросов)

Максимальный объем использования памяти (сервер запросов)

Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)

Средний объем использования памяти (интерфейсный веб-сервер)

Максимальный объем использования памяти (интерфейсный веб-сервер)

Число успешных запросов

Задержка пользовательского интерфейса запросов (75 процентиль)

Задержка пользовательского интерфейса запросов (95 процентиль)

Пропускная способность запросов

36,42 запроса в секунду

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

Среднее значение использования ЦП SQL Server (серверы баз данных обхода контента и свойств)

Максимальное значение использования ЦП SQL Server (сервер базы данных обхода контента и свойств)

Среднее значение использования ЦП индексатора

Сбои интерфейсного веб-сервера

Сбои сервера приложений

(серверы баз данных обхода контента и свойств)

Коэффициент попадания в кэш (SQL Server)

Операций блокировки SQL Server: среднее время ожидания [мс]

Операций блокировки SQL Server: максимальное время ожидания [мс]

Операций блокировки SQL Server: среднее время ожидания блокировки [мс]

Операций блокировки SQL Server: максимальное время ожидания блокировки [мс]

Операций блокировки SQL Server: взаимных блокировок в секунду

Операций кратковременной блокировки SQL Server: среднее время ожидания [мс]

Операций кратковременной блокировки SQL Server: максимальное время ожидания [мс]

Компиляций SQL Server в секунду: в среднем

Компиляций SQL Server в секунду: максимум

Статистика SQL Server: повторных компиляций SQL Server в секунду: в среднем

Статистика SQL Server: повторных компиляций SQL Server в секунду: максимум

Соотношение чтение/запись (операций ввода/вывода для базы данных): максимум

Средняя длина дисковой очереди (SQL Server)

Максимальная длина дисковой очереди (SQL Server)

Длина дисковой очереди: операций записи (SQL Server): в среднем

Длина дисковой очереди: операций записи (SQL Server): максимум

Обращений чтения с диска в секунду (SQL Server): в среднем

Обращений чтения с диска в секунду (SQL Server): максимум

Обращений записи на диск в секунду (SQL Server): в среднем

Обращений записи на диск в секунду (SQL Server): максимум

Средняя длина дисковой очереди (сервер обхода контента)

Длина дисковой очереди: операций записи (сервер обхода контента)

Обращений чтения с диска в секунду (сервер обхода контента)

Обращений записи на диск в секунду (сервер обхода контента)

Средний объем использования памяти (сервер обхода контента)

Максимальный объем использования памяти (сервер обхода контента)

Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)

Средний объем использования памяти (интерфейсный веб-сервер)

Максимальный объем использования памяти (интерфейсный веб-сервер)

Число успешных запросов

Скорость обхода контента портала (элементов в секунду)

Скорость обхода контента привязки (элементов в секунду)

Общая скорость обхода контента (элементов в секунду)

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

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

Общие сведения о минимальных и рекомендуемых требованиях к системе см. в разделе Требования к оборудованию и программному обеспечению (SharePoint Server 2010). Обратите внимание, что требования для серверов поиска имеют более высокий приоритет относительно общих требований к системе. Чтобы обеспечить соблюдение заданных показателей производительности, придерживайтесь следующих рекомендаций по объему ОЗУ, быстродействию процессора и числу операций ввода-вывода в секунду.

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

Существует несколько вариантов развертывания и настройки SharePoint Server 2010. Таким образом, не существует простого способа оценить, сколько пользователей или элементов будет поддерживаться для указанного количества серверов. Следовательно, перед развертыванием SharePoint Server 2010 в рабочей среде рекомендуется провести собственное тестирование.

В этом разделе описываются компоненты системы поисковых запросов для заданного приложения-службы поиска. Требования к масштабированию для каждого компонента приведены в таблице «Сведения о масштабировании» после следующего рисунка.

В следующем списке определяются объекты системы поисковых запросов, показанные на предыдущем рисунке:

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

Служба параметров сайтов и запросов поиска Также называется обработчиком запросов. При получении запроса из подключения прокси приложения-службы поиска обработчик запросов выполняет следующие действия:

Запрос отправляется в один активный компонент запросов для каждого раздела индекса (в базу данных свойств или в оба адресата, в зависимости от типа запроса)

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

Выполняется фильтрация результатов по ролям безопасности на основе дескрипторов безопасности в базе данных администрирования поиска

Из базы данных свойств извлекаются метаданные итогового набора результатов

Результаты запроса отправляются в прокси-службу

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

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

Активный — по умолчанию отвечает на запросы. Добавление нескольких активных компонентов в один раздел индекса позволяет увеличить пропускную способность.

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

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

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

Масштабируется с использованием интерфейсных веб-серверов, с которыми она связана.

Служба параметров сайтов и запросов поиска

Эта служба устанавливается на странице Службы на сервере центра администрирования и должна быть запущена на каждом сервере с компонентом запросов. При необходимости эту службу можно перенести на отдельный сервер (или пару серверов для более высокой доступности), чтобы высвободить ОЗУ серверов, на которых размещаются компоненты запросов. Использование настраиваемого триммера безопасности (Возможно, на английском языке) также может отрицательно повлиять на загрузку ЦП и ОЗУ.

Использует ОЗУ (кэш процессов) для кэширования дескрипторов безопасности индекса.

При увеличении числа разделов индекса уменьшается число элементов в каждом из них, что ведет к менее интенсивному использованию ОЗУ и дискового пространства на сервере запросов, на котором размещаются компоненты запросов, назначенные разделу индекса.

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

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

Объем ОЗУ (кэша операционной системы) для каждого активного компонента на сервере приложений должен обеспечивать хранение 33% индекса.

2000 операций ввода-вывода в секунду для каждой пары (активный/резервный) компонентов запросов для заданного сервера.

Компонент запросов выполняет операции ввода-вывода в следующих целях:

Загрузка индекса в ОЗУ для запросов

Запись фрагментов индекса, полученных от каждого компонента обхода контента

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

База данных администрирования поиска

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

Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения важной таблицы (MSSSecurityDescriptors) в ОЗУ.

База данных свойств

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

Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения 33% от объема важных таблиц (MSSDocSDIDs + MSSDocProps + MSSDocresults) в кэше.

30% чтение, 70% запись

В этом разделе описываются компоненты системы обхода при поиске. Требования к масштабированию для каждого компонента приводятся в таблице после рисунка.

В этом разделе определяются объекты системы обхода при поиске, показанные на предыдущем рисунке:

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

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

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

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

Система поисковых запросов

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

Компонент обхода контента

Компоненты обхода контента активно используют ресурсы ЦП. В идеальном варианте для каждого такого компонента требуется четыре выделенных ядра ЦП. Требования к ОЗУ носят менее критичный характер. В более крупных фермах для снижения воздействия программы-обходчика на другие компоненты компоненты обхода контента размещаются на выделенных серверах (особенно это касается сценариев с использование компонентов обхода, связанных с разными базами данных обхода контента в целях обеспечения избыточности).

Умеренное. Обратите внимание, что при обходе контента документов на восточноазиатских языках требования к ОЗУ возрастают в связи с поддержкой средств разбиения текста на слова.

База данных администрирования поиска

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

См. описание системы поисковых запросов выше.

База данных обхода контента

Базы данных обхода контента активно используют ресурсы подсистемы ввода-вывода. Требования к ОЗУ носят менее критичный характер. На операции, связанные с обходом контента затрачивается порядка 3500 операций ввода-вывода в секунду; при достаточной пропускной способности это число может возрастать до 6000.

73% чтение, 27% запись

Чтобы оценить требования к размеру хранилища, рассчитайте следующие коэффициенты. Коэффициенты масштабирования определяются на основе внутренней системы до развертывания с индексом, содержащим преимущественно контент SharePoint (размер базы данных контента 13,3 ТБ). В общем случае система поиска SharePoint использует приблизительно 20% от дискового пространства, занимаемого базой данных контента. Рекомендуется провести тестирование в собственной среде, прежде чем развертывать SharePoint Server 2010 в рабочей среде.

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

Даже если в собрании хранится в основном контент SharePoint, на величину коэффициентов могут дополнительно влиять следующие обстоятельства:

При наличии крупных репозиториев документов величины коэффициентов значительно возрастают.

Если собрание содержит преимущественно изображения, коэффициенты могут быть меньше.

Наличие многоязычного контента также может повлиять на величину коэффициентов.

Определите суммарный объем баз данных контента SharePoint, для которых будет выполняться обход контента. Это значение, ContentDBSum, будет использоваться при дальнейших вычислениях объема хранилища.

Определите полный размер индекса (располагается в компонентах запросов и используется для полнотекстовых запросов):

Умножьте величину ContentDBSum на 0,035. Будет получено значение TotalIndexSize до создания разделов и резервирования места для объединения и разбиения на разделы.

Далее определите число разделов в соответствии с архитектурой среды и сценарием. Рекомендуемый размер раздела индекса находится в диапазоне от 5 до 10 миллионов элементов. После этого можно рассчитать размер хранилища для компонента запросов.

Разделите значение TotalIndexSize на (число разделов индекса). Будет получено значение QueryComponentIndexSize, которое используется для расчета следующих величин:

Умножьте величину QueryComponentIndexSize на 0,33. Будет получено значение, соответствующее минимально необходимому объему ОЗУ для активного компонента.

Резервные компоненты потребляют ресурсы ОЗУ только после того, как переводятся в активное состояние.

Если на сервере присутствует несколько активных компонентов запросов, чтобы определить совокупные требования к ОЗУ, следует сложить требования для каждого из компонентов.

С помощью величины QueryComponentIndexSize также можно определить требования к дисковому пространству в зависимости от того, планируется ли разбиение индекса на разделы (т. е., планируется ли рост индекса свыше 10 миллионов элементов):

Умножьте величину QueryComponentIndexSize на 3. Будет получен объем дискового пространства для отдельного компонента запросов с учетом требований к пространству для объединения индекса.

Умножьте величину QueryComponentIndexSize на 4. Будет получен объем дискового пространства для отдельного компонента запросов с учетом требований к пространству для разбиения индекса на разделы.

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

Определите размеры баз данных свойств:

Умножьте величину ContentDBSum на 0,015. Будет получено значение TotalPropertyDBSize до разбиения на разделы.

Умножьте величину ContentDBSum на 0,0031. Будет получено значение TotalPropertyDBLogSize до разбиения на разделы. Предполагается, что базы данных SQL Server используют простую модель восстановления.

Умножьте величину ContentDBSum на 0,00034. Будет получена величина TempDBSize для базы данных свойств. Поскольку рекомендуется хранение 33% таблиц ключей базы данных свойств в ОЗУ, временная база данных используется неактивно.

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

Разделите величину TotalPropertyDBSize на (число баз данных свойств). Будет получено значение PropertyDatabaseSize.

Разделите величину TotalPropertyDBLogSize на (число баз данных свойств). Будет получено значение PropertyDatabaseLogSize.

Умножьте величину PropertyDatabaseSize на 0,33. Будет получено значение, соответствующее минимально необходимому объему ОЗУ для этой базы данных свойств.

Если на сервере баз данных развернуто несколько баз данных свойств, требования к дисковому пространству и ОЗУ для каждой из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду и ОЗУ (см. подраздел «Сведения о масштабировании» в разделе «Система поисковых запросов» этой статьи).

Далее определите размер базы данных контента:

Умножьте величину ContentDBSum на 0,046. Будет получено значение TotalCrawlDBSize до разбиения на разделы.

Умножьте величину ContentDBSum на 0,011. Будет получено значение TotalCrawlDBLogSize до разбиения на разделы. Предполагается, что базы данных SQL Server используют простую модель восстановления.

Умножьте величину ContentDBSum на 0,0011. Будет получена величина TempDBSize для базы данных обхода контента. Поскольку система обхода при поиске влияет на производительность временной базы данных, не рекомендуется размещать другие базы данных на серверах, на которых размещаются базы данных обхода контента, если это может привести к снижению производительности.

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

Разделите величину TotalCrawlDBSize на (число баз данных обхода контента). Будет получено значение CrawlDatabaseSize.

Разделите величину TotalCrawlDBLogSize на (число баз данных обхода контента). Будет получено значение CrawlDatabaseLogSize.

Если на сервере баз данных развернуто несколько баз данных обхода контента, требования к дисковому пространству для каждой из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду (см. подраздел «Сведения о масштабировании» в разделе «Система обхода при поиске» этой статьи). На выделенном сервере для баз данных обхода контента рекомендуется наличие как минимум 16 ГБ ОЗУ.

Определите размер базы данных администрирования поиска (предполагается применение проверки подлинности Windows):

Умножьте число элементов в индексе (в миллионах) на 0,3. Будет получено значение SearchAdminDBSize.

Умножьте величину SearchAdminDBSize на 0,33. Будет получено значение, соответствующее минимально необходимому объему ОЗУ для этой базы данных свойств.

Если на сервере баз данных развернуто несколько баз данных, требования к дисковому пространству и ОЗУ для каждой из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду и ОЗУ (см. подраздел «Сведения о масштабировании» в разделе «Система поисковых запросов» этой статьи).

Чтобы определить объем дискового пространства для резервного копирования одного приложения-службы поиска, выполните следующие вычисления:

Сложите величины TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize. Будет получен базовый размер резервной копии.

Базовый размер резервной копии является отправной точкой и может изменяться в зависимости от следующих факторов:

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

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

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

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

Для обслуживания 100 миллионов элементов требуется 10 разделов индекса.

Для обслуживания запросов требуется 10 активных компонентов запросов (по одному на каждый раздел индекса).

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

Чтобы определить требования к хранилищу и ОЗУ, выполните следующие действия:

В ферме SharePoint с несколькими базами данных контента совокупный объем включаемого в обход контента составляет 20 ТБ.

Умножьте 20 ТБ на 0,035 (коэффициент индекса). Будет получено значение TotalIndexSize, равное 716,8 ГБ. Если используется один раздел индекса, это значение определяет его размер.

Разделите значение TotalIndexSize на число разделов: 716,8 ГБ / 10 = 71,68 ГБ. Это размер индекса для каждого компонента запросов (QueryComponentIndexSize) с одним разделом индекса. Эта величина одинакова для активных и резервных компонентов запросов.

Умножьте TotalIndexSize на 4, если планируется разбиение индекса на разделы; в противном случае умножьте это значение на 3, чтобы обеспечить поддержку объединения с главной копией. 71,68 ГБ * 4 = 286,72 ГБ. Соответственно, для поддержки одного компонента запросов требуется 286,72 ГБ свободного дискового пространства на сервере запросов. Если на одном сервере приложений размещается два компонента запросов (как, например, в рекомендуемой для крупных ферм топологии «активный/резервный»), требования к дисковому пространству будут следующими:

Диск операционной системы (стандартный размер).

Дополнительная система хранения 1: общая папка компонента запросов 1 (размер не менее 300 ГБ), используется для активного компонента раздела индекса 1.

Дополнительная система хранения 2: общая папка компонента запросов 2 (размер не менее 300 ГБ), используется для активного компонента раздела индекса 2.

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

Приложение-служба поиска SharePoint

Рекомендуется не более 20 на ферму. Абсолютное ограничение составляет 256 приложений-служб.

В одной ферме можно развертывать несколько приложений-служб поиска SharePoint, поскольку компоненты и базы данных поиска можно назначать разным серверам.

Общее рекомендуемое ограничение составляет 10 миллионов элементов на каждый раздел индекса и 100 миллионов элементов на каждое приложение-службу поиска.

Служба поиска SharePoint поддерживает разделы индекса, каждый из которых содержит подмножество индекса поиска. Рекомендуемый максимум составляет 10 миллионов элементов для каждого раздела. Рекомендуемый максимум для общего числа элементов (пользователи, элементы списка, документы, веб-страницы) составляет 100 миллионов.

Рекомендуется не более 20 на каждое приложение-службу поиска.

Раздел индекса содержит логическое подмножество индекса приложения-службы поиска. Рекомендуемое ограничение составляет 20. Увеличение числа разделов индекса ведет к уменьшению числа элементов в каждом разделе. Это, в свою очередь, повлечет сокращение объема ОЗУ и дискового пространства, выделяемого на сервере запросов, на котором размещается компонент запроса, назначенный разделу индекса. Тем не менее, это может привести к снижению релевантности из-за уменьшения числа элементов в разделе индекса. Максимальное ограничение числа разделов индекса — 128.

База данных свойств

Рекомендуется не более 10 на каждое приложение-службу поиска.

В базе данных свойств хранятся метаданные для элементов в каждом связанном разделе индекса. Раздел индекса может быть связан только с одним хранилищем свойств. Рекомендуемое ограничение составляет 10 баз данных свойств для каждого приложения-службы поиска. Максимальное ограничение составляет 255 (аналогично разделам индекса).

Базы данных обхода контента

Ограничение составляет 32 базы данных обхода контента на приложение.

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

Компоненты обхода контента

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

Для минимального распространения ухудшений в производительности системы ввода-вывода общее число компонентов обхода контента для каждого сервера не должно превышать значения, вычисляемого по формуле 128/(общее число компонентов запроса). Превышение рекомендуемого ограничения не обязательно приведет к росту производительности обхода контента. В действительности, производительность обхода контента может уменьшиться в соответствии с наличием доступных ресурсов на сервере обхода контента и на узле, либо в базе данных.

Рекомендуемое ограничение составляет 128 на каждое приложение, 64/(общее число компонентов обхода контента) для каждого сервера.

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

Число параллельных обходов контента

Рекомендуется не более 20 на каждое приложение-службу поиска.

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

Рекомендуется не более 50 на каждое приложение-службу поиска.

Рекомендуемое ограничение в 50 источников может быть превышено вплоть до максимального ограничения, которое составляет 500 источников контента для каждого приложения-службы поиска. Тем не менее, при этом следует использовать меньшее число начальных адресов и соблюдать ограничение числа параллельных обходов контента.

Рекомендуется не более 100 начальных адресов на каждый источник контента.

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

Правила обхода контента

Рекомендуется не более 100 на каждое приложение-службу поиска.

Это значение может быть превышено, однако это может привести к снижению производительности правил обхода контента в системе администрирования поиска.

Журналы обхода контента

Рекомендуется не более 100 миллионов на каждое приложение.

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

Число распознанных свойств метаданных на элемент

Максимальное ограничение составляет 10 000.

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

Свойства для обхода

500 000 для каждого приложения-службы поиска

Свойства, которые будут обнаруживаться в процессе обхода контента.

100 000 для каждого приложения-службы поиска

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

Рекомендуемое ограничение составляет 200 для каждого сайта.

Это рекомендуемое ограничение для каждого сайта. Превышение этого ограничения может привести к снижению эффективности обхода контента и увеличению задержки в браузере конечного пользователя (в случае добавления областей в группу отображения). Также по мере превышения рекомендуемого ограничения на число областей снижается производительность при отображении областей в интерфейсе администрирования поиска.

25 для каждого сайта

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

Рекомендуемое ограничение составляет 100 правил для каждой области; всего 600 правил для каждого приложения-службы поиска.

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

Рекомендуемое ограничение составляет 200 для каждого семейства сайтов.

Рекомендуемое ограничение может быть превышено вплоть до максимального ограничения в 5000 для каждого семейства сайтов (задается в ASP.NET) при использовании пяти наиболее подходящих элементов на ключевое слово. Если это ограничение превышено, производительность отображения ключевых слов в пользовательском интерфейсе администрирования сайта при превышении этого ограничения будет ухудшаться. Устанавливаемое в ASP.NET ограничение может быть изменено посредством изменения файлов Web.config и Client.config (MaxItemsInObjectGraph).

Рекомендуемое ограничение — одна достоверная страница верхнего уровня и минимально необходимое для обеспечения релевантности число страниц второго и третьего уровня.

Максимальное ограничение составляет 200 на уровень релевантности для каждого приложения-службы поиска, однако добавление дополнительных страниц может привести к снижению релевантности. Добавьте ключевой сайт на первый уровень релевантности. При необходимости по одному добавляйте дополнительные ключевые сайты на второй или третий уровень релевантности и оценивайте релевантность после каждой операции добавления, чтобы гарантировать достижение нужной релевантности.

Рекомендуется не более 1 000 000 на каждое приложение-службу поиска.

Это проверенное ограничение.

100 URL-адресов за одну операцию

Это рекомендуемое максимальное количество URL-адресов, которое следует удалять из системы за одну операцию.

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

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

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

В общем случае оптимизация системы поисковых запросов требуется в следующих сценариях:

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

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

Горизонтальное и вертикальное масштабирование подсистемы запросов всегда предполагает создание дополнительных компонентов запросов. При наличии избыточных ресурсов (ОЗУ, подсистема ввода-вывода и ЦП) на существующем сервере запросов можно выполнить вертикальное масштабирование за счет создания на нем дополнительных компонентов. Это позволит повысить эффективность использования ОЗУ, ЦП или подсистемы ввода-вывода. В противном случае можно создать дополнительные компоненты (или перенести некоторые из существующих компонентов) на новом сервере (горизонтальное масштабирование).

В следующем разделе описываются различные способы добавления ресурсов запросов в систему поисковых запросов.

На следующем рисунке показаны результаты добавления активных компонентов запросов на отдельные серверы без изменения размера индекса.

Добавьте дополнительные активные компоненты запросов, чтобы сохранить величину задержку менее 1 секунды при увеличении нагрузки на систему (одновременного числа пользовательских запросов).

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

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

На следующем рисунке показаны результаты добавления активных компонентов запросов на отдельные серверы без изменения размера индекса.

Добавьте дополнительные активные компоненты запросов, чтобы повысить пропускную способность запросов при увеличении нагрузки на систему (одновременного числа пользовательских запросов).

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

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

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

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

Низкая скорость обхода из-за снижения производительности подсистемы ввода-вывода в подсистеме обхода при поиске.

Низкая скорость обхода из-за нехватки потоков ЦП в подсистеме обхода при поиске.

Низкая скорость обхода из-за высокой задержки отклика репозитория.

Во всех случаях проблемы связаны с низкой скоростью обхода контента. В разделе Use search administration reports (SharePoint Server 2010) (в рамках жизненного цикла программного обеспечения) приводятся рекомендации по определению базовой скорости обхода контента для системы. При ухудшении этого базового показателя необходимо устранить проблемы, связанные с производительностью, руководствуясь рекомендациями в следующих подразделах.

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

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

Если в среде присутствует большое число узлов и отсутствуют другие проблемы с производительностью обхода контента, необходимо масштабировать систему обхода контента с использованием нужного решения. Программа-обходчик поддерживает не более 256 потоков на одно приложение-службу поиска. Для полноценного использования преимуществ многопотоковой обработки рекомендуется наличие четырехъядерного процессора. Если точно определено, что скорость обработки данных в репозитории достаточно высока (см. раздел «Снижение производительности обхода контента из-за репозитория» этой статьи), можно повысить пропускную способность обхода за счет более быстрого запроса данных из репозитория (достигается путем увеличения числа потоков для программы-обходчика). Это можно реализовать одним из трех следующих способов:

Изменение уровня производительности индексатора на частично сокращенный или максимальный с помощью следующего командлета Windows PowerShell:

Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel «Maximum»

Значение Maximum следует применять при использовании процессора с числом ядер меньше 4.

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

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

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

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

Низкий (менее 20%) уровень использования ЦП на серверах обхода контента.

Большое число ожидающих потоков в сети (в худших случаях практически все потоки).

Определить наличие такой ситуации можно по значению счетчика производительности «Средство сбора данных поиска OSS/Потоков, обращающихся к сети».

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

После определения проблемного узла необходимо выявить причины высокой задержки отклика. Дополнительные сведения относительно контента SharePoint см. в статье Capacity management and sizing for SharePoint Server 2010.

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

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

Использование ЦП SQL Server (в %)

База данных свойств / база данных обхода контента

Ожидаемый срок жизни страницы SQL Server

База данных свойств / база данных обхода контента

Средняя длительность операции записи на диск (SQL Server)

База данных свойств / база данных обхода контента

466 мс / 1277 мс

253 мс / 1156 мс

Средняя длительность операции чтения с диска (SQL Server)

База данных свойств / база данных обхода контента

1362 мс / 2688 мс

2039 мс / 2142 мс

Использование ЦП программы-обходчика (в %)

Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)

Обращений записи на диск/сек

Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)

Обращений чтения с диска/сек

Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)

Среднее время записи на диск

Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)

1962 мс / 3235 мс

Среднее время чтения с диска

Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)

2366 мс / 5206 мс

В системе поиска SharePoint реализованы инструментированный конвейер запросов и связанные с ним административные отчеты, которые можно использовать при устранении неполадок, связанных с эффективностью запросов на стороне сервера. Дополнительные сведения см. в разделе Use search administration reports (SharePoint Server 2010). В этом разделе описываются некоторые отчеты и демонстрируется их применение для устранения неполадок на стороне сервера. Кроме того, в этом разделе описываются средства и приводятся рекомендации по устранению неполадок на стороне клиента (в браузере).

Проблемы, связанные с эффективностью запросов на стороне сервера, можно подразделить на два уровня:

Проблемы на стороне интерфейсных серверов поиска

Проблемы на стороне внутренних серверов поиска

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

В первую очередь при устранении неполадок такого рода необходимо ознакомиться с административным отчетом системы поиска «Общая задержка обработки запросов». Ниже приводится пример этого отчета:

В этом отчете показатели эффективности на стороне интерфейсных серверов представлены следующими рядами данных:

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

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

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

Проблемы, связанные с платформой, в том числе следующие:

Низкая скорость поиска Active Directory

Низкая скорость отклика SQL Server

Низкая скорость обработки запросов к приложению профиля пользователя в пользовательских запросах в SharePoint Server 2010 или во всех запросах в FAST Search Server 2010 для SharePoint

Низкая скорость обработки запросов на извлечение параметров пользователя

Низкая скорость обработки вызовов для получения маркера пользователя из службы маркеров безопасности

Проблемы, связанные с кодом программной части, в том числе измененные страницы результатов поиска (например, results.aspx и peopleresults.aspx), которые были возвращены, но не были опубликованы.

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

Проблемы на уровне Windows Communication Foundation (WCF), в том числе:

Истечение времени ожидания и исключения threadabortexception в вызовах WCF в развертывании.

Низкая скорость взаимодействия между интерфейсным веб-сервером и сервером приложений. Это может быть связано с ошибками протокола IPsec или низкой скоростью подключения к сети.

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

В первую очередь при устранении неполадок такого рода необходимо ознакомиться с административным отчетом системы поиска «Задержка обработки запросов к базе данных SharePoint». Ниже приводится пример этого отчета:

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

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

База данных свойств:

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

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

База данных администрирования поиска:

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

Наиболее достоверные результаты. Среднее время, затрачиваемое на извлечение наиболее достоверных результатов для запросов.

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

Удаление повторений. Среднее время, затрачиваемое на удаление повторений.

Заполнение результатов. Среднее время, затрачиваемое на создание в памяти таблиц, которые возвращаются в объектную модель.

Компоненты запросов, особенно в активном состоянии (в процессе обработки запросов), потребляют большой объем ресурсов. Устранение неполадок, связанных с эффективностью компонентов запросов, является одно из самых сложных задач при работе с системой поиска. Ниже приводятся общие рекомендации, которые следует учитывать в этом случае:

Наиболее ресурсоемким событием компонентом запросов является объединение с главной копией, в ходе которого теневые индексы объединяются с главным. Это событие возникает независимо для каждого компонента. Пример влияния этого события можно просмотреть в отчете «Задержка обработки запросов к базе данных SharePoint» (см. ранее в этой статье) в районе отметки 13:30. Если это событие влияет на задержку обработки запросов, можно определить периоды блокировки, в которые операции объединения с главной копией будут отключаться, если процент изменений не превышает заданного ограничения.

Если в среде постоянно наблюдаются высокие значения, рекомендуется выполнить следующие действия:

Проверьте размер индекса для каждого компонента на сервере. Убедитесь, что на сервере установлен объем ОЗУ, достаточных для хранения приблизительно 33% от совокупного размера индексов в кэше.

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

Если подсистема ввода-вывода и ОЗУ не являются причинами снижения производительности, следует выполнить разбиение индекса на разделы (добавить новые разделы индекса), а также горизонтальное масштабирование системы, добавив дополнительные компоненты запросов на новые серверы.

Проверьте работоспособность SQL Server, основываясь на рекомендациях раздела Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010). Если выполняются настраиваемые запросы, возможно, потребуется ознакомиться с рекомендациями по разработке плана запросов.

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

Фильтрация по ролям безопасности:

Для утверждений Windows проверьте подключение Active Directory к серверу, на котором размещается обработчик запросов.

Во всех случаях, если существует взаимосвязь с большим числом операций приема-передачи SQL Server (определяется в приложении SQL Server Profiler), можно увеличить размер кэша, используемого обработчиком запросов. Использовать вызовы SQL Server для извлечения дескрипторов безопасности из базы данных администрирования поиска должны не более 25% запросов. В противном случае следует увеличить размер кэша обработчика запросов.

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

Получение нескольких результатов:

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

Суммарное время загрузки страницы в пользовательском интерфейсе системы поиска не должно превышать 1 секунды. Из этого времени на стороне клиента (в зависимости от используемого браузера и способов измерения) затрачивается не более 280 миллисекунд. Если эти показатели соблюдаются, пользователи будут удовлетворены результатами.

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

Ниже приводятся общие рекомендации:

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

Пользователи обычно замечают изменения (увеличение или уменьшение скорости) с шагом в 20%. Учитывайте это при внесении изменений. 20% от стандартного времени отображения составляет всего 50 мс. (Источник: статья, посвященная управлению временем при проектировании (Возможно, на английском языке))

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

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

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

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

В системе поиска SharePoint на этапах получения, обслуживания и удаления индекса могут возникать узкие места, связанные с подсистемой обхода контента. Для эффективного устранения неполадок, связанных с обходом контента, используйте отчеты мониторинга работоспособности поиска, а также рекомендации, приведенные в разделе «Распространенные узкие места и причины их возникновения» этой статьи.

Основным способом определения проблем, связанных с обходом контента, является отчет «Скорость обхода по источникам контента». Как показано далее в этой статье, в этом отчете приводится обзор скорости обхода для каждого источника контента в системе. В общем случае скорость обхода должна превышать 15 документов в секунду для источников пользовательского контента и 35 документов в секунду для остальных источников контента.

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

Приостановите все процессы обхода контента, за исключением проблемного источника. Определите, возросла ли скорость обхода до рекомендуемого значения в 15 (35) документов в секунду?

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

Если узкое место не связано с репозиторием, проверьте производительность сервера обхода контента или сервера баз данных и оптимизируйте их работу. Соответствующие рекомендации см. в разделах «Снижение производительности подсистемы ввода-вывода» и «Снижение производительности из-за нехватки потоков ЦП» этой статьи.

Основная задача на этапе обслуживания индекса заключается в поддержании максимальной степени актуальности индекса. На данном этапе используется два ключевых индикатора:

Актуальность индекса. Заканчивается ли обход контента в установленное время и в соответствии с заданными ИТ-отделом ограничениями относительно актуальности индекса?

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

В ходе тестирования производительности было обнаружено несколько узких мест. Узкое место — это состояние, при котором достигается предельная емкость отдельного компонента фермы. Узкие места снижают пропускную способность фермы.

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

ОЗУ базы данных

База данных свойств

Характеристики базы данных администрирования поиска:

Диспетчер буферов SQL Server/ожидаемый срок жизни страницы 1000 с)

Диспетчер буферов SQL Server/коэффициент попадания в кэш буфера 98%)

Увеличьте объем памяти сервера баз данных.

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

Убедитесь, что используется выпуск SQL Server 2008 Enterprise, поддерживающий сжатие страниц.

Переместите базу данных на отдельный сервер (при необходимости добавьте несколько баз данных свойств).

Подсистема ввода-вывода сервера баз данных

Характеристики базы данных свойств или обхода контента:

Среднее время чтения с диска и среднее время записи на диск

50 мс или > 50 мс

Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения 33% от объема важных таблиц (MSSDocSDIDs + MSSDocProps + MSSDocresults) в кэше.

Увеличьте зарезервированное число операций ввода-вывода для базы данных, выполнив следующие действия:

Используйте разные массивы запоминающих устройств.

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

Запустите анализатор работоспособности системы поиска SharePoint — правило индексов одной или нескольких баз данных свойств фрагментировано (если отключено).

Запустите анализатор работоспособности системы поиска SharePoint — правило индексов одной или нескольких баз данных обхода контента фрагментировано.

Убедитесь, что используется выпуск SQL Server 2008 Enterprise, поддерживающий сжатие страниц.

Переместите базу данных на отдельный сервер (при необходимости добавьте несколько баз данных свойств или обхода контента).

Подсистема ввода-вывода компонента запросов

Характеристики логического диска, используемого для хранения индекса компонента запросов:

Среднее время чтения с диска и среднее время записи на диск в течение длительного времени составляет около 30 мс или > 30 мс (в течение большей части дня, а не только в процессе объединения индекса).

Убедитесь, что на каждом сервере приложений выделен достаточный объем для хранения 33% индекса каждого из активных компонентов (на этом сервере) в кэше (кэш операционной системы).

Увеличьте зарезервированное число операций ввода-вывода для диска, который используется для хранения индекса компонента запросов, выполнив следующие действия:

Используйте разные массивы запоминающих устройств для разных компонентов.

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

Брайон Стоун (Brion Stone), ведущий руководитель программы системы поиска SharePoint Server в корпорации Майкрософт.

Вам также может быть интересно

Обучение программированию

Эффективный способ применения интерфейсов в mdi приложениях

Многооконный интерфейс. Создание MDI-приложения , страница 3 Вместо дополнительных байт окна приложение может использовать

Обучение программированию

Язык xml стилевые таблицы xsl

Отображение XML с использованием XSLT При помощи XSLT вы можете преобразовывать XML документ в

Обучение программированию

Эффекты с изображениями

Как сделать — визуальные эффекты изображениям Узнайте, как добавить визуальные эффекты к изображениям. Фильтры

Обучение программированию

Язык xml схемы данных

Понимание XML Узнайте, как Расширяемый язык разметки (Extensible Markup Language — XML) облегчает универсальный

Обучение программированию

Юмор пиво для программиста

ХАЙФХАК: ПРОГРАММИСТ ВЗЛОМАЛ СИСТЕМУ, ЧТОБЫ ПОПИТЬ ПИВО БЕСПЛАТНО / пиво :: geek новости ::

Обучение программированию

Язык обработки данных awk

Примеры команды AWK в Linux Введение AWK назван в честь фамилии его авторов: Альфред

Обучение программированию

Я загружаю timagelist динамически как сделать картинки из timagelist прозрачными

Я загружаю timagelist динамически как сделать картинки из timagelist прозрачными? Элемент управления ImageList содержит

Обучение программированию

Язык преобразований xsl (xslt)

Введение в XSLT XSLT представляет собой способ для XML-документов в другие XML или документы

Обучение программированию

Является ли указанная страница — домашней (IE)

Является ли указанная страница — домашней? (IE) При создании новой вкладки (about:Tabs) в IE9

Обучение программированию

Язык преобразований XSLT

Справочник по интерфейсу администратора Ссылки Назад «> Вверх Вперед Опубликованные SQL View > XSLT

Обучение программированию

Ядро и процессы

Что такое ядро в биологии? Строение и функции ядра В каждой живой клетке протекает

Обучение программированию

Язык программирования alfa

Язык программирования alfa По питанию контроллеры делятся на два типа: с питанием 220 В

Обучение программированию

Язык cc

C++ — Базовый синтаксис Когда мы рассматриваем программу на C ++, ее можно определить

Обучение программированию

Язык рефал

Язык рефал Ура! Сегодня, 30.05.2005, наконец появилась адаптированная к современным платформам Windows-(95/98/ME/NT/2000/XP) и UNIX

Обучение программированию

Эффект pазвивающегося флага

Scrontch’s Flag Designer Design Your Flag! Generates Scalable Vector Graphics (SVG). This App requires

Обучение программированию

Язык sql

SQL-Урок 1. Язык SQL. Основные понятия. Для того, чтобы начать изучать SQL нам нужно

Обучение программированию

Язык с

C++ с нуля Этот самоучитель создан для тех, кто хочет освоить основы программирования на

Обучение программированию

Эффект горящей надписи

Простой огненный текст в Фотошопе Конечный результат: Ресурсы урока: Шаг 1 Создайте новый документ

Обучение программированию

Язык xml documents type definitions (dtd)

Язык XML — практическое введение . Documents Type Definitions (DTD) В XML- документах DTD

Обучение программированию

Языки и грамматики простейший компилятор

ГРАММАТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯ Описанию грамматики языка предшествует описание его алфавита. Алфавит любого языка состоит

Обучение программированию

Эффект ледяной надписи

Ледяной текст в Фотошопе Конечный результат: Ресурсы урока: 1. Создание фона Шаг 1 Создайте

Обучение программированию

Язык xml dom совместимые анализаторы

XML-анализаторы в java XML как набор байт в памяти, запись в базе или текстовый

Обучение программированию

Языки описания пользовательских интерфейсов

Языки описания пользовательских интерфейсов Язык описания интерфейсов Язык описания интерфейсов (IDL), используемый OMG определяет

Обучение программированию

Эффект линзы (watcom c)

Эффект линзы (watcom c) Просветляющие покрытия от ZEISS Высококачественные линзы требуют высоколассного подхода: защита,