Нагрузочное тестирование сервера 1С при использовании WEB сервисов

01.02.17

База данных - HighLoad оптимизация

Проведение нагрузочного тестирования WEB-сервисов, развернутых на платформе 1С. Целью тестирования является ознакомление с возможностями платформы 1С при работе с большим количеством запросов через опубликованные WEB сервисы на IIS 7.5

Аббревиатуры и сокращения

Постановка задачи

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

Ограничения, накладываемые на тестовую систему в целом

План тестирования и ожидаемые результаты

Отправка пакетов со 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, для дальнейшего анализа.

  1. Отправлю одиночный пакет – данный тест показывает время отклика системы при свободных ресурсах сервера;
  2. Отправлю 10 пакетов – данный тест показывает время отклика и возможные задержки при одновременных выполнениях сервером задач;
  3. Нагрузочное тестирование с контролем фоновых заданий на клиенте – создаю постоянную нагрузку на серверные мощности и получаю ответ от сервера, показывает время отклика при неполной нагрузке на сервер;
  4. Создаю нагрузку на сервер нагрузочной конфигурацией с 3-х клиентских точек – покажет узкие места сервера при 100% загруженности;
  5. Отправлю одиночный пакет с ожиданием ответа – покажет время отклика системы при 100% загруженности серверных ресурсов.

Нагрузка на сервер

рис.2


6. Отправка пакетов со 100% получением результата

При одиночном запросе клиент получил ответ от сервера через 10 секунд. При этом ответ был подготовлен и клиент об этом был уведомлен уже через 4 секунды.

Одиночный пакет отправка

рис. 3

Одиночный пакет ответ сервера

рис. 4

При этом на серверной стороне временные показатели (время указано в миллисекундах):

Одиночный пакет - замер

рис. 5

Следующим шагом отправим 10 пакетов:

10 пакетов

рис. 6

Замеры на клиенте показывают, что в среднем клиент был уведомлен о готовности ответа через 7.4 секунды и получен пакет ответа через 12 секунд.

10 пакетов - ответ сервера

рис. 7

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

10 пакетов - замер

рис. 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 серверу в процессе внедрения и эксплуатации на конкретном оборудовании позволит ускорить обработку и формирование запрашиваемых данных и возможно снизит нагрузку на дисковую подсистему.


©Тестирование и разработка проводилась на ресурсах и при финансировании  НПЦ "Прогтехника"

Обмен WEB сервис тестирование нагрузка

См. также

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    5484    ivanov660    12    

56

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    9667    Evg-Lylyk    61    

44

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    5274    spyke    28    

49

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    7822    vasilev2015    20    

42

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    12759    257    ZAOSTG    84    

115

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    5911    glassman    19    

42

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    15170    doom2good    49    

71
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. МихаилМ 01.02.17 18:25 Сейчас в теме
отключите на сервере Hyper-Threading
2. BraunAlex 136 01.02.17 22:46 Сейчас в теме
(1) Михаил, можно уточнить, на что это повлияет?
3. collider 02.02.17 08:11 Сейчас в теме
(2) При включенном HT обработка двух параллельных процессов может попасть на одно ядро.
Соответственно, обрабатываться они будут примерно с половинной частотой процессора.
4. TODD22 19 02.02.17 09:05 Сейчас в теме
(3)А HT надо всегда вообще выключать на сервере 1С? У меня сервер на нём стоит SQL и 1С сервер. Запускаются различные фоновые задания.
Или это относится только к параллельным процессам? Когда одно регламентное порождает несколько фоновых обрабатывающих в несколько потоков что либо?
5. collider 02.02.17 09:14 Сейчас в теме
(4) Не знаю, как надо. Гилёв рекомендует отключать вообще со странной формулировкой.
http://www.gilev.ru/systemperfomance/
Для некоторых не очень параллельных задач также рекомендуется выключить гипертрейдинг в биосе.

