ну вообщем итог экспериментов
тестировалась связка
разработческий компьютер (HP Pavilion Elite HPE-400 Core i7 2.93 RAM 8Gb)
0. soapUI - проверка нагрузки Web службы
1. IIS (ASP.Net Web Service) - SOAP
2. COM+ Component v8Server - размер пула от 10 до 100 объектов
тестовый сервер 1С 8.2.13.219
чего то там внутри "блэйда" - на нем обычно тестируются базы от 100 GB, так что что-то производительное
тестовый сервер MSSQL 2008R2
чего-то тоже внутри блэйда но с довольно вменяемой дисковой - тестируются обычно время выполнения реструктуризации и вообще регламентных работ
---
тестировались два метода тестовой Web службы
1. string HelloWorld - вызывались два метода 1С ИмяПользователя() и СтрокаСоединенияИнформационнойБазы()
2. int RemainGood(int code) - вызов метода общего модуля 1С (найти номенклатуру по коду, получить количество Не нулевых остатков серийных номеров) - количество движений в регистре 333000000 записей, количество итогов 7000000 записей в таблицах SQL.
замеры производились по сценариям. перед выполнение каждого сценария машина перезагружалась и службы IIS, COM+ и 1С перезапускались - temp файлы очищались
simple (простой режим)время выполнения сценария 600 секунд
количество одновременных потоков 120
задержка работы потока - <случайное число от 1 до 100 миллисекунд>
thread (потоковый режим)время выполнения сценария 600 секунд
количество одновременных потоков от 10 до 120 с пропорциональным шагом
задержка при вызове не происходит - все потоки выполняются одновременно
burst (тестирование взрывом)время выполнения сценария 600 секунд
количество одновременных потоков 120
задержка при вызове не происходит - все потоки выполняются одновременно
длина шага запуска всех 120 потоков - 60 секунд (старт работы всех потоков)
длина шага задержки - 30 секунд (стоп работе всех потоков)
результаты:
имя сценария | helloWorld | RemainGood |
simple | max 1400ms, avg 19ms, min 3ms, err 0, count 1079000 | max 4409ms, avg 223ms, min 123ms, err 0, count 89078 |
thread | max 1540ms, avg 34ms, min 12ms, err 0, count 1241798 | max 3400ms, avg 256ms, min 146ms, err 0, count 234987 |
burst | max 1745ms, avg 43ms, min 14ms, err 0, count 946336 | max 4907ms, avg 381ms, min 201ms, err 0, count 102569 |
разъяснение:
max - максимальное время вызова
avg - среднее время вызова
min - минимальное время вызова
err - количество ошибок
count - общее количество вызовов за время сценария
до сих пор не понимаю как система понимает что один из объектов пула освободился для выполнения другим клиентским вызовом
во всех тестовых сценариях COM+ приложение создавало от 83 до 92 COM соединений к 1С - до предела в 100 так и не добрался (на досуге попытаюсь выбраться к пределу и посмотреть кто упадет в таком случае)
P.S. в коде выше чтобы не было зависших объектов приходится принудительно делать
connector =nullP.S.S. А ниче так жизнеспособная схемка получилась
- 1C-ный то Web сервис при 50 потоках ниже секунды не показывал
P.S.S.S. И еще - никакого тонкого тюнинга на стороне IIS и COM+ пока не производилось, данный результаты получены в рамках штатных установок
в эти выходные буду в Липецке - покажу данные своему коллеге - вместе с которым пытались построить почти тоже самое, но собственными силами (проект OneCService назывался
)