Как это работает:
В процессе тестирования происходит подсчет рейтинга производительности. Промежуточные результаты можно наблюдать на графике. График вещь относительная и показывает величину прироста рейтинга за равные промежутки времени. Среднее значение — высчитывается из графика и тоже вещь чисто информативная. Реальный рейтинг считается по количеству операций в БД и может не совпасть с средним значением.
Как это запустить:
Короткий ответ — нажать Старт.
Длинный ответ — придумать задачу, определить исходные параметры, изменить настройки теста и нажать Старт.
При первом запуске произойдет заполнение БД необходимым количеством объектов исходя из заданного количества клиентов. Для 10 клиентов это занимаеет около 5 мин. Если выбрать «много» клиентов, то необходимо будет долго ждать заполнения.
Как это остановить:
Для остановки теста нужно еще раз нажать «Старт». Отключать отдельных клиентов можно в таблице. Выкладываю конфу и тестовую БД с уже заполненной базой на 10 клиентов(для тех кто не хочет ждать заполнения).
О методике тестирования(или для чего это нужно).
Задача была придумана такая — необходимо ли нам на текущем железе использовать 1 рабочий процесс или увеличить до 2-х. Думаю со стандартными рекомендациями знакомы все. «Но нам хотелось бы конкретики с привязкой к используемой конфигурации оборудования» — сказали админы. Ок, начинаем тестирование. Меняя количество клиентов с шагом 10 получили такой результат:
Синим — операций всего, красным — операций на 1 сеанс.
Что можно сказать по данному графику. Многопоточность работает! Если 1 клиент смог сделать 2500 операций, то 10 — уже около 16 000(за равный промежуток времени). «Насыщение» операциями происходит примерно при 20 подключенных клиентах. Далее мы не получаем заметного роста и в итоге совсем упираемся в планку 23к. операций. Видимо это предел данного сервера, точнее сказать данной конфигурации.
Добавляем еще 1 рабочий процесс. Тестируем, вот что получилось:
На данном сервере имеет смысл добавить еще 1 РП, если количество клиентов превышает 20. «Насыщение» наступит гораздо позже и общая производительность сервера заметно возрастет. Админы довольны, закупку нового сервера можно отложить.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Ничего не понятно и зачем?
А чуть подробнее о методике тестирования можно?
Из описания ничего непонятно.
Методика у каждого своя, все зависит от задачи. В настройках теста можно менять только число сеансов и нагрузку. Нагрузка — это какой процент данных будет изменен в процессе теста. Еще можно поиграть с настройками сервера приложений, количество рабочих процессов например.
Что мне поможет понять этот тест? Какие выводы можно сделать на основе его вычислений?
Судя по описанию, есть еще график. Почему не приложены дополнительные изображения?
(5) tolyan_ekb, Спасибо! видимо отвалились в процессе публикации. Сейчас прицеплю.
закрытый код тестировать отказываюсь))
досвидос короче))
(3) SodaWater, Вообще идея хорошая, получается этакий «Бесплатный СНТ», но в СНТ очень хорошая идея — там производительность измеряется в стандартных пользователях. Может тебе так же сделать? А то правда из результатов трудно какие-либо выводы сделать…
(0)
Подробно опишите методику и откройте код, тогда взлетит.
(4) Confucius, если просто запустить 1 раз, то ничем не поможет. Как минимум надо запускать 2 раза на разном железе или при разных настройках(железа, SQL, сервера 1С), не меняя при этом настройки теста. Можно запускать на 1 сервере несколько раз, меняя процент записи — мне это помогло понять, где уже SQL начинает притормаживать.
(8) Олег, в этом и есть отличие от СНТ. Если тот больше для оценки конкретного оборудования, то этот тест больше подходит для оценки разного железа(настроек). Задача СНТ — ответить сколько пользователей потянет ваше железо, а у меня была необходимость сравнить разные конфигурации оборудования. Виртуальные пользователи — это хорошо, но на практике все пользователи разные, кто-то весь день вбивает данные, а другие снимают отчеты. Для оценки реальной картины нужно писать сценарии и запускать в разных сеансах и т.д.
(9) KV1s, Методика проста — берем конкретный сервер1С и SQL и гоняем тест, получаем средний результат. Берем другой(ие) сервер1С и SQL и гоняем тест не меняя настроек. Сравниваем полученные результаты. Код простой до безумия — прербираем объекты БД(имитация чтения) и в части из них изменяем данные и записываем в БД. Открою код, когда будут аналоги таких тестов для 1С(СНТ не в счет там другие задачи). В идеале такой тест должен быть отдельной программой, но в связке с 1С этот вопрос труднореализуемый, потому и написано в рамках платформы.
(7) sanfoto, не, не так ) «давайдосвидания» )) Александр, видимо для тестирования дисков,памяти,процессоров, Вы используете только тесты с открытым кодом. В любом случае, спасибо за отклик.
а в чем соль?!
(13) SodaWater,
Просто не доверяю уж извините,
на инфостарте полно было обработок с закрытым кодом которые отправляют в инет различные данные — без позволения так сказать))
(15) sanfoto,
Возможно такие обработки(летящие в инет без предупреждения) тут есть. Эта точно не такая. Мне уже много лет, а с годами приходит не только маразм ), но и понимание того, что репутацию нельзя купить, а прос..ть можно за минуту. Всем понятно, что закрытый код это фикция, но в свою очередь готов предоставить исходники по запросу(контакты есть на форме обработки), если случится острая жизненная необходимость.
А размер Тестовой БД можно регулировать?
А получить Симбиоз Данной Конфы с Рабочей базой (тестирование на реальных Объектах БД)? В частности интересует показатель зависимости от Размера БД…
(17) V.Nikonov, размер пока фиксированный и зависит от выбранного кол-ва клиентов. Если размер БД необходимо менять, то можно сделать в след. версии. Хотя это имеет смысл только при проценте записи=0..3%, т.к. при проценте от 5 и выше SQLсерверу и так тяжко(даже если БД влезает в память).
Симбиоз не планировал. Причина в том, что тест задуман как замер производительности. Мне хотелось опуститься на уровень ниже и максимально абстрагироваться от конкретной конфигурации. Иначе это будет «тест кода» со всеми его плюшками в виде блокировок и т.д. В текущей версии каждый «клиент» изолирован и вероятность блокировок очень мала.
Однако, при недостаточном размере БД происходит недооценка Дисковой подсистемы SQL-Servr. Рабочие реальные базы почти никогда не умещаются в Памяти! При малых базах вообще можно не покупать Сервер 1С.
(19) V.Nikonov, Это не совсем так. Есть такие правила ACID , которые придуманы еще в 70-х, но уверен соблюдаются в SQL серверах по сей день. Например у нас есть 2 базы — одна в 10раз больше чем объем ОЗУ, а другая в 10раз меньше ОЗУ. Если мы сделаем UPDATE 10000 записей, то нагрузка на дисковую в обеих базах будет сравнима. SQL серверу надо сначала записать все эти изменения в LOG, а потом уже в базу(на диске) и в память. При запуске этого теста на наших серверах очень хорошо видно как SQL сервер начинает проседать под нагрузкой и от размера базы это не сильно зависит. Другое дело, если тестить только чтение(%записи=0). На базе, которая влезла в память будет более высокий результат.