А я не заморачиваюсь и отключаю всегда. Потому что у нас, в бизнесе вокруг 1С, потоков процессора и без HT хватает, как правило.
Он нужен людям, которые занимаются рендерингом, шифрованием или ещё чем-то, что распараллеливается хоть на 40 ядер. Там даже и выгода будет от Hyper Threading.
16. Fragster 1151 04.02.17 12:25 Сейчас в теме
(3) не может, прочитайте, что такое HT. Негативный эффект от него по большей части от уменьшения L2 и L3 кэша (при их наличии)
6. nickpugachev 02.02.17 15:34 Сейчас в теме
Саша, а опросы готовности пакета - это бизнес-требование? Просто этими запросами ты даешь дополнительную побочную нагрузку и на веб-сервер и на сервер 1С.

Ну и по замерам - если тестируются веб-сервисы имеет смысл дополнительно учитывать сколько времени тратится на веб-сервер, а также его потребление памяти и процессорного времени отдельно от процессов сервера 1С.

Если же ты тестируешь сколько пакетов может подготовить именно сервер приложений на этом оборудовании - то смысла делать это именно веб-сервисами особого нет.

Вот то что взялся за нагрузочное тестирование - однозначно плюс.
А за то что еще и поделился - отдельное спасибо
8. BraunAlex 136 02.02.17 17:58 Сейчас в теме
(6) Опрос - да, это бизнес требование.

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

"Если же ты тестируешь сколько пакетов может подготовить именно сервер приложений на этом оборудовании - то смысла делать это именно веб-сервисами особого нет." - Ну не скажи. У 1С часто падение/зависание самих фоновых заданий. Конечно тут и утечки памяти и дополнительные расходы, но тем не менее я узнал что на этом серверном оборудовании можно запускать смело 4000 фоновых заданий :)

Благодарю за коменты!
7. Fragster 1151 02.02.17 15:38 Сейчас в теме
Можно подробнее про метод доступа (http или web сервисы, или вообще odata?)
И что конкретно делается на сервере кроме накладных расходов на сериализацию и передачу данных?
9. BraunAlex 136 02.02.17 18:03 Сейчас в теме
(7) Это WEB-сервисы, как объекты 1С конфигурации (SOAP)

В этой конфигурации более ничего, кроме самого хранения документов, которых очень большое множество, более 700 тысяч. Дополнительно на сервере конечно кое-что крутится, но там минимальные затраты. В пике, без нагрузки на тестируемую БД (конфигурацию), 5-7% от процессорного времени.
10. CSiER 36 03.02.17 03:32 Сейчас в теме
Рассматривали функционал SOAPUI? Там есть возможность проводить нагрузочное тестирование с разбором ответа сервера, определением response SLA и т.п. имхо, это очень удобно, особенно когда нужно тестировать не один вызов функции, а определенную последовательность (например, получение токена, создание какой-то сущности, изменение и удаление). Также там несколько стратегий тестирования с возможностью указания количества потоков (хотя у меня больше 200 вызовов в секунду запускать не удавалось в бесплатном варианте программы).
13. BraunAlex 136 03.02.17 13:46 Сейчас в теме
(10) Спасибо за рекомендацию. Гляну на этого зверя
11. speshuric 1338 03.02.17 09:35 Сейчас в теме
(0) А какова была цель тестирования?
12. BraunAlex 136 03.02.17 13:44 Сейчас в теме
(11) Написано в кратком описании статьи.
14. speshuric 1338 03.02.17 19:43 Сейчас в теме
(12) Так вот в том-то и дело, что не совсем понятно. Попробую пояснить, что мне непонятно.

Вызывает много вопросов тестируемое решение и его структура.

Окружение:
1. Аппаратное обеспечение. Процессоры 5-7-летней давности и скромный объём памяти еще объяснимы, но удивляет совсем никакая дисковая подсистема, которая при минимальной нагрузке должна стать очевидным ограничением. Собственно, как ниже видно - она и становится.
2. 32-битный сервер 1С. Особенно с учетом того, что ниже фраза "При этом на 1С сервер приходилось около 8 Гбайт оперативной памяти"
3. Свалены на слабый сервер все роли. Это на самом деле не самая большая проблема, проблема в том, что вы не оказываете из-за какой из этих ролей будет ограничена производительность.
4. Были ли какие-то межсетевые экраны/прокси, другие задержки между клиентом и сервером?
5. Что использовалось - http или https и в каком режиме?

