Все знают, что 1С поддерживает работу по HTTPчерез Apache как в режиме Тонкого клиента, так и в режиме Веб клиента. Так же в тонком клиенте 1C можно указать скорость соединения. Мы знаем, что танки грязи не боятся, боится ли 1С плохих линий?
1С для плохих линий связи – поможет ли Apache?
Медвежий угол в 30 км от МКАД
Есть много мест куда не дотянулась качественная связь даже в ближайшем Подмосковье, для теста возьмем модем Yota, подключенный к ноутбуку через USB. В точке тестирования прием на две-три палки, но именно Yota здесь держит интернет связь лучше чем МТС. Задержка по ping 30-40 мс до www.mos.ru и периодически бывают request timeout. В общем ничего хорошего, даже в соотношение сигнал шум лезть не хочется.
Пробуем ресурс с RDP сеансом до него 50 мс по проводам – значит общая задержка по мобильному каналу будет 80-90 мс по мобильному каналу. Работает в целом удовлетворительно
Далее попробуем ресурс с RDP сеансом, до которого 150 мс по проводам – значит общая задержка по мобильному каналу будет 180 – 190 мс. Работает крайне медленно, с постоянными разрывами связи
Очевидно, что в последнем случае у нас всего четыре альтернативы
· Тонкий клиент по TCP (соединение напрямую к кластеру 1С)
· Тонкий клиент по HTTP\HTTPS (сейчас практически безальтернативно через Apache)
· Веб клиент (сейчас практически безальтернативно через Apache)
· Репликация на уровне 1С управление распределенными базами данных – работа с локальной базой для удаленных офисов.
Если у Вас есть VPN (виртуальная частная сеть) Вы можете использовать любой вариант, если без VPN то только протокол HTTPS с необходимым уровнем безопасности.
В нашем случае VPN есть, проверим работу Тонкого клиента с ресурсом до которого ping будет 190-210 мс по мобильной связи с периодическими Request time out. В качестве теста используем простой код на циклическое открытие форм. По сути это запрос к субд, передача данных через кластер 1С, веб сервер, и открытие формы на клиенте.
Замеры = Новый Массив;
ОбщееВремя = 0;
Для каждого ТекДок Из МассивДокументов Цикл
ПараметрыФормыДокумента = Новый Структура;
ПараметрыФормыДокумента.Вставить("Ключ", ТекДок);
ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
ФормаДокумента = ОткрытьФорму("Документ.СУУ_СделкаСырье.Форма.ФормаДокумента", ПараметрыФормыДокумента);
ПараметрыФормыРегистра = Новый Структура;
СтруктураОтбора = Новый Структура;
СтруктураОтбора.Вставить("Регистратор", ТекДок);
ПараметрыФормыРегистра.Вставить("Отбор", СтруктураОтбора);
ОткрытьФорму("РегистрБухгалтерии.Хозрасчетный.ФормаСписка", ПараметрыФормыРегистра, ФормаДокумента, , ФормаДокумента.Окно, , , );//РежимОткрытияОкнаФормы.
ФормаДокумента.Закрыть();
ТекущийЗамер = ТекущаяУниверсальнаяДатаВМиллисекундах() - ВремяНачала;
ОбщееВремя = ОбщееВремя + ТекущийЗамер;
Замеры.Добавить(ТекущийЗамер);
КонецЦикла;
Странный выбор между TCP или HTTP
Посмотрим результаты
Первое что бросается в глаза это разница открытия форм по проводам и беспроводной связи.
Казалось бы в первом случае задержка тоже немалая 150- 160 мс , но за счет стабильности (отсутствия Request timeout) результаты отличаются в разы 1 секунда против 4-9 секунд на открытие формы.
Вывод 1. Важна не столько задержка в канале, а сколько стабильность (отсутствие Request timeout по ping) в канале.
Второе что видно – это преимущество работы по TCP против HTTP в плане скорости. Это объяснимо – поскольку промежуточное звено в виде веб сервера дает свою задержку. Просто посмотрите на архитектуру
Работа через веб сервер
Работа через кластер 1с
Вывод 2 На стабильных линиях связи по VPN протокол TCP в общем случае обеспечивает лучшую скорость в режиме Тонкого клиента.
Тут нужно дать оговорку, на моем стенде Apache 2.4 на Linux установлен с настройками по-умолчанию.
Возможно тонким тюнингом, расположением его на сервере с более высокой тактовой частотой и подобными мероприятиями можно нивелировать различие. Может кто-нибудь уже знает ответ?
С точки зрения настроек все устроено просто.
В apache httpd.conf
Прописан LoadModule _1cws_module “opet/1cv8/x86_64/8.3.23.1739/wsap24.so”
И прописан Alias на публикацию с default.vrd файлом. Как конкретно идет взаимодействие с кластером в документации не указано.
1C по http имеет важное преимущество (по крайней мере в релизе 1С:Предприятие 8.3 (8.3.23.1739) ) – устойчивость к обрывам связи!
Т.е. если все плохо выскакивает сообщение
1C по TCP наоборот зависает на 10 мин и только потом переподключается
Вывод 3. Предельным комфортным вариантом качества линии связи для работы тонкого клиента 1С является задержка 150-200 мс . При этом Request timeout быть не должно. Если вероятность Request timeout существует нужно однозначно использовать http\https протокол.
Результаты тестов можно посмотреть тут
В таблице зафиксированы миллисекунды
До новых встреч на нашем канале t.me/Chat1CUnlimited , хороших Вам связей и связи.