Pull to refresh

Плохие линии связи для 1С — поможет ли Apache?

Level of difficultyEasy
Reading time3 min
Views2.6K

Медвежий угол в 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 протокол.

Результаты тестов можно посмотреть  тут

В таблице зафиксированы миллисекунды. Последние 4 столбца показывают еще один странный эффект – если поставить в описании базы данных «низкую скорость соединения» вместо обычной результаты получаются хуже хотя на стабильность это не влияет. С чем это связано не знаю, но возможно  какая то недоработка в клиенте  1С

До новых встреч на нашем канале t.me/Chat1CUnlimited , хороших Вам связей и связи.

Tags:
Hubs:
Total votes 5: ↑3 and ↓2+1
Comments15

Articles