Схема проведения нагрузочного тестирования и задействованное оборудование
Ограничения, накладываемые на тестовую систему в целом
План тестирования и ожидаемые результаты
Отправка пакетов со 100% получением результата
Нагрузка сервера и получение ответа
Результаты тестирования через WEB
Методы оптимизации и повышения производительности
1. Аббревиатуры и сокращения
ПО – программное обеспечение;
Сервер – компьютер, на котором развернуто серверное ПО;
Клиент – компьютер или оборудование, на котором развернуто клиентское ПО для обращения к серверу за какой-либо информацией;
Запрос – клиентское обращение к серверу;
Соединение – канал передачи данных возникающий между клиентом и сервером в процессе передачи запроса от клиента к серверу;
Пакет – отправленный от клиента XML, несущий информацию о том, что необходимо клиенту или некие данные с сервера.
2. Постановка задачи
Произвести тестирование возможностей 1С платформы при обмене и обработке полученных данных от клиента серверу через WEB соединение. На сервере организовать WEB сервис приема пакетов/запросов от клиентов через объекты метаданных "Web-сервисы" с одним параметром типа строка. Все отправляемые пакеты на сервер имеют формат XML. Клиент должен получать вразумительный ответ от сервера в формате XML; например, статус и сумму по запрашиваемому документу. При проведении тестирования необходимо использовать продукты компании Microsoft: MS Windows, MS SQL Server, IIS.
Постоянные опросы готовности ответа является обязательным условием(бизнес-требованием) при разработке тестового стенда. При получении запроса идет частичный разбор полученного XML пакета. Необходимо что бы сервер понимал от кого и какой запрос был получен.
3. Схема проведения нагрузочного тестирования и задействованное оборудование
рис. 1
Серверное оборудование и ПО - процессор: 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% загруженности серверных ресурсов.
рис.2
6. Отправка пакетов со 100% получением результата
При одиночном запросе клиент получил ответ от сервера через 10 секунд. При этом ответ был подготовлен и клиент об этом был уведомлен уже через 4 секунды.
рис. 3
рис. 4
При этом на серверной стороне временные показатели (время указано в миллисекундах):
рис. 5
Следующим шагом отправим 10 пакетов:
рис. 6
Замеры на клиенте показывают, что в среднем клиент был уведомлен о готовности ответа через 7.4 секунды и получен пакет ответа через 12 секунд.
рис. 7
На сервере пакеты обработались (время указано в миллисекундах)
рис. 8
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-х точек. В результате получаем нагрузку на сервере:
рис. 9
Обработчики на сервере показывают, что идет выполнение фоновых заданий для подготовки ответов на запросы от клиентов и рассылка этих ответов по запросу. В результате при получении 5408 пакетов было обработано и подготовлено ответов на 5368.
рис. 10
рис. 11
рис. 12
Клиент при этом получает пакеты в течение 26 секунд.
рис. 13
Нагрузочное тестирование при отмене контроля фоновых заданий на клиенте и выполнении нагрузки получаю, что серверные ресурсы загружены почти полностью:
рис. 14
При запросе одиночного пакета, когда очередь пакетов еще не набралась. Результаты показывают, что время ожидания пакета ответа составляет около 86 секунд.
рис. 15
рис. 16
При этом сервер получил 500 запросов и обработал 157 полученных пакетов (время указано в миллисекундах):
рис. 17
И при рассмотрении, когда сервер получил 1015 и обработал 438 пакетов (время указано в миллисекундах):
рис. 18
Далее происходит накопление количества пакетов и время обработки падает. Количество соединений от клиентских машин возрастает свыше 4000 тысяч в минуту, при этом сервер подготавливает данные и рассылает ответы на получаемые в реальном времени запросы (получено более 5000 пакетов и обработано 2400):
рис. 19
рис. 20
рис. 21
Нагрузка на аппаратные средства сервера:
рис. 22
рис. 23
Время получения ответа на одиночный запрос возрастает до 18 минут:
рис. 24
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).
При постоянной нагрузке на сервер в течении 7 минут и опросе сервера на готовность ответа клиентом скорость получения ответов клиентом сильно падает и достигает 18 минут (рис.24). Что напрямую связано с архитектурой построения сервиса, подготавливающего ответы, где все части инфраструктуры реализованы на одном компьютере без распределения нагрузки по различным узлам системы. При этом имеются провалы производительности сервера. В моменты падения производительности были пакеты не достигшие конечной точки, т.е. потерянные пакеты, в количестве 289 штук, которые составили около 1,9% от общего количества отправленных пакетов. Общее число сгенерированных пакетов 15000 штук. Это может говорить о падении служб 1С и перезапуске службы rphost. Но тем не менее, все полученные пакеты обрабатываются сервером и система продолжает подготовку ответов на них.
В дополнение хочется упомянуть, что почти половину процессорных ресурсов забирает на себя программное обеспечение 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 серверу в процессе внедрения и эксплуатации на конкретном оборудовании позволит ускорить обработку и формирование запрашиваемых данных и возможно снизит нагрузку на дисковую подсистему.
©Тестирование и разработка проводилась на ресурсах и при финансировании НПЦ "Прогтехника"
