Тестирование производительности базы данных с помощью 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 методологий тестирование производительности также интегрируется в жизненный цикл разработки программного обеспечения.
На рисунке ниже показана основная классификация видов тестирования производительности.
На основе классификации показанной на рисунке выше можно выделить основные виды тестирования, которые производятся во время этапа тестирования производительности системы. Основные типы тестирования и вопросы, которые они решают представлены в таблице.
№ | Вид тестирования | Вид тестирования по английский | Вопрос на который отвечает тестирование |
---|---|---|---|
1 | Нагрузочное тестирование | Load Testing[2] | Достаточно ли быстро работает система? |
2 | Тестирование стабильности | Stability Testing[3] | Достаточно ли надежно работает система на долгом интервале времени? |
3 | Тестирование отказоустойчивости | Failover Testing[4] | Сможет ли система переместиться сама на другой сервер в случае сбоя основного сервера? |
4 | Тестирование восстановления | Recovery Testing[5] | Как быстро восстановится система? |
5 | Стрессовое тестирование | Stress Testing[6] | Что произойдет при незапланированной нагрузке? |
6 | Тестирование объемов | Volume Testing[7] | Как будет работать система, если объем базы данных увечится в 100 раз? |
7 | Тестирование масштабируемости | Scalability Testing[8] | Как будет увеличиться нагрузка на компоненты системы при увеличении числа пользователей? |
8 | Тестирование потенциальных возможностей | Capacity Testing[9] | Какое количество пользователей может работать? |
9 | Конфигурационное тестирование | Configuration Testing[10] | Как заставить систему работать быстрее? |
10 | Тестирование сравнения | Compare Testing[11] | Какое оборудование и ПО выбрать? |
Нагрузочное тестирование (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 и операционной системы. Однако этот путь имеет ряд недостатков:
- Увеличивается производительность hardware, а вовсе не быстродействие ПО;
- Производительность hardware ограничена возможностями существующих в данный момент элементной базы и инженерных решений в данной области;
- Большие финансовые затраты на модернизацию и настройку по причине высокой стоимости комплектующих ЭВМ и услуг специалистов требуемой квалификации.
По этим причинам при разработке ПО прибегают к увеличению его быстродействия с помощью различных средств программной инженерии. Это позволяет:
- Обеспечить работу нового ПО на уже существующем оборудовании;
- Разработать масштабируемое ПО;
- Значительно уменьшить финансовые и трудовые затраты при внедрении.
Вместе с тем и у этого пути имеется ряд недостатков:
- Значительно усложняется процесс разработки ПО, так как более «быстрые» алгоритмы сложнее более «медленных» (на пример алгоритм бинарного поиска сложнее, чем алгоритм линейного поиска) [2];
- Реализация более сложных алгоритмов, как правило, требует привлечения специалистов более высокой квалификации;
- В случае работы с большими объёмами данных или выполнении задач требующих больших и сложных вычислений, ресурсоёмкость ПО всё равно остаются достаточно высокой. Несмотря, на какие либо способы увеличения быстродействия.
Таким образом, в общем случае обеспечение быстродействия ПО является комплексной задачей.
Однако следует заметить, что среди существующих задач, очень немногие обладают высокой ресурсоёмкостью. Вследствие этого в большинстве случаев не требуется никаких действий относительно hardware и требуемого результата можно достичь, прибегая только к программной инженерии.
Программная инженерия предоставляет несколько способов увеличения быстродействия программ. Рассмотрим их на примере языков программирования Delphi и Assembler.
Увеличение быстродействия программ.
Как было показано в предыдущем параграфе, можно увеличить быстродействие ПО соответствующим образом реализовав его алгоритмы. Количественным показателем быстродействия алгоритма (а, следовательно, и ПО) является время его выполнения, измеренное по специальной методике, так называемого профилирования [2]. Таким образом, в общем случае выбор наиболее «быстрых» алгоритмов сводится к измерению времени их выполнения и сравнении полученных результатов между собой. Такой способ анализа быстродействия является наиболее объективным [2]. На протяжении многих лет программистами был накоплен большой опыт профилирования, который позволяет сделать определённые выводы относительно возможности оптимизации быстродействия ПО ещё на стадии написания.
Эти выводы были обобщены и представлены в виде определённых рекомендаций [2, 4]. Если программист будет следовать данным рекомендациям, то написанная программа вероятнее всего будет обладать большим быстродействием, чем в случае их игнорирования. Однако следует ещё раз подчеркнуть, что достоверные сведения о быстродействии может дать только профилирование. Это обусловлено тем, что быстродействие алгоритма определяет в первую очередь его конкретная реализация. Кроме того необходимо ещё раз отметить, что в отношении увеличения быстродействия ПО программная инженерия не всесильна (см. предыдущий параграф).
В чём же состоят выше упомянутые рекомендации? Их краткое содержание применительно к языку программирования Delphi приведено ниже.
- При написании кода программ рекомендуется избегать процедур, состоящих из сотен строк. Практически всегда в них можно выделить блоки, которые лучше оформить в виде отдельной процедуры. Возможно, позже вы ей даже воспользуетесь где-то в другом месте. Не говоря уже о том, что это повышает понимание программы и вами, и другими программистами. К тому же так проще искать «узкие» места в программе.
- Использование оператора case (switch) вместо многократных if… then… else (if… else). Во втором варианте компилятор будет выполнять проверку условия столько раз, сколько у вас вариантов. В первом проверка выполняется лишь однажды.
- Некоторые действия могут быть довольно продолжительными, поэтому рекомендуется выносить за рамки цикла всё, что можно выполнить вне его, чтобы избежать большого числа повторений внутри цикла.
- В циклах типа for нужно стараться, чтобы значение счетчика уменьшалось до нуля, а не наоборот — начиналось с нуля. Это связано с особенностями процессора. Сравнение с нулём выполняется гораздо быстрее, чем с другим числом.
- Пользоваться типом Variant только при необходимости. Операции над этим типом сложнее, чем, например, над Integer или String.
- Не злоупотреблять «программированием на компонентах». В частности не использовать компонент TTreeView для хранения древовидных структур данных — он работает очень медленно и предназначен только для визуального отображения. В случае работы со структурами данных лучше использовать алгоритмы, созданные самостоятельно на основе фундаментальных.
- Сохранение и загрузка свойств компонентов с помощью методов ReadComponent и WriteComponent работает довольно медленно, поэтому по возможности рекомендуется сохранять и восстанавливать состояние программы между сеансами при помощи других способов.
- Заменить простой в реализации алгоритм на более сложный, но с большим быстродействием. Например, если заранее известно, что в списке для поиска будет много элементов, лучше его отсортировать и применять бинарный поиск вместо линейного.
- В критических с точки зрения быстродействия местах программы делать вставки на ассемблере. Команды ассемблера напрямую транслируются в машинный код. Таким образом, в отличие от высокоуровневых языков при компиляции отсутствует проблема синхронизации и ряд других негативных обстоятельств.
Для других языков программирования вышеприведённый список может несколько отличаться, в частности отсутствием поддержки ассемблера и как следствие возможности оптимизации с его помощью (Java, Visual C# и др.).
Особо следует отметить, что рекомендации 3 и 4 применяются не только для языков высокого уровня, но и для ассемблера. Помимо вышеуказанных для увеличения быстродействия программ написанных на ассемблере, в том числе и вставок, существуют следующие рекомендации [3]:
- Замещение универсальных инструкций на учитывающие конкретную ситуацию, например, замена умножения на степень двойки на команды сдвига (отказ от универсальности).
- Уменьшение количества передач управления в программе: за счет преобразования подпрограмм в макрокоманды для непосредственного включения в машинный код; за счет преобразования условных переходов так, чтобы условие перехода оказывалось истинным значительно реже, чем условие для его отсутствия; перемещение условий общего характера к началу разветвленной последовательности переходов; преобразование вызовов, сразу за которыми следует возврат в программу, в переходы («сращивание хвостов» и «устранение рекурсивных хвостов») и т.д.
- Максимальное использование всех доступных регистров за счет хранения в них рабочих значений всякий раз, когда это возможно, чтобы минимизировать число обращений к памяти, упаковка множественных значений или флагов в регистры и устранение излишних продвижений стека (особенно на входах и выходах подпрограмм).
- Использование специфических для данного процессора инструкций, например, инструкции засылки в стек непосредственного значения, которая имеется в процессоре 80286 и более поздних. Другие примеры – двухсловные строковые инструкции, команды перемножения 32-разрядных чисел, деление 64-разрядного на 32-разрядное число и умножение на непосредственное значение, которые реализованы в процессорах 80386 и 80486. Программа должна, разумеется, вначале определить, с каким типом процессора она работает!
Заключение.
Методы оптимизации быстродействия, рассмотренные в этой статье, были выработаны и проверены не одним поколением программистов и уже стали классическими. В то же время информационные технологии, в частности технологии программирования, постоянно развиваются. Появляются новые технологии, старые – модернизируются или уходят в прошлое. Растёт производительность аппаратной части ЭВМ и параллельно с этим растёт сложность и ресурсоёмкость выполняемых ими задач.
Поэтому вопрос оптимизации быстродействия сейчас актуален также как и много лет назад. Более того он будет также актуален и в будущем.
Список литературы и источников.
- Быстро и легко. Сборка, диагностика, оптимизация и апгрейд современного компьютера/ под ред. Печникова В.Н. Учебное пособие – М.: Лучшие книги, 2005;
- Бакнелл Д. Фундаментальные алгоритмы и структуры данных в Delphi. М.: ООО «ДиаСофтЮП»; СПб.: Питер, 2006;
- Дункан Р. Оптимизация программ на ассемблере./ Дункан Р.//PC Magazine/Russian Edition №1/1992;
- Список пропускных способностей интерфейсов передачи данных;
- Гапанович А. Как сделать свою программу быстрой./Компьютерра 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 миллионов элементов, должен иметь один раздел. На каждом сервере развернут один основной компонент запросов из раздела индекса. Такая конфигурация компонента запросов в режиме «активный/активный» позволяет обеспечить работоспособность даже в случае отказа одного из компонентов поиска, когда нагрузка по обработке запросов переносится на оставшийся компонент. При отказе одного из компонентов система поиска пересылает запросы на следующий доступный компонент запросов (используется алгоритм циклического перебора).
Один сервер приложений используется для обхода контента и администрирования. На нем создаются центр администрирования (обеспечивает управление системой поиска) и компонент обхода контента.
Отдельный сервер базы данных, обеспечивающий работу фермы. На этом сервере должно быть зарезервировано определенное число операций операций ввода-вывода в секунду для баз данных обхода контента, свойств и администрирования (например, могут использоваться разные массивы запоминающих устройств).
В этом разделе приведены подробные сведения об оборудовании, программном обеспечении, топологии и конфигурации этой тестовой среды.
Note |
---|
Поскольку в тестовой ферме были развернуты предварительные выпуски SharePoint Server 2010, чтобы избежать потенциальных проблем, на серверах использовалось оборудование большей, чем обычно требуется, производительности. |
Веб-сервер | Интерфейсный веб-сервер/сервер запросов (1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Сервер | Сервер запросов (1) | Сервер обхода контента/администрирования (1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
База данных | Общая (1) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Note |
---|
В связи с уменьшением числа дисков, рекомендация по разделению баз данных по различным каналам ввода-вывода не применима. |
Число сетевых адаптеров
Скорость передачи данных сетевого адаптера
Версия программного обеспечения
Microsoft SQL Server 2008 Enterprise
В этом разделе описывается нагрузка, используемая для формирования данных, включая число пользователей и характеристики использования фермы.
Характеристики рабочей нагрузки | Значение | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Объект | Значение | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Показатель системы показателей | Задержка запросов | Пропускная способность запросов | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Показатель системы показателей | Контент SharePoint (4 млн.) | Общая папка (1 млн.) | HTTP (не SharePoint) (1 млн.) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Note |
---|
Поскольку в тестовой ферме были развернуты предварительные выпуски SharePoint Server 2010, чтобы избежать потенциальных проблем, на серверах использовалось оборудование большей, чем обычно требуется, производительности. |
Веб-сервер | Интерфейсный веб-сервер (1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Сервер (число) | Сервер запросов (4) | Сервер обхода контента (1), сервер обхода контента/администрирования (1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Сервер базы данных | Базы данных администрирования поиска, свойств и другие базы данных SharePoint | Базы данных обхода контента | |||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Характеристики рабочей нагрузки | Значение | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Объект | Значение | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Показатель системы показателей | Задержка запросов | Пропускная способность запросов | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Показатель системы показателей | Контент SharePoint (3,5 млн.) | Общая папка (1 млн.) | HTTP (не SharePoint) (1 млн.) | |||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Note |
---|
Поскольку в тестовой ферме были развернуты предварительные выпуски SharePoint Server 2010, чтобы избежать потенциальных проблем, на серверах использовалось оборудование большей, чем обычно требуется, производительности. |
Веб-сервер | Интерфейсный веб-сервер (1) | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Сервер (число) | Сервер запросов (10) | Сервер обхода контента (2), сервер обхода контента/администрирования (1) | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Сервер базы данных | Базы данных администрирования поиска, свойств и другие базы данных SharePoint | Базы данных обхода контента | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Показатель системы показателей | Пропускная способность запросов | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Показатель системы показателей | Контент SharePoint (3,5 млн.) | Общая папка (1 млн.) | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Объект | Рекомендации по масштабированию | ОЗУ | Число операций ввода-вывода в секунду (чтение/запись) | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Объект | Рекомендации по масштабированию | ОЗУ | Число операций ввода-вывода в секунду (необязательно, % чтение/запись) | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Note |
---|
На этом сервере приложений с одним активным компонентом запросов потребуется как минимум 71,68 ГБ * 0,33 = 23,65 ГБ ОЗУ + 3 ГБ ОЗУ для операционной системы (фактически используется 32 ГБ) для кэширования большинства запросов. |
В следующей таблице приводятся ограничения программного обеспечения, связанные с поддержкой допустимого интерфейса поиска.
Объект | Ограничение | Дополнительные примечания | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Топология (Компонент обхода контента/ база данных обхода контента) | Использование ЦП | ОЗУ: коэффициент попадания в кэш буфера % | Задержка чтения | Задержка записи | Скорость обхода контента (документов в секунду) | |
---|---|---|---|---|---|---|
Показатель | Получение индекса | Обслуживание индекса | Очистка индекса |
---|---|---|---|
Узкое место | Признак (счетчик производительности) | Решение |
---|---|---|