Как отключить сжатие передачи данных между клиентом и сервером 1с
платформа 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, на него вообще параметр запуска не прикрутить насколько я в курсе.
Добрый день. Ситуация следующая. По умолчанию при входе в режим предприятия Клиент запускается с параметром "Режим: Серверный (сжатие: усиленное)"
В базе есть объемные документы (больше 30к строк на тч 1 документа). При включенном сжатии происходит следующее. Такой документ записывается в базу 2-5 сек. а передача данных между клиентом и сервером занимает 840 сек.
При отключении сжатия параметром запуска клиента "/TComp -None" общее время выполнения уменьшается до 37 сек. для deflate алгоритма общее время выполнения 90 сек. Т.е. используемый платформой алгоритм по умолчанию тормозит процесс больше чем в 20 раз. Ну и ждать 14 минут пока запишется 1 документ несерьезно. (для чистоты эксперимента, документ писался как в режиме проведения, так и режиме записи, как с выполнением процедур "ПередЗаписью" и "ОбработкаПроверкиЗаполнения" так и без них. разница по времени выполнения записи в бд 0.1-3 секунды. Когда общее время 14 минут - моно сказать что разницы нет.)
Собственно сам вопрос: как отключить это сжатие со стороны сервера, чтобы не прописывать каждому клиенту "/TComp -None" в параметры запуска? Клиентов много. да и многие используют web, на него вообще параметр запуска не прикрутить насколько я в курсе.
Прикрепленные файлы:
По теме из базы знаний
- Параметры командной строки 1С:Предприятие
- Универсальный обмен данными XML через web-сервисы
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- HTTP сервер, HTTP асинхронный клиент, клиент ГИС МТ "Честный знак" внешние компоненты для 1С 7.7
- Обновление через копию 1С: ERP.УХ
Найденные решения
(4)
1) полагаю, что ввод строк в документ - не вручную, а загрузкой. тогда проще обработкой программно создавать документ и записывать в базу.
2) почему бы проводить документ не из формы документа, а из списка?
3) можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
1) полагаю, что ввод строк в документ - не вручную, а загрузкой. тогда проще обработкой программно создавать документ и записывать в базу.
2) почему бы проводить документ не из формы документа, а из списка?
3) можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
И не вчера, и даже не позавчера:
Похоже, что желаемого вами решения просто не существует: выбор режима задается клиентом.
И это, кстати, вполне логично: клиенты бывают разными, каналы связи у них - тоже разные, для одних приемлема работа без сжатия, для других - нет. Поэтому выбор осуществляется под каждого клиента свой, а сервер обязан обрабатывать все запросы.
Если бы был способ отключить сжатие на сервере и мы бы его отключили, то как осуществлялась бы работа с клиентом, которые требует сжатия? Не пущать его? Вряд ли это приемлемый способ.
Собственно сам вопрос: как отключить это сжатие со стороны сервера
Этим вопросом задавались и до вас:
И не вчера, и даже не позавчера:
Похоже, что желаемого вами решения просто не существует: выбор режима задается клиентом.
И это, кстати, вполне логично: клиенты бывают разными, каналы связи у них - тоже разные, для одних приемлема работа без сжатия, для других - нет. Поэтому выбор осуществляется под каждого клиента свой, а сервер обязан обрабатывать все запросы.
Если бы был способ отключить сжатие на сервере и мы бы его отключили, то как осуществлялась бы работа с клиентом, которые требует сжатия? Не пущать его? Вряд ли это приемлемый способ.
(2) Я согласен с вами что со стороны клиента должна быть возможность переопределить настройки подключения. Однако со стороны сервера должа быть возможность установить параметры по умолчанию. А таковой возможности как выходит просто не существует. и это как минимум странно.
(6)
А в клиенте 1С (и, насколько я понимаю, в браузере при подключении через WEB - тоже) сжатие по умолчанию включено. Так с чего серверу капризничать?
Однако со стороны сервера должа быть возможность установить параметры по умолчанию.
Тогда это был бы не сервер - по определению, формат обмена (и не только в 1С) запрашивает клиент, а сервер либо принимает запрос, либо отказывает в обслуживании.
А в клиенте 1С (и, насколько я понимаю, в браузере при подключении через WEB - тоже) сжатие по умолчанию включено. Так с чего серверу капризничать?
(22)
можно почитать на ИТС:
1. Про сервисы: Приложение 6. Интернет-сервисы получения списка общих информационных баз и дистрибутива клиентского приложения
2. Про списки: Списки общих информационных баз и ярлыки
2.1 Образец:
ПС: Действительно веб клиент игнорит параметр, ¯\_(ツ)_/¯,однако и усиленное сжатие по умолчанию не использует
TComp
можно почитать на ИТС:
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
У меня прям групповая политика прописана в домене на замену/создание файла с прописанными базами и методами подключения с применением на все сервера терминальные. В самой политике прописан путь как %appdata%\1c\1cestart и т.д. - применяешь до входа и всё - пользователь и список баз видит актуальный и сжатием управляешь через этот файл v8i
Параметры запуска для веб клиента задаются в адресной строке подключения, например так
см. тут
а вообще эти симптомы явно указывают, на проблемы в самом документе.
как минимум замеры производительности на запись и проведение этого документа произведите/покажите - думаю кандидаты на оптимизацию в виде неоптимальных запросов, обращений через точку или менеджеров записей вылезут сразу.
опыт подсказывает, что подкручивание настроек сервера не может происходить до бесконечности. в один прекрасный момент придется либо покупать ну очень мощный сервак, либо перепроектировать архитектуру и переписывать тонны кода.
см. тут
а вообще эти симптомы явно указывают, на проблемы в самом документе.
30к строк на тч 1 документа
документ записывается в базу 2-5 сек
передача данных между клиентом и сервером занимает 840 сек
как минимум замеры производительности на запись и проведение этого документа произведите/покажите - думаю кандидаты на оптимизацию в виде неоптимальных запросов, обращений через точку или менеджеров записей вылезут сразу.
опыт подсказывает, что подкручивание настроек сервера не может происходить до бесконечности. в один прекрасный момент придется либо покупать ну очень мощный сервак, либо перепроектировать архитектуру и переписывать тонны кода.
(3) Из-за специфики работы предприятия, сделать документ меньше не представляется возможным. Сервак итак ну ооооочень мощный.
Вот скрины сообщений меток времени выполнения процедуры на автоматически сгенерированной форме документа. со сжатием и без него.
Ощутимая разница. На форме и в модуле объекта выключено вообще все. ни одной строки кода, ни одной подписки. Т.е. просто гоняем данные туда-сюда со скоростью 10gbps. Поэтому грешить на оптимизацию кода не получается. Если вернуть документ к первоначальному виду. для указанной выше функции изменяется только время записи документа. с 0,03 до 0,4-1,1 сек в зависимости от текущей нагрузки.
Вот скрины сообщений меток времени выполнения процедуры на автоматически сгенерированной форме документа. со сжатием и без него.
&НаКлиенте
Процедура ЗаписатьДокумент()
ЗаписатьСервере();
КонецПроцедуры
&НаСервере
Процедура ЗаписатьСервере();
ДокОбъект = ДанныеФормыВЗначение(Объект,Тип("ДокументОбъект.МойДокумент"));
ДокОбъект.Записать(РежимЗаписиДокумента.Запись);
ЗначениеВДанныеФормы(ДокОбъект,Объект);
КонецПроцедуры
ПоказатьОщутимая разница. На форме и в модуле объекта выключено вообще все. ни одной строки кода, ни одной подписки. Т.е. просто гоняем данные туда-сюда со скоростью 10gbps. Поэтому грешить на оптимизацию кода не получается. Если вернуть документ к первоначальному виду. для указанной выше функции изменяется только время записи документа. с 0,03 до 0,4-1,1 сек в зависимости от текущей нагрузки.
Прикрепленные файлы:
(7)
Скринов нет. Сейчас тут выходные. Но использование ресурсов мониторил. сеть выше 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 гбит/сек изолированной сети вполне достаточно.
А как себя сеть и собственно сервер в эти 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 гбит/сек изолированной сети вполне достаточно.
(12)
ручное редактирование там тоже нужно) оптимизировать документ и форму практически некуда, все что можно не передавать на клиент итак не передается.
проблема то в другом) без сжатия док передается в 20 раз быстрее)
А как заполняется этот документ?
ручное редактирование там тоже нужно) оптимизировать документ и форму практически некуда, все что можно не передавать на клиент итак не передается.
проблема то в другом) без сжатия док передается в 20 раз быстрее)
(4)
1) полагаю, что ввод строк в документ - не вручную, а загрузкой. тогда проще обработкой программно создавать документ и записывать в базу.
2) почему бы проводить документ не из формы документа, а из списка?
3) можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
1) полагаю, что ввод строк в документ - не вручную, а загрузкой. тогда проще обработкой программно создавать документ и записывать в базу.
2) почему бы проводить документ не из формы документа, а из списка?
3) можно при запуске сеанса в общем модуле получать строку подключения, и если в ней нет флага отключения сжатия - перезапускать сеанс с новой строкой подключения с флагом.
(14)
1. Документ заполняется по кнопке, но данные корректируются вручную.
2. потому что кнопочка "провести и закрыть" после редактирования его таки проводит) и почему-то даже если заменить ее на стандартную "Записать и закрыть" все равно проводит(даже непроведенный) и потому что оптимизация документа в сторону уменьшения удобства для пользователя не вариант) рисовать свою кнопку вариант, но не хочется.
3. А вот это идея. попробую. только для web клиента кажется все равно не отработает. т.к. параметр выключающий сжатие не работает для web. Система его просто игнорирует.
1. Документ заполняется по кнопке, но данные корректируются вручную.
2. потому что кнопочка "провести и закрыть" после редактирования его таки проводит) и почему-то даже если заменить ее на стандартную "Записать и закрыть" все равно проводит(даже непроведенный) и потому что оптимизация документа в сторону уменьшения удобства для пользователя не вариант) рисовать свою кнопку вариант, но не хочется.
3. А вот это идея. попробую. только для web клиента кажется все равно не отработает. т.к. параметр выключающий сжатие не работает для web. Система его просто игнорирует.
(15)
И сколько времени приходится пользователю тратить на корректирование вручную "больше 30к строк на тч 1 документа"?
Может что-то в бизнес-логике поправить?
1. Документ заполняется по кнопке, но данные корректируются вручную.
И сколько времени приходится пользователю тратить на корректирование вручную "больше 30к строк на тч 1 документа"?
Может что-то в бизнес-логике поправить?
1. Передавайте с клиента и на клиент только изменённые строки в функцию &НаСервереБезКонтекста.
2. Пакуйте на сервере всё, что можно*, в массив строк, а потом в одну строку через СтрСоединить. На клиенте распаковывайте с помощью СтрРазделить. В обратную сторону тоже.
* А можно всё, поскольку пользователь в конечном счёте воспринимает и вводит только текст, то бишь строки.
2. Пакуйте на сервере всё, что можно*, в массив строк, а потом в одну строку через СтрСоединить. На клиенте распаковывайте с помощью СтрРазделить. В обратную сторону тоже.
* А можно всё, поскольку пользователь в конечном счёте воспринимает и вводит только текст, то бишь строки.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот
