Отчет позволяет замерять на актуальных базах КА2 и УТ11 (в том числе на демо-базах) три параметра: время выборки данных, время передачи с клиента на сервер, время вывода данных. Тестировал на релизах КА 2.4.1.240 и УТ 11.4.5.32.
Отчет позволяет замерять на актуальных базах КА2 и УТ11 (в том числе на демо-базах) три параметра: время выборки данных, время передачи с сервера на клиент, время вывода данных.
С помощью его можно быстро понимать: стало лучше/стало хуже после изменения каких-либо настроек сервера. На живом проекте обнаружили "узкое" место — именно передачу с сервера на клиент — шла несообразно много времени.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Вообще не понятно как пользоваться. По кнопке «запустить замеры» КА просто виснет.
Буду использовать как дополнение к нагрузочному тесту gilev.ru/tpc1cgilv/.
Спасибо.
(1) Да, кнопкой «Запустить замеры». У вас база не демо, а с данными? Если да, тогда поставьте период поменьше.
Как вы это поняли, что это «узкое место» и как решили проблему?
(4) Подумали, замерили этой обработкой, увидели время выполнения этой части на порядок превышающее, например, время выборки — сообщили об этом службе поддержки интегратора, где у нас расположены сервера. Они нашли узкое место в настройках сервера (что там конкретно было, надо в истории переписки копаться, так как это было года 3 назад)
(4) порылся, прикрепляю скриншот с цифрами замера, который мы имели во время «тормозной» работы системы. И резюме службы техн.поддержки облака «где собака была зарыта и как ее нашли». Главное для нас было, что на «той» стороне починили, и 1С начала «летать»
Короткий отчет о том, как удалось найти «загвоздку»…
Как я писал ранее в письме от 09 октября:
В итоге проблема в терминальном сервере на системно-прикладном уровне или на уровне виртуализации: в нём самом или в том, как согласовывается сетевой обмен между конкретно ним и сервером 1С.
После этого этапа локализации сразу было предположение, что а) собрали неверно терминальный сервер; б) какие-то новые фишки WinServer 2012 — но находить «узкое место» не удавалось.
Также было понимание, что есть зависимость от нагрузки — в 7 утра Ваш отчет выполнялся за 10 сек, а около 9 часов уже за 60 сек, причем зависимость от числа активных сеансов была прямая.
Потом Вы начали стресс-тест, который утыкался по нашим данным в vCPU на терминальном сервере, и вот тогда было замечено, что большую часть процессорного времени отъедает TSFairShare.sys.
Тогда и решили обратить внимание на функцию Dynamic Fair Share Sheduling, которая в 2012 WinServer получила поддержку управления дисковой и сетевой активностью.
Опытным путем было выявлено, что большее влияние на производительность оказывает активная Disk Fair Sharing, а ее отключение полностью решало проблемы с передачей данных с сервера на клиент и «выпрямляло» производительность терминального сервера.
Таким образом подтвердились предположения, что проблема а) в конкретном терминальном сервере б) на системно-прикладном уровне в) в новшествах WinServer 2012 г) зависит от числа активных пользователей — так устроена эта функция DFSS.
Несмотря на то, что случай для нас новый, мы сможем использовать полученные опытные данные в своей дальнейшей работе, и потому готовы отблагодарить Вас за активное содействие предоставлением 10%-ной скидки на наши услуги за ноябрь месяц.
Будем прикладывать усилия, чтобы по окончании тестовой эксплуатации Ваша работа в частных облаках происходила уже без подводных камней 🙂
(4) Вот скриншот сегодняшнего замера в той же базе, три с небольшим года спустя
(6)
давно известный факт.
(8) Обратите внимание, дело происходило в 2015 году. Может быть тогда это был недавно известный факт