Решение:
1. Мне непонятно какой API тестировался, т.е. конкретно, какие методы у сервисов, с какой сигнатурой, как дёргаются. Без этого читать что-то про тестирование можно было бы только для какого-то стандартного решения.
2. Картинка "Схема нагрузочного тестирования" сразу вызывает вопросы: а) Не пришибут ли сервер "пинги" от "Запрос готовности ответа" и б) где и как хранится готовящийся ответ (если в СУБД, то мы точно не тестируем веб-сервисы), в) Что там за "распаковка ответов"?
3. Что такое "прием пакетов от клиентов"?
4. Почему задача "Клиент должен получать вразумительный ответ от сервера в формате XML; например, статус и сумму по запрашиваемому документу" не решена банальным веб-сервисом, который тупо делает запрос и возвращает эти данные?
5. Что там за промежуточная долгая подготовка данных?
6. Я не знаю вашего решения, поэтому вся фраза "На серверной стороне использую стандартные объекты запуска процедур по расписанию. Не стал дорабатывать процедуры для запуска отложенных процедур. Хотя это позволит усовершенствовать процесс обработки полученных пакетов." для меня ничего не значит. Как, впрочем и следующие 2-3 абзаца.
7. Настораживает фраза "Вес пакета составляет около 900 байт ± 50 байт." Я не знаю термина "пакет" в веб-сервисах. Это размер http-запроса? Что там содержится в 900 байтах? Или это размер какого-то XML? Как вы в 1С контролируете размер в байтах (а не в символах)?

По целям тестирования. Обычно тестируется задержка, общая пропускная способность, максимальное количество клиентов (до деградации) или какая-то другая метрика. При этом обычно у нагрузочного тестирования цель - выяснить как эти метрики меняются при изменении параметров нагрузки и что является основным узким местом.
Смотрю на ваши 5 тестов: пункт 1 понятен, пункт 2 примерно понятен, пункты 3, 4 и 5 вызывают вопросы (что такое 100% нагрузка, зачем при ней измерять время отклика, где ниже "узкие места сервера" и т.д.)
В этом тестировании я так и не суть выбранных метрик и не понял, что является ограничением, какое их практическое значение. Точнее, мне кажется, что понял, но не понял, причем тут веб-сервисы.

То есть я вижу, что из описания я просто не понимаю, что и зачем тестировалось, не понимаю результатов.

Из глав "Результаты" и "выводы" я вижу:
1. Нагрузка на сервер в части именно веб-сервисов - никакая. Даже мой десктоп, если мне память не изменяет (извините, это было лет 5 назад), под 1С без оптимизаций оперировал то ли сотнями, то ли тысячами запросов к веб-сервису в секунду.
2. Даже из скриншотов понятно, что при тестировании всё уткнулось в SQL и диск.
3. В скриншотах монитора ресурсов фигурирует какая-то 1cv8.exe
4. Используются какие-то неопределённые термины типа "Количество соединений от клиентских машин возрастает свыше 4000 тысяч в минуту" - что это? С количеством наверное опечатка, но что за "соединения от клиентских машин в минуту"? Что такое "рассылает ответы на получаемые в реальном времени запросы"?
5. В выводах почти к каждому предложению у меня вопрос "почему?", "из чего это следует?" или "что автор хотел сказать этой информацией?".

