Серверный сжатие усиленное что значит в 1с

Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве

/TComp [-None | -Deflate | -SDC] — устанавливает режим сжатия трафика между сервером и клиентом (используется в тонком клиенте).

-None — сжатие отключено;
-Deflate — используется стандартное http сжатие трафика по алгоритму deflate;
-SDC — используется собственный алгоритм сжатия;
По умолчанию используется SDC сжатие трафика.

в долнительных параметрах поставил /TComp -None
теперь: Серверный (без сжатия)

Серверный сжатие усиленное что значит в 1с

CPU-Z Single Thread

• Тест 4Gbit — QLogic QLE2460
• Тест 8Gbit -QLogic QLE2560

• Microsoft Windows Server 2016 Standart
• Microsoft SQL Server 2016 SP1 (13.0.4001.0)
• Гипервизор Hyper-V
• Сервер 1C:Предприятие 8.3.10.2667
• CrystalMark 6.0.2
• Виртуальная машина BitrixVM 7.3.0 с объемом диска 20 ГБ для HyperV

• Однопоточный синтетический тест платформы 1С:Предприятие + Многопоточный тест записи на диск (2.1.0.7) Гилёв Вячеслав Валерьевич

• Размер 0,072 ГБ
• Платформа: 1С:Предприятие 8.3 (8.3.10.2667)

Тест Гилева (TPC-1C)

Тест с использованием программы CrystalMark

• Количество проверок — задаёт количество повторов, по результатам которых выводит среднее значение
• Размер файла — задает объем файла, который будет использоваться для чтения или записи в тестах
• Диск — позволяет выбрать диск, который будет тестироваться

• из-за чего тормозит сервер 1С?
• компьютер с 1С работает очень медленно
• жутко тормозит клиент 1С

Что же делать и как это победить, и так по порядку:

Проблемы производительности

Хочу рассмотреть вопросы и подготовку к сертификации. Учить правильные ответы плохой путь, а вот понимать ответы и применять их, вы тем самым становитесь на путь к уровню «1С:Эксперт». По сути это цикл записей с расширенными ответами на несколько вопросов из тестов.

У проблем производительности есть два обычных подозреваемых:
• не оптимальные запросы;
• плохая работа кода.

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

«Время ожидания блокировки данных (в секундах)» влияет как на время ожидания управляемых блокировок данных «1С:Предприятие 8» так и на время ожидания блокировок данных СУБД.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 59.

Увеличение времени ожидания блокировки данных позволяет уменьшить количество таймаутов в системе, но эффект от этого есть только в том случае, если их там и так единицы. Оно не устраняет причин возникновения таймаутов, а лишь маскирует сами таймауты.
Если в информационной системе есть взаимоблокировки, редактирование этого параметра бесполезно.
В подавляющем большинстве случаев изменять этот параметр не надо, следует использовать значение по умолчанию, равное двадцати секундам.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 259.

Выполнять подсчет и анализ клиент-серверных вызовов с помощью замера производительности в конфигураторе можно, но нужно учитывать, что этот режим показывает только вызовы, которые выполняются непосредственно в ходе выполнения модулей и не показывает вызовы, которые выполняются платформой вне выполнения модулей.

Режим сжатия тонкого клиента влияет на производительность в зависимости от баланса пропускной способности сети и мощности клиентского компьютера. При наличии явной зависимости подбирается экспериментально.

Большое количество клиент-серверных вызовов замедляет работу — на каждый клиент-серверный вызов тратится время (в том числе на переустановку соединения), влияние наиболее ощутимо на медленных каналах связи

Режим сжатия тонкого клиента можно изменить с помощью ключа командной строки или в режиме программы запуска «1С:Предприятие 8» указать дополнительный параметр запуска (воспользоваться командой «Изменить»). Режим сжатия можно регулировать параметром строки /TComp :

• -None — сжатие не используется;
• -Deflate — используется сжатие по алгоритму deflate;
• -SDC — используется собственный алгоритм сжатия.

Каждый вид клиента в условиях конкретного прикладного решения имеет свою границу пропускной способности сети, выше которой влияния на производительность нет, ниже которой производительность последовательно снижается.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 156-157.

Рекомендованных требований к пропускной способности сети для производительной работы «1С:Предприятие 8» нет, так как они определяются из задачи работоспособности, а не производительности. Единственное требование — сеть должна быть работоспособной.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 153-154.

При прочих равных более существенным для производительности сервера приложений «1С:Предприятие 8» для целей многозадачной работы является суммарное количество ядер процессоров.
Источники:
• ИТС: Требования к аппаратуре и программному обеспечению

