Схема проведения нагрузочного тестирования и задействованное оборудование
Ограничения, накладываемые на тестовую систему в целом
План тестирования и ожидаемые результаты
Отправка пакетов со 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 серверу в процессе внедрения и эксплуатации на конкретном оборудовании позволит ускорить обработку и формирование запрашиваемых данных и возможно снизит нагрузку на дисковую подсистему.
©Тестирование и разработка проводилась на ресурсах и при финансировании НПЦ «Прогтехника»
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
отключите на сервере Hyper-Threading
(1) Михаил, можно уточнить, на что это повлияет?
(2) При включенном HT обработка двух параллельных процессов может попасть на одно ядро.
Соответственно, обрабатываться они будут примерно с половинной частотой процессора.
(3)А HT надо всегда вообще выключать на сервере 1С? У меня сервер на нём стоит SQL и 1С сервер. Запускаются различные фоновые задания.
Или это относится только к параллельным процессам? Когда одно регламентное порождает несколько фоновых обрабатывающих в несколько потоков что либо?
(4) Не знаю, как надо. Гилёв рекомендует отключать вообще со странной формулировкой.
А я не заморачиваюсь и отключаю всегда. Потому что у нас, в бизнесе вокруг 1С, потоков процессора и без HT хватает, как правило.
Он нужен людям, которые занимаются рендерингом, шифрованием или ещё чем-то, что распараллеливается хоть на 40 ядер. Там даже и выгода будет от Hyper Threading.
Саша, а опросы готовности пакета — это бизнес-требование? Просто этими запросами ты даешь дополнительную побочную нагрузку и на веб-сервер и на сервер 1С.
Ну и по замерам — если тестируются веб-сервисы имеет смысл дополнительно учитывать сколько времени тратится на веб-сервер, а также его потребление памяти и процессорного времени отдельно от процессов сервера 1С.
Если же ты тестируешь сколько пакетов может подготовить именно сервер приложений на этом оборудовании — то смысла делать это именно веб-сервисами особого нет.
Вот то что взялся за нагрузочное тестирование — однозначно плюс.
А за то что еще и поделился — отдельное спасибо
Можно подробнее про метод доступа (http или web сервисы, или вообще odata?)
И что конкретно делается на сервере кроме накладных расходов на сериализацию и передачу данных?
(6) Опрос — да, это бизнес требование.
Согласен, что надо и IIS контролировать, но пока только 1С сервер приложений затестил. В последующем можно предусмотреть и журналирование IIS, что бы увидеть что там происходит и сколько времени тратится на подьем самих WS-ок.
«Если же ты тестируешь сколько пакетов может подготовить именно сервер приложений на этом оборудовании — то смысла делать это именно веб-сервисами особого нет.» — Ну не скажи. У 1С часто падение/зависание самих фоновых заданий. Конечно тут и утечки памяти и дополнительные расходы, но тем не менее я узнал что на этом серверном оборудовании можно запускать смело 4000 фоновых заданий 🙂
Благодарю за коменты!
(7) Это WEB-сервисы, как объекты 1С конфигурации (SOAP)
В этой конфигурации более ничего, кроме самого хранения документов, которых очень большое множество, более 700 тысяч. Дополнительно на сервере конечно кое-что крутится, но там минимальные затраты. В пике, без нагрузки на тестируемую БД (конфигурацию), 5-7% от процессорного времени.
Рассматривали функционал SOAPUI? Там есть возможность проводить нагрузочное тестирование с разбором ответа сервера, определением response SLA и т.п. имхо, это очень удобно, особенно когда нужно тестировать не один вызов функции, а определенную последовательность (например, получение токена, создание какой-то сущности, изменение и удаление). Также там несколько стратегий тестирования с возможностью указания количества потоков (хотя у меня больше 200 вызовов в секунду запускать не удавалось в бесплатном варианте программы).
(0) А какова была цель тестирования?
(11) Написано в кратком описании статьи.
(10) Спасибо за рекомендацию. Гляну на этого зверя
Что это вообще за поток сознания?
(3) не может, прочитайте, что такое HT. Негативный эффект от него по большей части от уменьшения L2 и L3 кэша (при их наличии)
(14) Согласен во многом, но большая часть ответов на твои вопросы находится под собственностью компании для которой и по заказу которой проходило тестирование. Тут прошу меня извинить, но всех ньюансов открыть не могу.
Ожидал тестирования кэширования пула соединений к веб-сервису (которое появилось в 8.3.9).
Сам очень плотно занимался высоконагруженным обменом через веб-сервисы.
Я могу предположить, что такое пакет и зачем он нужен.
Остальное — поток цифр. Если бы я выкатил такое заказчику, неважно внутреннему или внешнему,
это было бы последнее мое исследование. Гендиру можно сразу сообщать 10 абзац (без анализа).
Если это реальный клиент — это антиреклама.
Если демонстрация «мускулов» — см (14).
(17) Заказчику эти результаты я бы постыдился отдавать. Методика тестирования не разъяснена и непонятно что и почему именно так тестируется. Выводы и предложения в лучшем случае не связаны с тестированием, в худшем — противоречат. На месте заказчика я бы поинтересовался, все ли работы подрядчик выполняет настолько неквалифицированно.
Даже маркетинговые статьи с тестированиями от или в сотню раз полезнее.
(18) Не вижу конкретики в этом комменте. Есть предложения, куда нужно глядеть — валяй. Остальное — вода.
В 14-м посте хоть немного конкретики было, хоть и сплошное смешивание с грязью.
(14)
Не первый раз это слышу, но … Через ВЕБ(без доступа к серверу по локалке) не выходят те самые многотысячные WS-ки в минуту. Обращение к SOAP с передачей одного параметра в котором XML строка длиной в 400-500 символов. Как я не старался. При получении идет частичный разбор XML, для того что бы понять какой это вид запроса и от кого. Может подскажешь, как сделать?
Только условие остается: сервак один и только тот, который приведен в статье. Разносить инфраструктуру нельзя. ПО используем — то что есть и перечислено в статье. И попрошу без рекомендаций уйти на современные средства.
Чушь, нагрузка сбалансирована для этого оборудования. Длина очереди диска только в пике стукается о значение 11. Среднее за все время составило — 8. Среднее время обращения к дискам не превышает 0,18, а в середнем составляет — 0,055. В купе с занятостью проца получается, что и дисковая подсистема и проц будут узким местом. В выводах конечно нужно указать, что SQL сервак надо отдельно выносить. Но именно для этих работ было нормуль.
Нет. Но и не туннель. Сервер в дата центре. Скорее всего у них маршрутизация настроена по своему. Но меня, в данном контексте, это не интересует.
HTTP. IIS настроен на сжатие динамических и статических данных.
(19) Что заказчик просил — то и получил. В данном случае именно время отклика подобной системы и количество запросов в минуту. Не более того.
(21)
Какая такая сбалансированность? Это же самое прямое указание, что диски захлебнулись.
Еще. Вдруг внезапно понял, что не могу придумать, как на этом сервере может быть 76 ГБ памяти. Это ошибка или виртуализация?
(23)
Это же Винды Enterprise и сервак HP Dl380 (вроде как). Он около 170 держит по тех. характеристикам. А планки там разношерстные, естественно по парам.
(24) X5560 держит 144ГБ и она там трёхканальная, а не парами (у меня дома десктоп на близком к ним по архитектуре W3690), но это не важно. Я не могу придумать какими планками набрать 76 ГБ. Даже по парам.
(23)
Поясни. Потому как везде сказано, что:
1. Длина очереди диска должна быть не более 2*на кол-во шпинделей. Шпинделей в сервере 4. Среднее значение показателя по тестированию — 8.
2. Среднее время обращения к дискам не должна превышать 0.25. В тестировании менее этой величины.
Где захлебнулись?
(25) Когда будет сервер на руках — сфотаю и отпишусь
(26) Это рекомендации 10-15-летней давности. Они сейчас устарели. Если кратко, то нужно
1. Нужно как-то разделить (или научиться считать отдельно) все виды дисковой загрузки сервера. В данном случае это примерно 6-10 видов.
2. Посмотреть параметр «% загруженности». Вместе с динамикой текущей очереди (отдельно на запись и чтение и вместе) и временем отклика (R/W и общее)
3. Посмотреть sys.dm_os_waitstats — я думаю, что там будет просто всё забито writelog и pageiolatch_*.
Спасибо за статью, а еще большее спасибо за комменты.
(18)
Если интересно, то по моим результатам, минимум 4х кратный рост производительности, при том, что соединения и так были оптимизированы до этого (это у 1С на стандартной бухгалтерии 10 раз).
я гонял у себя обращение к http-сервисам, на виртуалке в Azure
(30)
Мне Азур что то совсем не нравится. 1С на нем ужасно тормозит(временами). Похоже из-за регламентных процедур обслуживания серверов.
У Вас развернута клиент-серверная версия?
(31) Да, клиент-серверная. Но у нас машины с 10 тысяч IOPS, а не дефолтные, плюс отдельно оптимизированные временные файлы, поэтому никаких тормозов нет. Плюс, у нас ультраспецифическая нагрузка 🙂
Спасибо за статью. При нормальной работе ждать получения результата 25 секунд не просто роскошь, но и реальная пытка. Вероятно причина в том, что 1С может работать одновременно только с одним ядром, которое грузит по максимуму и эту беду не исправляет ни дисковая система, ни объемы памяти.
(33)
Это не так.