Как следствие, читая последнюю часть "Методы..." я просто удивлён:
1. Советуешь "необходимо организовать кластер 1С"? Чувааак! У тебя 1С и SQL толкаются по процу, SQL (скорее всего) упёрся в недодисковую недосистему и вообще сервер "в годах". Лимит по дисковой подсистеме настолько очевидный, что дальше и тестировать-то смысла нет.
2. Говоришь "необходимо развертывать 64-х разрядную платформу 1С"? Твоё тестирование скорее всего стоило ДОРОЖЕ, чем этот апгрейд.
3. "Оптимизация кода и запросов к SQL серверу в процессе внедрения и эксплуатации на конкретном оборудовании"??? Оборудование типичнейшее, чего там на нём "конкретном" оптимизировать? Индексы нужны? Напиши какие и как это выяснено. Запросы кривые? Покажи их текст, план выполнения и рекомендации по изменению. Код кривой? Ну так напиши, что именно исправить.
rosinfo1; Yakud3a; hlopik; mr_best_23rus; kiruha; apatyukov; ig1082; Liris; JohnyDeath; baracuda; asved.ru; +11 Ответить
17. BraunAlex 136 05.02.17 08:58 Сейчас в теме
(14) Согласен во многом, но большая часть ответов на твои вопросы находится под собственностью компании для которой и по заказу которой проходило тестирование. Тут прошу меня извинить, но всех ньюансов открыть не могу.
19. speshuric 1338 06.02.17 09:45 Сейчас в теме
(17) Заказчику эти результаты я бы постыдился отдавать. Методика тестирования не разъяснена и непонятно что и почему именно так тестируется. Выводы и предложения в лучшем случае не связаны с тестированием, в худшем - противоречат. На месте заказчика я бы поинтересовался, все ли работы подрядчик выполняет настолько неквалифицированно.
Даже маркетинговые статьи с тестированиями от EMC или MS в сотню раз полезнее.
22. BraunAlex 136 06.02.17 10:27 Сейчас в теме
(19) Что заказчик просил - то и получил. В данном случае именно время отклика подобной системы и количество запросов в минуту. Не более того.
18. ig1082 281 06.02.17 09:29 Сейчас в теме
Ожидал тестирования кэширования пула соединений к веб-сервису (которое появилось в 8.3.9).
Сам очень плотно занимался высоконагруженным обменом через веб-сервисы.
Я могу предположить, что такое пакет и зачем он нужен.
Остальное - поток цифр. Если бы я выкатил такое заказчику, неважно внутреннему или внешнему,
это было бы последнее мое исследование. Гендиру можно сразу сообщать 10 абзац (без анализа).

Если это реальный клиент - это антиреклама.
Если демонстрация "мускулов" - см (14).

20. BraunAlex 136 06.02.17 09:53 Сейчас в теме
(18) Не вижу конкретики в этом комменте. Есть предложения, куда нужно глядеть - валяй. Остальное - вода.

В 14-м посте хоть немного конкретики было, хоть и сплошное смешивание с грязью.
30. Inkasor 28 07.02.17 15:08 Сейчас в теме
(18)
Ожидал тестирования кэширования пула соединений к веб-сервису (которое появилось в 8.3.9).


Если интересно, то по моим результатам, минимум 4х кратный рост производительности, при том, что соединения и так были оптимизированы до этого (это у 1С на стандартной бухгалтерии 10 раз).
я гонял у себя обращение к http-сервисам, на виртуалке в Azure
31. BraunAlex 136 08.02.17 10:42 Сейчас в теме
(30)
я гонял у себя обращение к http-сервисам, на виртуалке в Azure

Мне Азур что то совсем не нравится. 1С на нем ужасно тормозит(временами). Похоже из-за регламентных процедур обслуживания серверов.
У Вас развернута клиент-серверная версия?
32. Inkasor 28 08.02.17 13:15 Сейчас в теме
(31) Да, клиент-серверная. Но у нас машины с 10 тысяч IOPS, а не дефолтные, плюс отдельно оптимизированные временные файлы, поэтому никаких тормозов нет. Плюс, у нас ультраспецифическая нагрузка :)
21. BraunAlex 136 06.02.17 10:22 Сейчас в теме
(14)
Нагрузка на сервер в части именно веб-сервисов - никакая. Даже мой десктоп, если мне память не изменяет (извините, это было лет 5 назад), под 1С без оптимизаций оперировал то ли сотнями, то ли тысячами запросов к веб-сервису в секунду.

Не первый раз это слышу, но ... Через ВЕБ(без доступа к серверу по локалке) не выходят те самые многотысячные WS-ки в минуту. Обращение к SOAP с передачей одного параметра в котором XML строка длиной в 400-500 символов. Как я не старался. При получении идет частичный разбор XML, для того что бы понять какой это вид запроса и от кого. Может подскажешь, как сделать?
Только условие остается: сервак один и только тот, который приведен в статье. Разносить инфраструктуру нельзя. ПО используем - то что есть и перечислено в статье. И попрошу без рекомендаций уйти на современные средства.

