Отчет по нагрузочному тестированию 1с
Перед запуском 1С:Документооборот для средних и крупных внедрений крайне желательно провести нагрузочное тестирование, чтобы проверить корректность и скорость работы системы электронного документооборота в условиях максимальной нагрузки. В данной статье пойдет речь о том, как провести нагрузочное тестирование в 1С:Документооборот без использования 1С:КИП.
Рассмотрим упрощенное нагрузочное тестирование, которое встроено в типовую конфигурацию 1С:Документооборот КОРП или ДГУ. При этом можно не приобретать дополнительно 1С:КИП (корпоративный инструментальный пакет).
Подготовка эталонной базы СЭД для нагрузочного тестирования
Для проведения нагрузочного тестирования нужно создать эталонную базу СЭД 1С Документооборот. В качестве эталонной базы может выступать прототип или копия рабочей базы.
Необходимо установить следующие флажки в настройках программы под Администратором. В настройках по делопроизводству:
- Виды входящих документов,
- Виды исходящих документов,
- Виды внутренних документов,
- Учет по организациям,
- Вопросы деятельности,
- Управление мероприятиями,
- Грифы доступа,
- Категории для документов и файлов,
- настройку "Штрихкодирование документов" отключаем.
В настройках по процессам и задачам:
В настройках по правам доступа:
Также нужно включить настройку "Выполнять замеры производительности" в общих настройках программы.
И можно настроить автоматический экспорт замеров производительности.
Нужно обязательно заполнить следующие справочники:
- Виды внутренних документов – для каждого вида документа должны быть установлены настройки "Автоматически вести состав участников рабочей группы" и "Вести учет по корреспондентам" (довольно странное требование, так как в копии рабочей базы или прототипе далеко не всем видам документам нужны такие настройки).
- Виды входящих документов – для каждого вида документа должна быть установлена настройка "Автоматически вести состав участников рабочей группы".
- Виды исходящих документов – для каждого вида документа должна быть установлена настройка "Автоматически вести состав участников рабочей группы".
- Организации.
- Грифы доступа.
- Вопросы деятельности.
- Папки внутренних документов.
- Папки мероприятий.
- Корреспонденты.
Если видов документов много, то указанные настройки быстрее установить с помощью обработки "Групповое изменение реквизитов" в разделе "Настройка и администрирование".
Указываем справочник "Виды внутренних документов".
Выбираем реквизиты и значения, которые хотим изменить и нажимаем кнопку "Изменить реквизиты".
Аналогично поступаем со справочниками "Виды входящих документов" и "Виды исходящих документов".
Сценарии тестирования, входящие в типовую поставку 1С:Документооборот
Откроем конфигуратор 1С:Документооборот. И в конфигурации установим отбор по подсистеме НагрузочноеТестирование .
В общем модуле НагрузочноеТестированиеСценарииСтандартные указаны типовые сценарии.
В общем модуле НагрузочноеТестированиеСценарии содержится код пользовательских сценариев. В этом модуле основные сценарии вызывают стандартные сценарии из модуля НагрузочноеТестированиеСценарииСтандартные .
В комментариях перед каждой функцией можно посмотреть из каких шагов состоит каждый сценарий. Также полезным будет оценить среднее время на выполнение сценария.
Функция СозданиеВнутреннегоДокумента()
// Сценарий создания внутреннего документа.
// Шаги сценария:
// 1. Открытие списка внутренних документов, если он еще не открыт (пауза 5с).
// 2. Переключение режима просмотра на случайное (пауза 5с).
// 3. Если режим просмотра "По папкам", тогда переход к папке (пауза 5с).
// 4. Выполнение команды "Создать документ" в списке (пауза 5с).
// 5. Выбор шаблона создаваемого документа в форме выбора шаблона (пауза от 20с до 30с).
// 6. Выполнение команды "Создать по шаблону" в форме выбора шаблона (пауза 5с).
// 7. Заполнение реквизитов документа в форме документа (пауза от 60с до 180с).
// 8. Выполнение команды "Записать" в форме документа (пауза 5с).
// 9. Закрытие формы документа (пауза 5с).
Функция СозданиеИсходящегоДокумента()
// Сценарий создания исходящего документа.
// Шаги сценария:
// 1. Открытие списка исходящих документов, если он еще не открыт (пауза 5с).
// 2. Выполнение команды "Создать документ" в списке (пауза 5с).
// 3. Выбор шаблона создаваемого документа в форме выбора шаблона (пауза от 20с до 30с).
// 4. Выполнение команды "Создать по шаблону" в форме выбора шаблона (пауза 5с).
// 5. Заполнение реквизитов документа в форме документа (пауза от 60с до 180с).
// 6. Выполнение команды "Записать" в форме документа (пауза 5с).
// 7. Закрытие формы документа (пауза 5с).
Стандартный нагрузочный тест предназначен для оценки производительности серверного оборудования и программного обеспечения в так называемых «Стандартных пользователях 1С». Основная область применения данного теста — выбор конфигурации серверного оборудования и программного обеспечения для целей конкретного внедрения.
Решаемые задачи
- Расчет производительности данной конфигурации серверного оборудования и программного обеспечения
- Сравнение производительности различных конфигураций серверного оборудования и программного обеспечения
- Выбор оборудования, необходимого для работы данной информационной системы
- Расчет параметров оборудования, необходимого для работы данной информационной системы
Что оценивает тест
Тест оценивает производительность всей совокупности серверного оборудования и серверного программного обеспечения с точки зрения задач, типичных для систем, работающих на платформе «1С:Предприятие 8». То есть полученная оценка отражает не производительность какого-то одного серверного компонента системы (например, рабочего сервера кластера «1С:Предприятия»), а всей серверной конфигурации в целом. Серверная часть системы, производительность которой измеряется данным тестом, включает в себя:
- все рабочие серверы, использованные для развертывания кластера «1С:Предприятия» и серверы СУБД
- операционные системы всех рабочих серверов;
- настройки операционных систем, «1С:Предприятия» и СУБД.
При проведении тестирования тест будет автоматически увеличивать количество одновременно работающих пользователей до тех пор, пока один из аппаратных или программных компонентов системы не перестанет справляться с нагрузкой. Это приведет к получению плохой оценки производительности, и тест остановится, выдав последнее хорошее значение в качестве результата. При этом остальные компоненты могут оказаться в той или иной степени недогруженными.
Таким образом, тест оценивает производительность серверной части системы по самому узкому месту, то есть ее наименее производительному компоненту.
Если серверная часть системы недостаточно хорошо сбалансирована для работы с «1С:Предприятием», то при устранении узкого места (замене или апгрейде наименее производительного компонента) можно будет получить более высокую оценку производительности.
Следует обратить внимание на то, что тест никак не оценивает производительность клиентской части системы, поэтому этот фактор должен быть полностью исключен. Иначе говоря, клиентские рабочие места не должны стать узким местом системы. Этот вопрос более детально обсуждается в главе «Подготовка клиентской части тестового стенда».
Как работает тест
Стандартный нагрузочный тест представляет собой информационную базу «1С:Предприятия 8.2» с конфигурацией, основанной на «Управлении производственным предприятием». Конфигурация объединена с «Тест-центром 2.0», в состав которого включен один сценарий тестирования.
Сценарий тестирования включает в себя эмуляцию бизнес-процесса «продажи в УПП», а именно: создание нескольких различных документов, формирование отчетов и другие прикладные действия. Тест работает в режиме полной параллельности, то есть каждый пользователь работает с собственными уникальными данными, и ожиданий на блокировках не возникает. Пользователь выполняет один полный цикл продажи в минуту.
Каждый специалист поддержки имеет опыт получения абстрактных жалоб со стороны пользователей. Всем знакомы формулировки: «она очень долго думает», «у меня красное окно», «система работает как-то не так», а также «этого давно не было, и вот опять».
В такой ситуации сходу разобраться, где кроется ошибка, и что предпринять в первую очередь, очень сложно. В этой статье рассмотрим от чего зависит производительность 1С, т.е. высоконагруженных систем, созданных на базе «1С:Предприятие», в ситуациях, когда симптоматика не до конца понятна и конкретный диагноз поставить невозможно.
Рис.1 Производительность 1С: замеры, оценка нагрузки, тестирование
Основные причины, влияющие на производительность 1С
Более чем в 60% случаев причинами низкой производительности оказываются:
- Неоптимальные запросы и программный код конфигурации (26% случаев);
- Неоптимальная индексация таблиц объектов (19% случаев);
- Неоптимальная нагрузка на дисковую подсистему (16% случаев).
С этим солидарны и ведущие разработчики Microsoft
Таким образом, получить значимое улучшение производительности приложения базы данных, можно оптимизировать область доступа к данным, включая логическое и физическое проектирование баз (насколько это возможно в 1С), а также посредством создания правильных запросов и использования оптимальной индексации. Часть проблем с производительностью баз данных может быть решена с помощью наращивания аппаратных мощностей, но не всегда: неправильная проектировка прикладного решения не может быть компенсирована более мощным сервером. Не редки случаи, когда, не разобравшись с причинами проблемы производительности, компании-пользователи идут на серьезные затраты, приобретая новое оборудование, а проблема так и остается нерешенной.
Качественная диагностика производительности 1С с применением всего спектра существующих инструментов – залог успешного решения проблем и оптимизации затрат
Первым шагом к выявлению и устранению проблем низкой производительности должно стать составление полного перечня ключевых проблемных операций, с указанием точной скорости их выполнения на текущий момент и ожидаемой скорости их выполнения в будущем.
Не правильно: При формировании отчета программа «зависает». Хочу, чтобы формировала быстрее.
Правильно: Формирование отчета «Ведомость по задолженности» осуществляется 5 минут 10 секунд. Ожидаемая скорость формирования данного отчета – не более 20 секунд.
После того как перечень проблем составлен и оцифрован, необходимо провести анализ причин, начав с поисков проблемного кода, если таковой имеется (например, «тяжелые» запросы, длительные ожидания на блокировках, deadlock’и пр.).
Инструменты для идентификации проблемного кода
- «1С:Центр управления производительностью» (модуль, входящий в инструментальный пакет «1С:Корпоративный», производителем которого является фирма 1С);
- Облачные сервисы Гилева;
- Штатные инструменты, встроенные в СУБД ведущих вендоров.
Эффективность использования данных инструментов гарантирует квалификация разработчика «1С:Эксперт по технологическим вопросам», подразумевающая его участие в масштабных внедрениях 1С. При этом разные эксперты, исходя из своего индивидуального опыта, могут отдавать предпочтения тому или иному инструменту/методу.
Параллельно с использованием одного из представленных инструментов, применяются и штатные средства мониторинга загрузки оборудования (счетчики «Performance monitors»).
На основании полученных замеров выявляется класс причины:
- Проблема в коде;
- И/или проблема в аппаратной части;
- Проблема в других ресурсоемких программах, используемых на рабочих серверах.
Нагрузочное тестирование 1С – методика оценки серверного оборудования
Как уже упоминалось, среди факторов, способных повлиять на быстродействие 1С, как в положительную, так и отрицательную сторонку, важное место занимает серверное оборудование и его настройка. Рассмотрим варианты замеров, оценки нагрузки и тестирования работоспособности системы в следующих условиях:
- Сервер 1С имеется в наличии и располагается:
- Совместно с СУБД;
- На отдельном сервере.
- Планируется приобретение сервера.
Для оценки соответствия параметров имеющегося серверного оборудования требованиям системы необходимо произвести сбор данных по нагрузке на аппаратную часть, в том числе и на процессор, т.е. нагрузочное тестирование 1С. Для этого применяется «Performance Monitor» – инструмент, позволяющий произвести замер оборудования на рабочем контуре и снять счетчики производительности.
Ниже приведен базовый набор счетчиков, которые необходимо настроить для мониторинга производительности оборудования в ОС Windows. Сбор производится со всех серверов, где установлены серверы 1С.
Виды | Счетчик | Описание |
---|---|---|
Физические диски | \PhysicalDisk(_Total)\Avg. Disk Queue Length | Очередь к дискам |
\PhysicalDisk(*)\Avg. Disk Bytes/Write | Среднее время записи на диск | |
\PhysicalDisk(*)\Avg. Disk Bytes/Read | Среднее время чтения с диска | |
Процессор | \Processor(_Total)\% Processor Time | % загруженности процессоров |
\System(_Total)\Processor Queue Length | Длина очереди к процессорам | |
Оперативная память | \Memory(_Total)\Available Mbytes | Доступная оперативная память |
Сеть | \Network Interface(*)\Bytes Total/sec | Скорость передачи данных по сети |
Если показатель счетчика процента загруженности процессора для вида «Processor» имеет высокое значение, следует выявить процессы, которые можно остановить без ущерба для работы сервера, а также перенести на другие сервера.
Вид «Process» позволит настроить мониторинг для каждого отдельного процесса, а также определить, какие из процессов занимают больше всего процессорного времени. Если на сервере установлен только сервер 1С, то чтобы понять, какую нагрузку он дает на железо, необходимо настроить сбор следующих счетчиков:
\Process("1Сv8*")\% Processor Time |
\Process("ragent*")\% Processor Time |
\Process("ragent*")\Private Bytes |
\Process("ragent*")\Virtual Bytes |
\Process("rmngr*")\% Processor Time |
\Process("rmngr*")\Private Bytes |
\Process("rmngr*")\Virtual Bytes |
\Process("rphost*")\% Processor Time |
\Process("rphost*")\Private Bytes |
\Process("rphost*")\Virtual Bytes |
\Process("1Сv8*")\Private Bytes |
\Process("1Сv8*")\Virtual Bytes |
Если текущая система находится в неудовлетворительном состоянии, то на основании собранных замеров, применяя линейную зависимость, следует провести расчет параметров оборудования для установки целевой системы.
Если приобретение серверного оборудования только планируется, рассчитать его параметры можно проэммулировав работу планируемой системы, но в меньшем масштабе, на имеющемся оборудовании. Для этого используется «1С:Тест-цент», который входит в Корпоративный инструментальный пакет 1С. На основании полученных замеров, с помощью методик расчета определяются параметры планируемой системы и, соответственно, требования к оборудованию. Данный тест можно использовать многократно под разные замеры, предварительно дополнив и расширив функционал. Эта методика имеет высокую точность и простоту расчета.
Перед запуском 1С:Документооборот для средних и крупных внедрений крайне желательно провести нагрузочное тестирование, чтобы проверить корректность и скорость работы системы электронного документооборота в условиях максимальной нагрузки.
В данной статье пойдет речь о том, как провести нагрузочное тестирование в 1С:Документооборот без использования 1С:КИП.
Рассмотрим упрощенное нагрузочное тестирование, которое встроено в типовую конфигурацию 1С:Документооборот КОРП или ДГУ. При этом можно не приобретать дополнительно 1С:КИП (корпоративный инструментальный пакет).
Подготовка эталонной базы СЭД для нагрузочного тестирования
Для проведения нагрузочного тестирования нужно создать эталонную базу СЭД 1С Документооборот. В качестве эталонной базы может выступать прототип или копия рабочей базы.
Необходимо установить следующие флажки в настройках программы под Администратором. В настройках по делопроизводству:
- Виды входящих документов,
- Виды исходящих документов,
- Виды внутренних документов,
- Учет по организациям,
- Вопросы деятельности,
- Управление мероприятиями,
- Грифы доступа,
- Категории для документов и файлов,
- настройку «Штрихкодирование документов» отключаем.
В настройках по процессам и задачам:
В настройках по правам доступа:
Также нужно включить настройку «Выполнять замеры производительности» в общих настройках программы.
И можно настроить автоматический экспорт замеров производительности.
Нужно обязательно заполнить следующие справочники:
- Виды внутренних документов – для каждого вида документа должны быть установлены настройки «Автоматически вести состав участников рабочей группы» и «Вести учет по корреспондентам» (довольно странное требование, так как в копии рабочей базы или прототипе далеко не всем видам документам нужны такие настройки).
- Виды входящих документов – для каждого вида документа должна быть установлена настройка «Автоматически вести состав участников рабочей группы».
- Виды исходящих документов – для каждого вида документа должна быть установлена настройка «Автоматически вести состав участников рабочей группы».
- Организации.
- Грифы доступа.
- Вопросы деятельности.
- Папки внутренних документов.
- Папки мероприятий.
- Корреспонденты.
Если видов документов много, то указанные настройки быстрее установить с помощью обработки «Групповое изменение реквизитов» в разделе «Настройка и администрирование».
Указываем справочник «Виды внутренних документов».
Выбираем реквизиты и значения, которые хотим изменить и нажимаем кнопку «Изменить реквизиты».
Аналогично поступаем со справочниками «Виды входящих документов» и «Виды исходящих документов».
Сценарии тестирования, входящие в типовую поставку 1С:Документооборот
Откроем конфигуратор 1С:Документооборот. И в конфигурации установим отбор по подсистеме НагрузочноеТестирование .
В общем модуле НагрузочноеТестированиеСценарииСтандартные указаны типовые сценарии.
В общем модуле НагрузочноеТестированиеСценарии содержится код пользовательских сценариев. В этом модуле основные сценарии вызывают стандартные сценарии из модуля НагрузочноеТестированиеСценарииСтандартные .
В комментариях перед каждой функцией можно посмотреть из каких шагов состоит каждый сценарий. Также полезным будет оценить среднее время на выполнение сценария.
Функция СозданиеВнутреннегоДокумента()
// Сценарий создания внутреннего документа.
// Шаги сценария:
// 1. Открытие списка внутренних документов, если он еще не открыт (пауза 5с).
// 2. Переключение режима просмотра на случайное (пауза 5с).
// 3. Если режим просмотра «По папкам», тогда переход к папке (пауза 5с).
// 4. Выполнение команды «Создать документ» в списке (пауза 5с).
// 5. Выбор шаблона создаваемого документа в форме выбора шаблона (пауза от 20с до 30с).
// 6. Выполнение команды «Создать по шаблону» в форме выбора шаблона (пауза 5с).
// 7. Заполнение реквизитов документа в форме документа (пауза от 60с до 180с).
// 8. Выполнение команды «Записать» в форме документа (пауза 5с).
// 9. Закрытие формы документа (пауза 5с).
Функция СозданиеИсходящегоДокумента()
// Сценарий создания исходящего документа.
// Шаги сценария:
// 1. Открытие списка исходящих документов, если он еще не открыт (пауза 5с).
// 2. Выполнение команды «Создать документ» в списке (пауза 5с).
// 3. Выбор шаблона создаваемого документа в форме выбора шаблона (пауза от 20с до 30с).
// 4. Выполнение команды «Создать по шаблону» в форме выбора шаблона (пауза 5с).
// 5. Заполнение реквизитов документа в форме документа (пауза от 60с до 180с).
// 6. Выполнение команды «Записать» в форме документа (пауза 5с).
// 7. Закрытие формы документа (пауза 5с).
Проведение нагрузочного тестирования WEB-сервисов, развернутых на платформе 1С. Целью тестирования является ознакомление с возможностями платформы 1С при работе с большим количеством запросов через опубликованные WEB сервисы на IIS 7.5
1. Аббревиатуры и сокращения
ПО – программное обеспечение;
Сервер – компьютер, на котором развернуто серверное ПО;
Клиент – компьютер или оборудование, на котором развернуто клиентское ПО для обращения к серверу за какой-либо информацией;
Запрос – клиентское обращение к серверу;
Соединение – канал передачи данных возникающий между клиентом и сервером в процессе передачи запроса от клиента к серверу;
Пакет – отправленный от клиента XML, несущий информацию о том, что необходимо клиенту или некие данные с сервера.
2. Постановка задачи
Произвести тестирование возможностей 1С платформы при обмене и обработке полученных данных от клиента серверу через WEB соединение. На сервере организовать WEB сервис приема пакетов/запросов от клиентов через объекты метаданных «Web-сервисы» с одним параметром типа строка. Все отправляемые пакеты на сервер имеют формат XML. Клиент должен получать вразумительный ответ от сервера в формате XML; например, статус и сумму по запрашиваемому документу. При проведении тестирования необходимо использовать продукты компании Microsoft: MS Windows, MS SQL Server, IIS.
Постоянные опросы готовности ответа является обязательным условием(бизнес-требованием) при разработке тестового стенда. При получении запроса идет частичный разбор полученного XML пакета. Необходимо что бы сервер понимал от кого и какой запрос был получен.
3. Схема проведения нагрузочного тестирования и задействованное оборудование
Серверное оборудование и ПО — процессор: Xeon X5560 2.8GHz — 2 шт., память: 76GB, жесткий: RAID 10 из 4х SAS дисков со скоростью 10К, сеть Интернет: до 100 Mbit/s, операционная система: Windows Server 2008R2 Enterprise SP1 64-х разрядный, СУБД: MS SQL Server 2008 R2 64-х разрядный, сервер приложений 1С: 1С:Предприятие 8.3 (8.3.8.1652) 32-х разрядный, Web Server: IIS вер. 7.5.
4. Ограничения, накладываемые на тестовую систему в целом
Канал передачи данных ограничен со стороны клиента. В моменты опроса сервера пики нагрузки на сетевые интерфейсы на клиентской части выходят за 10 Мбит/сек.
Компьютеры, на которых развернуты клиенты, не могут выдать полную мощность при 100% ожидании получения ответа. Это связано с механизмами/алгоритмами ожидания подготовки пакетов сервером. Поэтому на клиентах выставлена задержка времени запуска процедур. Также процедуры реализованы как массовая попытка получить данные от сервера, хоть и разыми пакетами и различными WS-соединениями с сервером.
На клиентских компьютерах возникает необходимость развертывать полноценные клиент-серверные приложения, т.к. 32-х битная версия 1С с файловым вариантом развертывания базы не может выдать достаточное количество одновременных WS-соединений с сервером.
Серверная часть развернута на 32-х битной версии сервера 1С. Что накладывает ограничения на использование ресурсов железа сервера.
5. План тестирования и ожидаемые результаты
На серверной стороне использую стандартные объекты запуска процедур по расписанию(Регламентные задания). Не стал дорабатывать процедуры для запуска отложенных процедур. Хотя это позволит усовершенствовать процесс обработки полученных пакетов. Запуск проводится каждые 10 секунд. В одном регламентном задании обрабатывается до 1000 поступивших пакетов.
В связи с ограничением количества клиентских точек разработал клиентскую конфигурацию способную обеспечить нагрузку на сервер при выполнении на малом количестве компьютеров. Тестирование проводится с 3-х клиентских компьютеров. С помощью этой конфигурации создаю нагрузку на сервер, тестирую производительность занятости ресурсов на сервере, отслеживаю полный цикл прохождения запросов, согласно схемы рис. 1. Также результаты тестирования покажут возможные потери при отправке пакетов/запросов.
Дополнительно разработал конфигурация, с помощью которой отправляю одиночные пакеты на сервер с обязательным ожиданием и 100% получением ответа от сервера. Это поможет отслеживать время подготовки и пересылки пакетов на клиента во время нагруженного тестирования и без него.
Пакеты, на клиенте генерирую в онлайн режиме, а не произвожу отправку одного и того же пакета. Это сделано для отслеживания полного цикла прохождения пакета от отправки до получения результата с сервера. Вес пакета составляет около 900 байт ± 50 байт.
На сервере также запускаю сборщик счетчиков производительности средствами Windows — perfmon, для дальнейшего анализа.
- Отправлю одиночный пакет – данный тест показывает время отклика системы при свободных ресурсах сервера;
- Отправлю 10 пакетов – данный тест показывает время отклика и возможные задержки при одновременных выполнениях сервером задач;
- Нагрузочное тестирование с контролем фоновых заданий на клиенте – создаю постоянную нагрузку на серверные мощности и получаю ответ от сервера, показывает время отклика при неполной нагрузке на сервер;
- Создаю нагрузку на сервер нагрузочной конфигурацией с 3-х клиентских точек – покажет узкие места сервера при 100% загруженности;
- Отправлю одиночный пакет с ожиданием ответа – покажет время отклика системы при 100% загруженности серверных ресурсов.
6. Отправка пакетов со 100% получением результата
При одиночном запросе клиент получил ответ от сервера через 10 секунд. При этом ответ был подготовлен и клиент об этом был уведомлен уже через 4 секунды.
При этом на серверной стороне временные показатели (время указано в миллисекундах):
Следующим шагом отправим 10 пакетов:
Замеры на клиенте показывают, что в среднем клиент был уведомлен о готовности ответа через 7.4 секунды и получен пакет ответа через 12 секунд.
На сервере пакеты обработались (время указано в миллисекундах)
7. Нагрузка сервера и получение ответа
Запуск точек произвожу с 3-х различных компьютеров. Нагрузочные конфигурации выполнены в среде разработки 1С версии 8.3.8.2197 развернуты по клиент-серверной технологии с использованием СУБД MS SQL Server 2008/2012. Сервер расположен в сети Интернет с максимальным каналом в 100 Мбит/сек.
1-й компьютер — процессор: i7-4790 3.6GHz, память: 16GB, жесткий: WDC WD 10EZEX, сеть: до 100MB/s, операционная система: Windows 8.1 Профессиональная 64бит
2-й компьютер — процессор: i5-4570 3.2GHz, память: 8GB, жесткий: Toshiba DT01ACA100, сеть: до 100MB/s, операционная система: Windows 10 Профессиональная 64бит
3-й компьютер — процессор: i5-4460 3.2GHz, память: 16GB, жесткий: WDC WD20EURS, сеть: до 20MB/s, операционная система: Windows 10 Профессиональная 64 бит
При создании 100% нагрузки на сервер выполнение произвожу без контроля одновременно работающих фоновых заданий на отправку пакетов. Также задаю максимальное количество отправляемых пакетов в количестве 5000 штук для каждой точки.
На сервере не провожу контроль фоновых заданий. Контроль фоновых заданий сильно затормаживает выполнение логики.
8. Результаты тестирования через WEB
Отправляю множество пакетов с контролем количества одновременно выполняющихся фоновых заданий на клиенте. Отправка пакетов идет одновременно с 3-х точек. В результате получаем нагрузку на сервере:
Клиент при этом получает пакеты в течение 26 секунд.
Нагрузочное тестирование при отмене контроля фоновых заданий на клиенте и выполнении нагрузки получаю, что серверные ресурсы загружены почти полностью:
При запросе одиночного пакета, когда очередь пакетов еще не набралась. Результаты показывают, что время ожидания пакета ответа составляет около 86 секунд.
При этом сервер получил 500 запросов и обработал 157 полученных пакетов (время указано в миллисекундах):
И при рассмотрении, когда сервер получил 1015 и обработал 438 пакетов (время указано в миллисекундах):
Далее происходит накопление количества пакетов и время обработки падает. Количество соединений от клиентских машин возрастает свыше 4000 тысяч в минуту, при этом сервер подготавливает данные и рассылает ответы на получаемые в реальном времени запросы (получено более 5000 пакетов и обработано 2400):
Нагрузка на аппаратные средства сервера:
Время получения ответа на одиночный запрос возрастает до 18 минут:
9. Выводы
При одиночных пакетах отклик системы составляет 10-12 секунд (рис.4, рис.7), но уведомление о готовности ответа клиентом получено уже спустя 4-7 секунд. При отправке пакета с клиента на сервер возникает соединение с сервером, которое длится примерно 0,036 секунды (рис.5, рис.8). На сервере выполнение подготовки самого пакета ответа происходит в фоновом задании, время выполнения которого составляет 0,031 секунды. Задержка ответа связана с тем, что на сервере реализация выполнена на регламентных заданиях, которые выполняются раз в 10 секунд. Что и вызывает задержку по времени получения ответа клиентом.
В результате, когда серверные мощности свободны он справляется с постоянным количеством поступающих запросов и выдает ответы на них (рис.12). Соединение при этом удерживается в течении 0,036 секунды, обработка пакета на сервере производится в течении 0,062 секунды. Клиент получает ответ о готовности через 15 секунд, а готовый ответ через 25,6 секунды (рис.13).
В моменты, когда аппаратные средства нагружены время удержания соединения с сервером возрастает до 0,07 секунды (рис.17). А время выполнения фонового задания на подготовку пакета ответа достигает 0,33 секунды. Но клиент получает уведомление о готовности через 78 секунд и готовый ответ уже через 86 секунд (рис.16). На рисунке рис.20 видно, что большую часть процессорного времени занимают обработки соединений с клиентом, число которых достигает пиков до 4690 в минуту (рис.20). Серверные графики в эти моменты показывают, что процессор занят обработкой задач на 100%, скорость в интернет достигает 70 Мбит/сек и обращение к дискам съедает до 5 Мбит/сек (рис.22).
В дополнение хочется упомянуть, что почти половину процессорных ресурсов забирает на себя программное обеспечение MS SQL Server, о чем свидетельствуют замеры производительности средством perfmon. Из 28 Гбайт занятой оперативной памяти 18 Гбайт отвелось SQL серверу, который также съедал 50% процессорного времени. При этом на 1С сервер приходилось около 8 Гбайт оперативной памяти.
Также нагрузочное тестирование показало: длина очереди дисков в пике упирается в значение 11, но при рассмотрении среднего показателя, за все врема тестирования, длина очереди равна 8. Среднее время обращения к дискам в макимальных значениях не превышает 0,18, а в середнем за все время тестирования составляет — 0,055. Для увеличения производительности подобной системы придется использовать более производительные дисковые подсистемы и рассмотреть варианты оптимизации кода и запросов к БД.
В результате тестирования получено, что тестируемое серверное оборудование и ПО способно выдержать нагрузку для более чем 1200 запросов в минуту продолжительное время и более 4000 запросов в минуту при критических нагрузках, т.е. непродолжительное время. Для сокращения времени получения результатов клиентом от сервера во время «жестких» нагрузок необходимо оптимизировать инфраструктуру серверного оборудования и работу установленного серверного ПО.
10. Методы оптимизации и повышения производительности
Для повышения устойчивости, масштабируемости и распределения нагрузки необходимо организовать кластер 1С с настройками требований назначения функциональности серверов. Обязательно отдельно выделить сервера, которые будут обрабатывать фоновые и регламентные задания. Это позволит распределить нагрузку по серверам и обрабатывать пакеты независимо от процессов, обрабатываемых соединения с клиентами.
Необходимо выделить SQL сервер на отдельные ресурсы с более высокопроизводительной дисковой подсистемой.
На серверах необходимо развертывать 64-х разрядную платформу 1С, что поможет ускорить производительность и устойчивость кластера 1С.
Оптимизация кода и запросов к SQL серверу в процессе внедрения и эксплуатации на конкретном оборудовании позволит ускорить обработку и формирование запрашиваемых данных и возможно снизит нагрузку на дисковую подсистему.
©Тестирование и разработка проводилась на ресурсах и при финансировании НПЦ «Прогтехника»
Читайте также: