Добрый день.

Есть сервер с Windows Server 2016, MS SQL 2016 и сервером 1С 8.3.16.1876.
SQL База "Бухгалтерия для Украины, редакция 1.2".
Если запускать отчет в толстом клиенте (клиент-сервер) на этом же сервере  - он отрабатывает 10 сек.
Если запускать отчет в толстом клиенте (клиент-сервер) на любом другом, даже значительно более мощном компе - он отрабатывает 50 сек.
Сеть - просто гигабитный коммутатор.
При запуске отчетов - CPU компов не нагружаются более 2-3%, диски и сеть тоже без нагрузки.
Не могу найти узкое место, которое бы объяснило такую разницу во времени выполнения отчетов (и других операций)
Подскажите пожалуйста, как можно найти такую причину ?
Возможно есть какие-то конфигурации специально для этих целей ?

узкое место - синхронные сетевые вызовы, возвращающие малое количество данных. переходи на тонкий клиент целиком.

Но разве в случае запуска толстого клиента на том же сервере - он не использует те же синхронные сетевые вызовы ?

(0) Замечал подобное, решения тоже не нашел. Но мне кажется проблема в сети, точнее в комутаторах.
У меня такая конфигурация.
На 1 этаже стоит свитч, сервер и терминальный сервер.
На 2 этаже стоит свитч и 10 компьютеров.
На 3 этаже стоит свитч и 10 компьютеров.
Сеть везде 1Гб и скорость вроде везде нормальная, ping 1mc

Но запускаю отчет на сервере или терминальном сервере, которые стоят на 1 этаже и воткнуты в 1 свитч, отчет строится быстрее гораздо, чем на 2 и 3 этаже.
Причину не знаю, грешу на сеть. Сами свитчи могут тормозить, хотя при простом тестировании, когда копируешь файл на 1 Гб, показывают себе хорошо.

Вам можно проверить скорость запуска отчета подключив этот компьютер к комутатору, который подключен к серверу. Думаю тоже будет 10 секунд отрабатывать.

(3) Все подопытные включены в один свитч.
Все предыдущие опробованные компы с Windows 10 - отчет занимал 50 сек. Попробовал подключиться со старенького Windows Server 2003 - 10 сек !

(4) Кстати да, у меня сервер и терминальный сервер это Windows Server 2016 и Windows Server 2008r2.
А клиенты, это windows 7.
Возможно я зря грешу на сеть, а дело в ОС

Наткнули на мысль, если это касается Windows 7 и Windows 10.
Читал давно, что нужно настройки ОС и сетевого адаптера делать.
Вот нашёл одну из статей:
https://mega--obzor-ru.turbopages.org/mega-obzor.ru/s/kak-ispravit-medlennyj-internet-posle-obnovleniya-windows-10.html?utm_source=turbo_turbo

Ну, сетка очевидно. Может, дело в большом объеме данных, получаемом для отчета? Условно говоря, какой порядок количества строк результата?

(4) Хм. Интересно. Может, какая-то тонкая хрень типа размера пакетов.

(2) использует, но условные 0.0001мс и 0.1мс - есть разница? а этих микровызовов мнооооого. особенно весело работать с хранилищем, или там сравнение объединение запускать, если пинг до него миллисекунд так 50

(8) Или банальный не отключенный ipv6

(10) Все равно непонятно. Просадка в 5 раз на минуточку.

(10) IPv6 отключен

(11) значит из всего времени сетевое взаимодействие занимает 80%

А нет ли профайлера для 1С ? Или конфигурации, которая помогает найти узкие места ?

(14) в данном случае пможет переход на тонкого клиента

Очень похоже на накладные расходы на сетевое взаимодействие с Win10.
Нужно понять, почему старые операционки типа 2003 не тормозят.

(15) Если не разберусь - придется так и поступить

(12) Значит не до конца. Просто снять галку ipv6 в сетевых подключениях - недостаточно. Гугли.

А еще может оказаться, что сервер и не железный совсем, а там свои заморочки.

(16 тормзят)

(11) Ну или протоколы на MSSQL не настроены. На сервере внезапно включается шаред мемори, клиенты пытаются по именованым каналам, а древний 2003 которого послали с каналами, переключается на тсипип =)

(13) Раз есть компы что не тормозят - значит дело не в харде. И возникает вопрос, что такого может быть не так настроено на хосте, что в 5 раз просаживает сетку на одинэсном профиле нагрузки.

(21) Простите, не совсем вас понял.
К MSSQL подключается только СерверПриложений1С, расположенный на том же железе.
И соединение у них "Shared memory".
А толстые клиенты подключаются с Win10 и Win2003.

(22) может и в харде. например через коммутатор плохо лезут джумбо фрэймз или как там большие пакеты называются. а 2003 в это не умеет, получается обычные пакеты, у которых rtt в 2-4 раза меньше из-за коммутатора

нужен точный пинг, чтобы проверить, стандартный виндовский с точностью 1мс недостаточный.

(24) Ок. Может и в харде, но все равно должна быть разница в работе хостов. Понять бы её - а дальше дело техники.
Может, анализатор пакетов какой-нить может помочь...

во эта умеет до тысячных мс смотреть: https://nmap.org/nping/

хотя основная метрика для 1с - это скорее количество пакетов в секунду

Нет, проблема не в физической сети.
Подключил Win7x64 - получил 10сек !
Добавил гроздь коммутаторов последовательно, и повесил на дальний из них этот Win7x64 - те же 10 сек !

Т.е. проблема проявляется только если в качестве клиентов выступают Win10.

Что проверял:
- отключал напрочь IPv6 (и "галочкой", и в реестре, и через netsh...)
- отключал защитника/файрволл
- JUMBO фреймы включены и бегают без проблем

Причем толстый клиент, подключающийся с Win7x64 отрабатывает даже на пару секунд быстрее, чем локально запущенный на Win2016 (на котором MSSQL и Сервер1С).
Подключение во всех случаях разумеется через клиент-сервер.

сейчас подключишь вин 10, а там тоже все будет быстро формироваться, вот мы все поржем

(32) Если бы ))) c Win10 то все и началось.
Пробовал 5 разных машин - и AMD и Intel.
И свежие десятки, и LTSB/LTSC - одна и та же картина.

Взял стандартный отчет "Главная книга" за 2019-2021гг

Профайл на Win7x64:
http://i.piccy.info/i9/2306883fb3c4a59e5324d98638fe60fe/1617294336/23523/1423478/12242win7x64.png

Профайл на Win10x64:
http://i.piccy.info/i9/104f9481149d21900ae0122b0b4d3efd/1617294472/28556/1423478/win10x64.png

(30) Я бы джумбо вообще отключил. Не все коммутаторы умеют с ними работать. И как следствие - происходят задержки, пока протокол сообразит уменьшить размер пакета.

(34) Ну тут же ясно видно. Тормоза на .ПроверитьПрисоединение() - это значит, что сеть скорее всего ни при чем. Скорее всего задержка из-за обращения к драйверу принтера для получения параметров страницы. Попробуйте на этом компе сделать принтером по умолчанию какой-нибудь из стандартных типа pdf или xps -принтеров.
Кроме того, есть нюанс в последних версиях платформы с 8.3.16: работа с принтером вынесена из dll в отдельный процесс. И запуск этого процесса занимает какое-то время, задержка возможно из-за антивируса - попробуйте каталог с 1с добавить в исключения антивируса.

Внезапно :)