Антивирусное программное обеспечение может негативно влиять на производительность клиент-серверного режима работы «1С:Предприятие 8» на сервере, так и на клиенте.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 157-158.

Чтобы проверить отсутствие промежуточных точек маршрутизации между сервером и клиентом необходимо воспользоваться командой tracert.

Межсетевые экраны могут влиять на производительность клиент-серверного режима работы платформы «1С:Предприятие 8» вплоть до полной неработоспособности.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 157-158.

Вообще говоря, лучше, если все серверы, относящиеся к ландшафту «1С:Предприятие 8», находятся в одном сегменте сети. Это снимает целый класс потенциальных проблем. Проверить, есть ли в сети маршрутизация, можно с помощью команды tracert.Дело в том, что при прохождении пакета из одной подсети в другую через роутер на нем обязательно происходит задержка пакета на его обработку. Чаще всего и в основном потери времени идут на логирование, но могут быть задержки и на других программных надстройках роутера.
Длинные пакеты задерживаются на большее время, чем короткие. В результате штатными средствами (ping) эта задержка не определяется, так как там по умолчанию очень короткие пакеты, которые, если нет проблем, проходят быстро. А длинные пакеты (работа с СУБД и обмен между серверами) задерживаются, и это – нормальная работа.
Однако и в том случае, если речь идет о VLAN, полностью снимать вопрос о непричастности маршрутизации к проблемам не стоит.
Источники:
• книга «Настольная книга 1С:Эксперта по технологическим вопросам», издание 2, с. 157-158.

В окне показателей производительности можно увидеть текущие и накопленные: количество вызовов сервера, длительность вызова сервера, объем отправленных данных, объем принятых данных. В отдельных окнах — историю текущих и историю накопленных значений.

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

Режим отображения показателей производительности можно включить с помощью соответствующей настройки параметров конфигуратора или ключа командной строки /DisplayPerformance , а также можно включить и в режиме «1С:Предприятие» с помощью флажка «Отображать показатели производительности» диалога «Сервис» – «Параметры».

Показатель APDEX рассчитывается по формуле: APDEX = (Nt + N4t / 2) / N, где
N — общее число операций за период,
Nt — число операций выполненное за целевое время T,
N4t — число операций не уложившиеся в T, но уложившиеся в 4T,
NF — число операций не уложившиеся в 4T.
Соответственно формула, указывающую насколько изменится APDEX всей информационной системы в случае оптимизации выбранной:
deltaAPDEX = (NF + N4t / 2) / N

От экспертов «1С‑Рарус»: Ускоряем в 3 раза открытие сложной формы в 1С 8.3

В финансовых решениях консолидационного класса или класса ERP предлагается функциональность, связанная с составлением оперативных или мастер-бюджетов, например, работа с бюджетом доходов и расходов.

Экземпляр бюджета — это хрестоматийный пример сложной формы, где есть:

• данные в разрезе каждого месяца года (в колонках);
• группировка по настраиваемой структуре разделов и статей (в строках);
• возможность внесения изменений онлайн;
• автоматический пересчет сумм зависимых формул;
• отрисовка плана и факта рядом на пересечении месяца и статьи;
• вывод в будущих месяцах плановых значений в ячейках факта.

Как видно, логика работы достаточно нагруженная и, как следствие, данных на форме много.

Руководитель подразделения открывает форму экземпляра бюджета и долго ждет ее открытия. Если время ожидания слишком велико, то в конечном итоге менеджер переходит для осуществления процесса бюджетирования в табличный инструмент класса Excel.

После разработки и включения в рабочую базу оказалось, что открытие формы бюджета в терминах структур разделов и статей компании занимает 1,5 минуты и более. Это неприемлемо, тем более что основные пользователи системы — руководители подразделений, и без того сталкивающиеся с нехваткой времени.

Мы поставили перед собой задачу сократить открытие такой формы до времени <= 30 секунд.

Программная и аппаратная инфраструктура

• Нетиповая конфигурация собственной разработки.

Замечание: подобные проблемы могут также быть актуальны для иных систем класса ERP, например:

Используется трехзвенная клиент-серверная архитектура с доступом тонкого клиента через веб-сервер. Сервер СУБД и Сервер 1С:Предприятия совмещены на одной машине.

Сервер СУБД

• Процессор: Intel Xeon CPU E5-2637 v2, 2 процессора 3,5 Ghz.
• Память: 96 GB (разрешено потреблять СУБД не более 73728 MB).
• Жесткий диск SSD.

