платформа 8.3.11, актуально для всей линейки, как и для 8.3.10. более ранние версии не проверял
Добрый день. Ситуация следующая. По умолчанию при входе в режим предприятия Клиент запускается с параметром "Режим: Серверный (сжатие: усиленное)"
В базе есть объемные документы (больше 30к строк на тч 1 документа). При включенном сжатии происходит следующее. Такой документ записывается в базу 2-5 сек. а передача данных между клиентом и сервером занимает 840 сек.
При отключении сжатия параметром запуска клиента "/TComp -None" общее время выполнения уменьшается до 37 сек. для deflate алгоритма общее время выполнения 90 сек. Т.е. используемый платформой алгоритм по умолчанию тормозит процесс больше чем в 20 раз. Ну и ждать 14 минут пока запишется 1 документ несерьезно. (для чистоты эксперимента, документ писался как в режиме проведения, так и режиме записи, как с выполнением процедур "ПередЗаписью" и "ОбработкаПроверкиЗаполнения" так и без них. разница по времени выполнения записи в бд 0.1-3 секунды. Когда общее время 14 минут - моно сказать что разницы нет.)
Собственно сам вопрос: как отключить это сжатие со стороны сервера, чтобы не прописывать каждому клиенту "/TComp -None" в параметры запуска? Клиентов много. да и многие используют web, на него вообще параметр запуска не прикрутить насколько я в курсе.
1) полагаю, что ввод строк в документ - не вручную, а загрузкой. тогда проще обработкой программно создавать документ и записывать в базу.
2) почему бы проводить документ не из формы документа, а из списка?
3) можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
Похоже, что желаемого вами решения просто не существует: выбор режима задается клиентом.
И это, кстати, вполне логично: клиенты бывают разными, каналы связи у них - тоже разные, для одних приемлема работа без сжатия, для других - нет. Поэтому выбор осуществляется под каждого клиента свой, а сервер обязан обрабатывать все запросы.
Если бы был способ отключить сжатие на сервере и мы бы его отключили, то как осуществлялась бы работа с клиентом, которые требует сжатия? Не пущать его? Вряд ли это приемлемый способ.
(2) Я согласен с вами что со стороны клиента должна быть возможность переопределить настройки подключения. Однако со стороны сервера должа быть возможность установить параметры по умолчанию. А таковой возможности как выходит просто не существует. и это как минимум странно.
Однако со стороны сервера должа быть возможность установить параметры по умолчанию.
Тогда это был бы не сервер - по определению, формат обмена (и не только в 1С) запрашивает клиент, а сервер либо принимает запрос, либо отказывает в обслуживании.
А в клиенте 1С (и, насколько я понимаю, в браузере при подключении через WEB - тоже) сжатие по умолчанию включено. Так с чего серверу капризничать?
(1)
1. Используя сервисы/списки общих информационных баз, можно задавать клиентам параметры запуска централизовано (если их (списков) нет - пора завести)
2. Для веб клиентов можно модифицировать URI на стороне веб сервера (3)
1. Про сервисы: Приложение 6. Интернет-сервисы получения списка общих информационных баз и дистрибутива клиентского приложения
2. Про списки: Списки общих информационных баз и ярлыки
2.1 Образец:
[ERP 2 - Тест центр (8.3.11)]
Connect=Srvr="K1709040:6541";Ref="КЭ_ERP2_ТестЦентр";
ID=8e56d628-9499-4a63-8e86-6ffae5b31ee8
OrderInList=950272
Folder=/Тест центр
OrderInTree=8192
External=0
ClientConnectionSpeed=Normal
App=Auto
WA=1
Version=8.3
DefaultVersion=8.3.11.2867
AdditionalParameters=/DEBUG /TESTMANAGER /TComp -None
Показать
ПС: Действительно веб клиент игнорит параметр, ¯\_(ツ)_/¯,однако и усиленное сжатие по умолчанию не использует
(1) А почему просто не подменить файл "C:\Users\ИмяПользователя\AppData\Roaming\1C\1CEStart\ibases.v8i".
У меня прям групповая политика прописана в домене на замену/создание файла с прописанными базами и методами подключения с применением на все сервера терминальные. В самой политике прописан путь как %appdata%\1c\1cestart и т.д. - применяешь до входа и всё - пользователь и список баз видит актуальный и сжатием управляешь через этот файл v8i
а вообще эти симптомы явно указывают, на проблемы в самом документе.
30к строк на тч 1 документа
документ записывается в базу 2-5 сек
передача данных между клиентом и сервером занимает 840 сек
как минимум замеры производительности на запись и проведение этого документа произведите/покажите - думаю кандидаты на оптимизацию в виде неоптимальных запросов, обращений через точку или менеджеров записей вылезут сразу.
опыт подсказывает, что подкручивание настроек сервера не может происходить до бесконечности. в один прекрасный момент придется либо покупать ну очень мощный сервак, либо перепроектировать архитектуру и переписывать тонны кода.
Ощутимая разница. На форме и в модуле объекта выключено вообще все. ни одной строки кода, ни одной подписки. Т.е. просто гоняем данные туда-сюда со скоростью 10gbps. Поэтому грешить на оптимизацию кода не получается. Если вернуть документ к первоначальному виду. для указанной выше функции изменяется только время записи документа. с 0,03 до 0,4-1,1 сек в зависимости от текущей нагрузки.
А как себя сеть и собственно сервер в эти 800 секунд?
Скринов нет. Сейчас тут выходные. Но использование ресурсов мониторил. сеть выше 10% не нагружается в принципе. Серверная часть 1С ЦП 30-50%, память до 70% пиковая, в основном держалось в районе 40-50%. пиковая нагрузка на 1 rphost-процесс 15% ЦП, 1,5 гб памяти (не более 2 таких процессов одновременно), в среднем 1-3% и 300-400мб памяти. на сервере БД (MS SQL) замеры не делал. т.к. в процессе возврата управления клиенту не участвует. Клиентская часть при данном анализе ЦП выше 60% не нагружалась, памяти съедено было под 70%, т.к. большое количество RDP сессий. Текущий процесс 1с который ждет возврата с сервера выше 5% цп не нагружал. памяти сейчас не могу вспомнить сколько ел, но разница между простоем и записью документа была минимальной.
Сначала думал что виной блокировки. Но висит не запись, а возврат на клиент. т.е. по факту получаем либо сервер долго жмет пакеты перед отправкой либо эти вычисления по какой-то причине на серверной части не хотят выполняться параллельно и как будто висят в очереди, либо клиентская часть долго их распаковывает. Только монитор ресурсов четкого представления о происходящем не дал. с его точки зрения, свободных вычислительных мощностей еще с запасом.
Простым решением было выключить сжатие у всех, сняв излишнюю нагрузку. которая не нужна в данной конфигурации, освободив мощности для выполнения более необходимых операций. Сеть узким местом с такой пропускной способностью вряд ли станет. 10 гбит/сек изолированной сети вполне достаточно.
либо сервер долго жмет пакеты перед отправкой либо эти вычисления по какой-то причине на серверной части не хотят выполняться параллельно и как будто висят в очереди
(11) А как заполняется этот документ? Может быть не отображать ТЧ этого документа, а построить ДС если заполнение программное и нужно только отображать информацию из ТЧ? Или выводит в ТЗ порциями данные?
1) полагаю, что ввод строк в документ - не вручную, а загрузкой. тогда проще обработкой программно создавать документ и записывать в базу.
2) почему бы проводить документ не из формы документа, а из списка?
3) можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
1. Документ заполняется по кнопке, но данные корректируются вручную.
2. потому что кнопочка "провести и закрыть" после редактирования его таки проводит) и почему-то даже если заменить ее на стандартную "Записать и закрыть" все равно проводит(даже непроведенный) и потому что оптимизация документа в сторону уменьшения удобства для пользователя не вариант) рисовать свою кнопку вариант, но не хочется.
3. А вот это идея. попробую. только для web клиента кажется все равно не отработает. т.к. параметр выключающий сжатие не работает для web. Система его просто игнорирует.
1. Документ заполняется по кнопке, но данные корректируются вручную.
И сколько времени приходится пользователю тратить на корректирование вручную "больше 30к строк на тч 1 документа"?
Может что-то в бизнес-логике поправить?
можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
1. Передавайте с клиента и на клиент только изменённые строки в функцию &НаСервереБезКонтекста.
2. Пакуйте на сервере всё, что можно*, в массив строк, а потом в одну строку через СтрСоединить. На клиенте распаковывайте с помощью СтрРазделить. В обратную сторону тоже.
* А можно всё, поскольку пользователь в конечном счёте воспринимает и вводит только текст, то бишь строки.