Даже из скриншотов понятно, что при тестировании всё уткнулось в SQL и диск.

Чушь, нагрузка сбалансирована для этого оборудования. Длина очереди диска только в пике стукается о значение 11. Среднее за все время составило - 8. Среднее время обращения к дискам не превышает 0,18, а в середнем составляет - 0,055. В купе с занятостью проца получается, что и дисковая подсистема и проц будут узким местом. В выводах конечно нужно указать, что SQL сервак надо отдельно выносить. Но именно для этих работ было нормуль.

Были ли какие-то межсетевые экраны/прокси, другие задержки между клиентом и сервером?

Нет. Но и не туннель. Сервер в дата центре. Скорее всего у них маршрутизация настроена по своему. Но меня, в данном контексте, это не интересует.

Что использовалось - http или https и в каком режиме?

HTTP. IIS настроен на сжатие динамических и статических данных.
23. speshuric 1338 06.02.17 10:34 Сейчас в теме
(21)
Длина очереди диска только в пике стукается о значение 11. Среднее за все время составило - 8. Среднее время обращения к дискам не превышает 0,18, а в середнем составляет - 0,055.
Какая такая сбалансированность? Это же самое прямое указание, что диски захлебнулись.

Еще. Вдруг внезапно понял, что не могу придумать, как на этом сервере может быть 76 ГБ памяти. Это ошибка или виртуализация?
24. BraunAlex 136 06.02.17 10:43 Сейчас в теме
(23)
Еще. Вдруг внезапно понял, что не могу придумать, как на этом сервере может быть 76 ГБ памяти. Это ошибка или виртуализация?


Это же Винды Enterprise и сервак HP Dl380 (вроде как). Он около 170 держит по тех. характеристикам. А планки там разношерстные, естественно по парам.
25. speshuric 1338 06.02.17 10:47 Сейчас в теме
(24) X5560 держит 144ГБ и она там трёхканальная, а не парами (у меня дома десктоп на близком к ним по архитектуре W3690), но это не важно. Я не могу придумать какими планками набрать 76 ГБ. Даже по парам.
27. BraunAlex 136 06.02.17 10:51 Сейчас в теме
(25) Когда будет сервер на руках - сфотаю и отпишусь
26. BraunAlex 136 06.02.17 10:50 Сейчас в теме
(23)
Какая такая сбалансированность? Это же самое прямое указание, что диски захлебнулись.


Поясни. Потому как везде сказано, что:
1. Длина очереди диска должна быть не более 2*на кол-во шпинделей. Шпинделей в сервере 4. Среднее значение показателя по тестированию - 8.

2. Среднее время обращения к дискам не должна превышать 0.25. В тестировании менее этой величины.

Где захлебнулись?
28. speshuric 1338 06.02.17 11:05 Сейчас в теме
(26) Это рекомендации 10-15-летней давности. Они сейчас устарели. Если кратко, то нужно
1. Нужно как-то разделить (или научиться считать отдельно) все виды дисковой загрузки сервера. В данном случае это примерно 6-10 видов.
2. Посмотреть параметр "% загруженности". Вместе с динамикой текущей очереди (отдельно на запись и чтение и вместе) и временем отклика (R/W и общее)
3. Посмотреть sys.dm_os_waitstats - я думаю, что там будет просто всё забито writelog и pageiolatch_*.
15. asved.ru 37 03.02.17 20:47 Сейчас в теме
Что это вообще за поток сознания?
29. Жолтокнижниг 259 07.02.17 10:13 Сейчас в теме
Спасибо за статью, а еще большее спасибо за комменты.
33. boevrd 14.02.17 03:24 Сейчас в теме
Спасибо за статью. При нормальной работе ждать получения результата 25 секунд не просто роскошь, но и реальная пытка. Вероятно причина в том, что 1С может работать одновременно только с одним ядром, которое грузит по максимуму и эту беду не исправляет ни дисковая система, ни объемы памяти.
34. Fragster 1151 14.02.17 10:46 Сейчас в теме
(33)
Вероятно причина в том, что 1С может работать одновременно только с одним ядром, которое грузит по максимуму и эту беду не исправляет ни дисковая система, ни объемы памяти.

Это не так.
Оставьте свое сообщение