• MSSQLServer 2014 (12.0.4237.0).
• MS Windows NT 6.1 (7601).

Сервер «1С:Предприятие»

• Тот же сервер, что и сервер СУБД.
• Память: доступна вся свободная память, то есть, не менее 24576 MB.

• 1С 8.3.14.1694.

Веб-сервер

• Процессор: Intel core 2 DUO E7500 2,93 GHz.
• Память: 4 GB.

• MS Internet Information Services 8.5.96.
• MS Windows Server 2012 R2.

Тонкий клиент

• Процессор: Intel Core i5.
• Память: 16 GB.
• Диск SSD.

• 1С 8.3.14.1694 — тонкий клиент.
• MS Windows 10.

Ищем причину медленного открытия формы и устраняем ее в «1С»

1. Для начала расследования снимаем замер производительности в «1С» процесса открытия формы

В замере видно, что лидер по абсолютному времени выполнения — метод «ОткрытьФорму».

Из 104 секунд открытия 64 приходятся на этот метод.

При этом сделать вывод о причинах медленного открытия из этого замера невозможно.

2. Соберем технологический журнал для анализа медленного открытия

Какие события собираем

Собираем события CALL и SCALL.

Выдержка из документации по платформе:

• SCALL — исходящий удаленный вызов (исходящий вызов на стороне источника вызова).
• CALL — входящий удаленный вызов (удаленный вызов на стороне приемника вызова).

Эти события возникают при клиент-серверном взаимодействии.

Бытует мнение, что SCALL всегда возникает при обращении с клиента на сервер, а CALL — при приходе этого обращения на сервер.

Нередко это так и есть, например, когда клиент обращается к серверу.

Однако это не всегда так. Например, могут быть обращения внутри сервера между менеджером кластера и рабочим процессом, между сервером и клиентом и так далее.

Пример иного случая возникновения событий CALL и SCALL.

Цели сбора

Преследуем 2 цели:

• посмотреть длинные по времени вызовы;
• найти «лаги» в технологическом журнале.

С длинными вызовами вопросов не возникает: есть оператор программы, который длится слишком долго, и это можно в явном виде обнаружить в ТЖ. По сути, хотим увидеть то же, что в замере производительности.

Что такое «лаг технологического журнала»? Под ним понимается ситуация, когда в явном виде событий с большим временем исполнения в журнале нет, но косвенно об этом догадываемся за счет присутствия большой паузы между двумя соседними событиями в журнале по одной сессии.

Метод сбора

Метод сбора технологического журнала (далее — ТЖ) — обычный:

• в папке C:\Program Files\1cv8\conf создаем файл logcfg.xml (структура файла ниже);
• ждем, пока в папке с логами, указанной в logcfg, появятся подпапки с именами процессов сервера;
• выполняем открытие формы;
• убираем файл logcfg.xml из папки;
• ждем не более 5 минут, пока система завершит запись файлов журнала;
• забираем файлы технологического журнала из подпапки rphost_<номер процесса>.

В нем настроено:

• папка для сбора логов C:\logs;
• отбор по событиям CALL и SCALL;
• отбор по имени базы rarus_fb.

Анализируем данные собранного лога технологического журнала. Нехитрым скриптом посмотрим наиболее долгие вызовы.

Примечание по скрипту

По сути, скрипт отбирает из ТЖ события, с длительностью от 2 знаков (с 10 секунд и более). Т. к. время в ТЖ 8.3 — в микросекундах, то нам нужен отбор по времени > 8 разрядов; чтобы не писать много букв в регулярном выражении, используем синтаксис расширенных регулярных выражений: <8,>, который включается ключом -E.

Видим, что существует долгое событие CALL длительностью 85 секунд, на котором происходит большое потребление памяти 554 Мб, а в пике 701 Мб и оно возникает на методе ПолучитьФорму.

Соберем лаги ТЖ.

Сделаем это более сложным скриптом, суть которого в том, чтобы сравнить по времени 2 соседних события ТЖ и найти среди них наибольшие паузы.

• в скрипте делаем отбор по t:clientID, равному ID нашего клиента, чтобы учесть только события по текущему пользователю.

В результате получаем:

В первой колонке — время лага в микросекундах, далее — время старта двух соседних событий.

Видно, что первым номером идет лаг, сопоставимый по времени с временем открытия формы.

Делаем предположение, о том, что тяжелая форма долго загружается с сервера на клиент.

3. Посмотрим на форму в конфигураторе

Что же такое разработчик заложил на форме? Может быть данные формы перегружены избыточной информацией?

Важный элемент расследования — просто посмотреть на творение рук разработчика глазами в конфигураторе «1С».

Видим несколько таблиц значений на форме. Отладчиком посмотрим для реального бюджета, какое количество строк в них.

А строк совсем немало. И всё это при открытии перегружается с сервера на клиент.

Убедимся в этом тезисе.

4. Используем Fiddler в режиме ReverseProxy

Чтобы окончательно убедиться в том, что медленная работа обусловлена «большими» данными формы и понять, что именно это за данные, перехватим их.

Для перехвата встроим между веб-сервером и тонким клиентом «1С» программу Fiddler в режиме Reverse proxy. Эта программа по сути является отладчиком при передаче данных по протоколу http.

Режим Reverse proxy позволяет «вставить Fiddler в разрыв» между веб-сервером и клиентом и проанализировать пакеты обмена.

Настройка Fiddler в режиме ReverseProxy

Настройку будем производить на копии рабочей базы, которая развернута в той же инфраструктуре.

Настройка режима состоит на верхнем уровне из двух этапов:

• настроить на веб-сервере переадресацию url-rewrite на сервер с Fiddler’ом;
• настроить сам Fiddler.

Для настройки веб-сервера вводим правило url-rewrite на сервер finsrv, порт 8888, на котором будет слушать Fiddler.

Устанавливаем на отдельный сервер наш Fiddler и настраиваем в режиме Reverse proxy, как описано здесь.

Проверяем в опциях, что установлен флаг «Allow remote computers to connect».

if (oSession.host.toLowerCase() == «webserver:8888») oSession.host = «webserver:80»;

Отслеживаем взаимодействие между веб-сервером и клиентом «1С»

Теперь мы можем отслеживать все http-пакеты между веб-сервером и клиентом «1С».

Зайдем в копию базы и дойдем до открытия формы экземпляра бюджета, но открывать не будем. Перейдем в Fiddler, посмотрим, пакет с каким номером был получен последним, и запомним его номер. Теперь откроем форму бюджета, дождемся окончания открытия и посмотрим все пакеты от запомненного до самого последнего.

Видим входящий запрос с большим объемом данных.

Предполагаем, что это и есть данные формы. Смотрим подробности данных в правом окне:

Обращаем внимание, что прочитать можно только заголовки, а данные, похоже, сжаты, о чем также свидетельствует надпись 1C‑SDCversion и далее — MZ, что соответствует началу сжатой части.

• По 1C-SDCversion — ищем на партнерском форуме «1С» и встречаем упоминание о том, что это метод сжатия deflate.

Вспоминаем, что по умолчанию клиент «1С» запрашивает работу со сжатием данных между клиентом и сервером.

С помощью запуска тонкого клиента со специальным параметром отключаем этот режим.

Делаем повторное открытие формы и видим в Fiddler’е уже вполне читаемую картину.

Обращаем внимание, что без сжатия данные формы весят более 1 Мб, что немало.

Наконец справа видим данные формы:

Переходим на представление «TextView», копируем в буфер и сохраняем как xml.

Обращаем внимание на наличие больших блоков в ветке props c внушительным количеством строк, которое сопоставимо с числом строк таблиц значений на форме:

• 10668,
• и 903,

а также со свойством fullChanged=»true». Последнее скорее всего означает разрешение на изменение строк объекта на клиенте.

Выдвигаем предположение о том, что в данных формы на клиента приходят с сервера служебные таблицы значений.

С точки зрения функционирования алгоритма они не требуются на клиенте. Принимаем решение избавиться от таблиц значений на клиенте.

5. Разгружаем форму в «1С»

Что тяжелее всего?

• На форме есть таблицы значений с большим числом строк.
• Обработка объект содержит табличные части с большим числом строк.

Отказываемся от использования таблиц значений на форме и табличных частей в пользу такого подхода:

• на сервере создаем таблицы значений;
• при переходе на клиента помещаем их во временное хранилище, а на форме храним только его адрес;
• после возврата на сервер получаем таблицы значений из временного хранилища.

6. Смотрим в Fiddler результат «разгрузки» формы

Видно, что объем данных формы сократился более чем в 5 раз.

7. Делаем повторный замер производительности и смотрим потребление памяти и лаги в ТЖ

Накатываем изменения на рабочую базу, собираем замер производительности «1С».

Видим, что теперь открытие формы экземпляра бюджета составляет 25 секунд, а метод ОткрытьФорму — всего 2,1 секунды.