IIS? Apache? А может быть, Node.js?

14.12.23

Интеграция - WEB-интеграция

Можно ли использовать Node.js вместо нативных http-сервисов 1С под Apache и IIS? Можно! Сравниваем, анализируем, выбираем.

http-сервисы - один из самых прогрессивных способов интеграции сторонних систем в 1С, простой и основанный на широко применяемом протоколе. Однако и он не лишен недостатков:

  • Нам не известно, что у него под капотом, мало информации о сравнениях производительности и быстродействия с аналогами, мало изучено поведение сервисов на длительных больших нагрузках
  • Интересное лицензирование a.k.

 

 

  • Выбор лишь между IIS и Apache для веб-сервера. В самих IIS/Apache ничего плохого нет (разве что тяжеловаты), особенно если учесть, что под них сделаны не только сервисы, но и веб-клиент. Однако, подобная "прибитость гвоздями" ограничивает возможности разработчика в поиске оптимальных решений для своих задач

Но, как оказалось, есть еще одна альтернатива, которая позволяет немного (и даже с пользой) разнообразить стэк технологий для интеграции с внешним миром. А именно - прикрутить к 1С node.js. 

Далее я буду идти по порядку: начиная от стандартного 1С->http-сервис->IIS и закончу на максимальном отходе от канонов, чтобы показать все в сравнении. Будет много букв и много моих любимых графиков с k6 (сервис для стресс-тестирования веб-приложений)

 

Классика

 

Начнем с простого: 1С IIS. Не так давно я публиковал статью о своем проекте, где 1С выступает в роли бэка для веб-приложения. Вот она:

 

HTTP, Ajax, JSON: Один год Pet-проекту на 1С

WEB-интеграция Платформа 1С v8.3 Бесплатно (free)

Как 1С может стать площадкой для хобби и что из этого может получиться.

 

 

 

 

 

 

 

 

Там я рассказывал, в том числе, и о его быстродействии - собственно быстродействии http-сервисов на IIS. Однако, спустя некоторое время, я пришел к выводу, что приведенные мной данные не соответствуют действительности, если не сказать больше. Дело в том, что для теста я использовал один, постоянно повторяющийся, POST запрос с одним и тем же JSON внутри. 

 

 

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

1. Поиск пользователя по chat_id (запрос к справочнику)

2. Поиск книги по text: 7547G (запрос к справочнику)

3. Поиск, читал ли данный пользователь уже данную книгу (запрос к МЗ)

4. Отправка нужной страницы (поиск по табличной части элемента из п.2, http-запрос)

5. Запись прогресса - первая страница прочитана (МЗ.Прочитать, МЗ.Записать)

6. Запись общего дневного прогресса пользователя для дашборда в профиле (МЗ.Прочитать, МЗ.Записать)

Идентичность данных в запросах позволила 1С переиспользовать сеансы, а, как следствие, очень сильно порезала нагрузку на сервер, так как соединений плодилось гораздо меньше и процесс кластера не трясло. В реальной жизни такой ситуации, разумеется, быть не может - никто не будет посылать одни и те же данные. Поэтому, для новых тестов я сделал 25 разных запросов. И тут все завертелось...

Вот как это было тогда. Да, не очень быстро, но тут я даже мог на 4 области объяснить, что происходит.

 

 

Этот же тест теперь:

 

Remember this guy? Feel old yet?

Ну начнем с простого. Пиковое и общее количество запросов увеличилось, т.е. за то же время было обработано больше. И это даже было бы хорошо, если бы все шло, как и шло в начале. Проблема, как уже очевидно, во второй части теста, где систему начало трясти под нагрузкой. Классическая ситуация из разряда

 

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

  • Тестирование происходит на очень слабом железе - показатели низкие. Это буквально mini pc, который я использую как домашний сервер (подробнее в статье выше). Здесь это не играет роли: главное, что железо во всех тестах одинаковое, а смысл как раз в сравнении разных способов интеграции в одинаковых условиях.
  • Данные отправляются те же, что и в тесте из предыдущей статьи (скрин JSON и описание выше), но некоторые данные от запроса к запросу были изменены. Непосредственно обработка логики внутри 1С от этого не изменилась.
  • Максимальное количество одновременных http-соединений в пуле можно ограничить. Однако во-первых, тогда будут большие потери по timeout при нагрузке, а во-вторых это скучно и не интересно. Тем более, если оставить их достаточно много, в сущности, ничего и не поменяется.

После первого теста мне стало интересно: насколько все может стать плохо, если понапрягать сервер подольше. Ответ:

 

Очень плохо

 

 

Этот тест примерно такой же, но в 3 раза дольше - 9 минут. Однако даже невооруженным глазом видно, что и 1/6 этого времени было достаточно, чтобы у сервера порвало парус без надежды на дальнейшее плаванье. Вот как, в то же время, это выглядело внутри.


 

Максимум отъели сам рабочий процесс и процесс кластера. Но IIS тоже ухватил себе немало, это надо запомнить. В целом по итогам теста: количество обрабатываемых запросов в секунду страшно скакало между 5 и 60, 16 запросов не пришли вообще, среднее время отклика 7 секунд, что даже многие терпеливые отправители могут принять за timeout. Прискорбно. Но пришло время пробовать альтернативные решения.

 

Node.JS

Node.JS - популярная современная платформа для бэка, работающая на движке V8 - том самом, что обрабатывал js 5 минут назад для загрузки этой статьи в вашем браузере на хромиуме. Но мы здесь не ради него самого: я покажу немного js кода дальше, но смысл скорее именно в связи с 1С, а не самой работе с Node. Использовать же для этого всего мы будем старое доброе COM-соединение.

Если кратко и по пунктам:

  1. Есть известный многим, но не всем, Automation Server, он же внешнее соединение, он же V83.ComConnector. С его помощью мы в Node.JS поднимем соединение с базой.
  2. ...
  3. PROFIT

А, ну так, вообще-то, и все. Есть сервер Node.JS, при старте которого мы поднимаем COM. Сервер слушает - COM висит. Как только на порт приходит http-запрос, Node.JS вызывает по соединению функцию с параметром (желательно фоновую). Остается лишь найти способ подружить прогрессивную современную веб платформу работающую на языке для кнопок и формочек с древним хардкорным API для древних нативных виндовых программ.

 

Winax

Единственной, похожей на правду библиотекой, обещающей работу с COM в Node.JS оказалась winax (название в npm) или node-activex (название на GitHub)

https://github.com/durs/node-activex

https://www.npmjs.com/package/winax

 

Если у вас еще нет самого node.js, то, разумеется, необходимо установить его c офф. сайта

https://nodejs.org/en/download

Вместе с ним установится и npm. Для проекта необходимо создать отдельную папку, а в ней файл app.js, где будет код нашего сервера.

Далее, необходимо открыть командную строку в папке проекта и с ее помощью установить/подключить winax. Делается это командой

npm install winax

 

На этом этапе могут возникнуть ошибки. Скорее всего они будут связаны с отсутствием в системе двух необходимых вещей: python и Visual C++ Build tools (или просто Build tools, в зависимости от того, какого года версию вы выберите). Их необходимо установить, но в тексте ошибки будет написано как. Лично у меня проблема возникла только с Build tools, потому что на Windows Server 2012 не работает новый Visual Studio, пришлось брать 17 года.

После установки winax необходимо сформировать простой скрипт сервера, например такой

const http   = require("http");  // Подкючаем стандартную библиотеку http
const winax  = require('winax'); // Подкючаем winax
const url    = require('url');	// Подкючаем стандартную библиотеку url

//Создаем новый объект V83.ComConnector
const con = new ActiveXObject('V83.ComConnector', { activate: true });	

//Выполняем Connect - получаем объект соединения. Далее у него через точку я обращаюсь
//к Обработке(eng. DataProcessors) под названием NodeProcessor
const processor = con.Connect('srvr ="AIONIOTISCORE";Ref ="AioPg"').DataProcessors.NodeProcessor;

//Стандартная оболочка сервера
http.createServer(function(request,response){
	
	//localhost:3000/node
	if(request.url === "/node"){
       
        //Сборка тела post запроса по частям
        let data = "";
        request.on("data", chunk => {
            data += chunk;
        });
        request.on("end", () => {
            console.log(data);
            response.end();
			
            //Вызов функции из модуля менеджера обработки NodeProcessor
            processor["MyCrazyFunction"](data); 

        });
			
	  }
	  
}).listen(3000, "localhost",function(){
    console.log("Start 3000");	
});

 

Данный скрипт вызывает функцию MyCrazyFunction из модуля менеджера обработки NodeProcessor с одним параметром, куда я передаю тело запроса - например JSON. В данном варианте я ничего в ответ не возвращаю. Если нужно вернуть ответ, то 

//Вместо

response.end();
			
//Вызов функции из модуля менеджера обработки NodeProcessor
processor["MyCrazyFunction"](data); 

//Будет

let answer = processor["MyCrazyFunction"](data);
response.end(answer);

 

Вообще с возвращением значений все сложнее. Методы, которые ничего возвращать не должны (у меня это методы телеграм бота, но вообще может быть любой односторонний обмен, например) можно обернуть в фоновое задание - COM-соединение у нас все-таки одно. А вот если нужно что-то вернуть, то одно COM соединение может с этим не справляться. Я лично вижу выход только в создании нескольких COM соединений, сопоставимых примерно по количеству с ожидаемой нагрузкой, а в Node.JS уже использовать их каруселью: запихнуть в массив и вызывать через счетчик по индексу.

 

Сервер запускается командой

node app.js

 

Тестируем

Теперь надо посмотреть, есть ли во всем этом смысл. Мой код сервера не такой как в примере - у меня он вызывает функцию, которая была написана для 1Сного http-сервиса. Вызывает он ее создавая фоновое задание (как http-сервис создает сеансы) и в самом коде сервера больше разной маршрутизации. Короче говоря - логика максимально приближенная к тестируемой в прошлый раз на 1C + IIS.

Короткий тест (3 мин)

 

 

Во-первых: было выполнено больше запросов, а среднее время отклика - немного меньше

 

 

Единственный показатель, превалирующий у 1C+IIS - пиковое количество запросов в секунду. Как видите, обработать больше запросов за то же время это не помогло. Сам же график более плавный: ноду не бросает, время отклика просто растет со временем под нагрузкой.

Так это выглядит внутри:

 

 

Ноде вообще все равно - 75% ресурсов за процессами 1С. Единственная проблема - количество фоновых. Их выходит все равно больше, чем было бы http-сеансов, из-за чего увеличивается нагрузка от процесса кластера.

 

Длинный тест (9 минут)

 

 

Уже по графику короткого теста было видно, что Node.js ведет себя стабильнее и на длинной дистанции это скажется еще сильнее. Однако тут все, конечно, тоже не идеально (помним про слабое железо, и тем не менее)

 

 

Обработанных запросов больше, среднее время ответа меньше аж в 2 раза и нет ни одного необработанного запроса. Epic Win. Внутри все было примерно похоже на коротки тест: диспетчер загрузку ЦП > 100% все равно не покажет.

Казалось бы, можно уже и подводить итоги, рассказывать про плюсы и минусы. Но у меня припасен еще один козырь в рукаве. Внимательный читатель уже даже мог заметить этот непонятно чем занимающийся процесс IIS в скрине короткого теста для Node.JS. А кто-то даже мог справедливо указать на тот факт, что IIS, так то, публикует все свое добро в интернет, пока нода страдает фигней на своем localhost:3000. И это правда.

Дело в том, что пока это все было в рамках максимально сомнительного эксперимента, мне не очень хотелось ломать свой IIS ради другого поставщика reverse-proxy способного выкинуть мой localhost:3000 на внешний IP. Поэтому я, не мудрствуя лукаво, сделал это через тот же самый IIS. Но с учетом того, что даже так Node в моем случае оказался быстрее, грех было не попробовать его в полную силу

 

Nginx 

Nginx - "простой, быстрый и надёжный сервер, не перегруженный функциями". Инфографика с хабра, которая говорит лучше любых слов

 

 

Знающие люди мне, конечно, сейчас расскажут, что nginx тоже не панацея (это правда), но забегу немного вперед - с ним действительно (и ожидаемо) стало быстрее.

Поставить и настроить nginx, хотя бы на том ламерском уровне, который мне сегодня необходим, достаточно просто.

Нужно скачать zip с офф. сайта и распаковать

https://nginx.org/ru/download.html

Зайти в папку conf и поправить nginx.conf под свои нужды. В моем случае это был только пункт server внутри пункта http

	server { 
 
	listen 443 ssl; 
	server_name api.athenaeum.digital; 
	ssl_certificate ../ssl/domain.tld.chained.crt;
	ssl_certificate_key ../ssl/domain.tld.key;

	  ssl_protocols TLSv1.2;
	  ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
	  ssl_prefer_server_ciphers on;
  
	location /node 
	{ proxy_pass http://localhost:3000; 
	proxy_http_version 1.1; 
	proxy_set_header Upgrade $http_upgrade; 
	proxy_set_header Connection 'upgrade'; 
	proxy_set_header Host $host; 
	proxy_cache_bypass $http_upgrade; } 
	
 } 

Очень простой прокси с api.athenaeum.digital на localhost:3000. Запускаем и тестируем. Я пропустил в данном случае 3-х минутное тестирование и сразу запустил на 9

 

 

Выглядит неплохо.

 

 

Из всех трех тестов 1С + COM + Node.JS с nginx в качестве реверс прокси показали самый лучший результат: самое большое количество обработанных запросов за 9 минут, самое низкое среднее время отклика.

 

Итого

Конечно, эти тесты не абсолютны: например, Apache, IIS и nginx по разному использую мощные многоядерные процессоры. Но тут уже видно, что у этого есть потенциал. В качестве вывода предлагаю разобрать, где Node.js в связке с 1С можно сказать "да", а где - "нет":

Нет:

- Он не может полноценно заменить Apache и IIS для 1С: веб клиент никто не отменял + дополнительно нужно разбираться в js

- Не совсем понятен оптимальный способ возвращения значений в ответ на запрос: в то время, как 1С поднимает столько сеансов сколько нужно, однопоточный node.js требует правильной работы с неблокирующими вызовами и Event Loop, а для поднятия дополнительных COM соединений с 1С вообще нужно придумывать отдельный механизм (который при любом раскладе становится ничем не лучше сервисов в плане лицензий)

- Сложность в отладке внешних соединений, через которые все работает.

- Необходимость отдельно следить за состоянием сервера, перезапускать после обновления базы для поднятия нового соединения.

Да:

+ Хорошее быстродействие, производительность и стабильность

+ Простота в настройке и легковесность: node.js и nginx довольно легкие по ресурсам, а их настройка на базовом уровне достаточно проста.

+ При необходимости записи сразу в несколько мест (помимо 1С), сделать это проще и производительнее на стороне node.js, чем принимать http-сервисами в 1С, а затем средствами 1С передавать далее. Туда же можно и скинуть начальную обработку данных.

+ На node.js можно использовать WebSocket (наверняка и еще много других приколов, нереализуемых средствами 1С)

 

Думаю, идеальное место применения - односторонний обмен, когда большой массив данных необходимо передать в 1С по http. Хотя это тоже поверхностный взгляд. Кто знает, может и пугающий меня возврат ответа для знающего человека окажется пустяковой задачей? Пишите в комментариях свои мысли. Спасибо за внимание!

P.S Реализация с примером реального использования уже есть/скоро будет в репозитории Two-Digit Athenaeum (статья на Инфостарте). А еще у меня, кстати, есть и другие статьи ;)

 

 

 Мой GitHub:     https://gitub.com/Bayselonarrend 
 Лицензия MIT:   https://mit-license.org

 

web http-сервисы http node.js node js интеграция обмен

См. также.

Сайты и интернет-магазины WEB-интеграция Системный администратор Программист Пользователь Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме.

36000 руб.

03.08.2020    16430    15    18    

15

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс 24. Разработка имеет двухстороннюю синхронизацию 1С и Bitrix24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (платформа начиная с 8.3.23). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    18676    10    15    

16

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    13189    35    8    

14

Прайсы WEB-интеграция Ценообразование, анализ цен Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Автомобили, автосервисы Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Программа с заданным интервалом времени (или по ручной команде) скачивает файлы (например, прайс-листы поставщиков) из различных источников: письма электронной почты, FTP или HTTP-адреса, и сохраняет их в каталог упорядоченной структуры. При этом извлекает файлы из архивов, может переименовывать файлы и менять их формат (csv, xls, txt). Можно настроить выгрузку обработанных файлов на сайт (через FTP-подключение). Программа будет полезна компаниям, у которых есть большое количество поставщиков и/или прайс-листы поставщиков обновляются часто (необязательно прайс-листы, файлы могут быть любого назначения). Собранные таким образом актуальные версии прайс-листов можно выгрузить с помощью программы себе на сайт (или на любой FTP-сервер) или выполнить другие необходимые задачи.

25200 руб.

28.05.2015    86409    26    51    

50
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. dsdred 3431 14.12.23 11:51 Сейчас в теме
Спасибо за статью, плюс поставил.
Сам использую node.js

Но COM... Не то, что нужно.
ya.Avoronov; awk; sikuda; +3 Ответить
2. bayselonarrend 1542 14.12.23 11:56 Сейчас в теме
(1)Спасибо. COM, конечно, и изначально выглядел сомнительно, но по итогу все равно оказался производительнее. Честно говоря, не знаю, каким еще способом их можно было бы связать
10. sikuda 676 14.12.23 12:23 Сейчас в теме
(1) Я тоже всегда за тестирование и проверку новых технологий, но COM в 2023 году это ноунсес ;)
Автору эксперементировать с https://its.1c.ru/db/v8324doc#bookmark:dev:TI000001855
21. bayselonarrend 1542 14.12.23 13:34 Сейчас в теме
(10)Я использовал переиспользование сеансов в тесте http-сервисов на IIS
3. dsdred 3431 14.12.23 12:01 Сейчас в теме
(2) У меня есть мысль попробовать Сервисы интеграции.
Ну а если совсем хардкорно то прямые запросы к SQL, но тут тогда нужен слой с проверкой авторизации и выдачи JWT токенов на короткое время.
bayselonarrend; +1 Ответить
4. bayselonarrend 1542 14.12.23 12:05 Сейчас в теме
(3)Не очень много знаю про работу сервисов интеграции, но если их можно подвязать - будет хороший шаг вперед (разве что недоступный на старых версиях платформы). Что касается запросов, то теряется возможность обработки на стороне 1С. Идея была именно в альтернативе http-сервисам, где в момент прихода данных на сервер, 1С узнает об этом, получает данные и выполняет свою логику.
6. dsdred 3431 14.12.23 12:20 Сейчас в теме
(4)
Не очень много знаю про работу сервисов интеграции

По большому счету они появились под 1СШину, но я хочу с ними работать без Шины, надо просто повторить все то что делает Шина и 1С при взаимодействии друг с другом.

Что касается запросов, то теряется возможность обработки на стороне 1С. Идея была именно в альтернативе http-сервисам, где в момент прихода данных на сервер, 1С узнает об этом, получает данные и выполняет свою логику.

Что есть запросы в http?

0 Тип запроса (Get, Post...)
1 Заголовки запроса
2 Параметры запроса
3 Тело запроса

Соответственно если на стороне 1с вы все грамотро сделаете то у Вас получится примерно следующее
1 Получаем запрос и формируем структуру из перечисленных выше данных.

2 Рисуете единую точку входа с методом обработки структуры из пункта 1.

И тут вы получаете уже универсальное решение не привязанное к транспорту.
И вам уже пофиг http-сервисы ли это или что-то другое повторяющее структуру.
8. bayselonarrend 1542 14.12.23 12:22 Сейчас в теме
(6)
Что есть запросы в http?

0 Тип запроса (Get, Post...)
1 Заголовки запроса
2 Параметры запроса
3 Тело запроса

Соответственно если на стороне 1с вы все грамотро сделаете то у Вас получится примерно следующее
1 Получаем запрос и формируем структуру из перечисленных выше данных.


2 Рисуете единую точку входа с методом обработки структуры из пункта 1.

И тут вы получаете уже универсальное решение не привязанное к транспорту.
Показать


Я имел ввиду SQL запросы. Как стриггерить выполнение функции в 1С после записи данных?
9. dsdred 3431 14.12.23 12:23 Сейчас в теме
(8)Я поэтому и говорю это хардкор ))
5. bayselonarrend 1542 14.12.23 12:18 Сейчас в теме
(3)А сервисы интеграции, кстати, это не реализация AMQP? Мне почему то так казалось
7. dsdred 3431 14.12.23 12:21 Сейчас в теме
11. bayselonarrend 1542 14.12.23 12:29 Сейчас в теме
(7)Вообще тогда можно попробовать взять внешнюю компоненту, вроде PinkRabbitMQ, которая для обмена с RMQ и подвязать к node.js, если он сам хорошо работает по MQ
13. dsdred 3431 14.12.23 12:30 Сейчас в теме
50. gybson 16.12.23 10:06 Сейчас в теме
(11)Rabbit и сам по http довольно сносно работает
51. bayselonarrend 1542 16.12.23 11:18 Сейчас в теме
(50) Не найду уже где, но вроде где-то на сайте RabbitMQ было написано, что использовать http для обмена нельзя/не рекомендуется, а нужен он для того, чтобы сообщать своему приложению, когда запускать обмен по стандартному протоколу.

Плюс, как уже было говорено, никто не мешает и по AMQP обмениваться из 1С, проблема скорее в необходимости постоянных опросов
52. gybson 17.12.23 12:39 Сейчас в теме
(51) да не, проблема в том, что 1С пока не очень здорово работает с AMPQ

а то, что асинхронный обмен не является синхронным, это не проблема и её не надо решать =)
12. bayselonarrend 1542 14.12.23 12:29 Сейчас в теме
(7)Насколько я помню, сервисы интеграции все равно надо в цикле пинать постоянно, чтобы они новые сообщения получали, так что разница не велика
14. dsdred 3431 14.12.23 12:42 Сейчас в теме
(12) Все происходит на уровне платформы.
В сервисах интеграции создается Новый сервис например "IPrettyS"
В нем создается канал на "Получение" - "ReadingChannel"
И канал на "Отправку" - "SendingChannel"

Создается регламент который раз в 2 минуты работает:
Код:
ВключенПривилегированныйРежим = Ложь;
Если Не ПривилегированныйРежим() Тогда
ВключенПривилегированныйРежим = Истина;
УстановитьПривилегированныйРежим(ВключенПривилегированныйРежим);
КонецЕсли;

СервисыИнтеграции.ВыполнитьОбработку();

Если ВключенПривилегированныйРежим Тогда
ВключенПривилегированныйРежим = Ложь;
УстановитьПривилегированныйРежим(ВключенПривилегированныйРежим);
КонецЕсли;


По сути эта команда запускает платформенный механизм обработки входящих и исходящих сообщений и работает в течении 2 минут.
15. maksa2005 536 14.12.23 13:04 Сейчас в теме
Все таки appach золотая середина между IIS и Nginx.
Прост в обслуживанию (привет тебе IIS)
16. bayselonarrend 1542 14.12.23 13:13 Сейчас в теме
(15)IIS сложен в обслуживании?
17. maksa2005 536 14.12.23 13:14 Сейчас в теме
(16) вечно с ним были проблемы, то ошибки авторизации, то что-то не так.
Вывод: везде поднял appach и проблем нет.
Alex_Iz; sandr13; +2 Ответить
18. maksa2005 536 14.12.23 13:15 Сейчас в теме
(16)Самая "бесячая" в ней
Ошибка HTTP 500.0 - Internal Server Error после публикации базы 1С на веб-сервере IIS
Прикрепленные файлы:
19. bayselonarrend 1542 14.12.23 13:20 Сейчас в теме
(18)Никогда не сталкивался, если честно (не то чтобы и много работал с ним, на самом деле). Наоборот видел на Инфостарте недавно тред наподобие "Подскажите, почему через n-времени начинают тормозить сеансы на Apache под Windows? Ладно, поставил IIS, все стало нормально"
20. maksa2005 536 14.12.23 13:22 Сейчас в теме
(19)как бы было такое, но не получилось выявить почему: просто отваливался appach на конкретной базе после множество её публикации на web. перезагрузка rhost спасала, но это только вне присутствия пользователя)
bayselonarrend; +1 Ответить
53. zhenyat 6 18.12.23 13:45 Сейчас в теме
(18)Потому что для публикации БД надо явно запускать конфигуратор от администратора
55. maksa2005 536 18.12.23 14:13 Сейчас в теме
(53) а вот с appachem такого костыля нет)
22. wtlz 264 14.12.23 15:18 Сейчас в теме
23. bayselonarrend 1542 14.12.23 15:34 Сейчас в теме
(22) Ну, в этом нет ничего удивительного, что я такого еще не видел) Хотя вообще, если я все правильно понял, это не совсем то. Я в статье рассматриваю способы, как получить данные по http и закинуть их в какую-нибудь функцию обычной 1С базы. А в этом решении входящие данные обрабатываются SQL скриптами, просто в терминах метаданных как в запросах 1С. Т.е. если мне нужна обработка сложнее, чем доступна средствами SQL, или, например, необходимо сформировать не ответ, а новый запрос, то ничего не получится.

Короче, это уже гораздо дальше непосредственно от 1С
24. MarryJane 31 14.12.23 17:26 Сейчас в теме
Вопрос: а как можно еще запустить 1С без ком объекта. (wsisapi.dll как то же создает сеанс подключения)
25. bayselonarrend 1542 14.12.23 19:06 Сейчас в теме
(24) ISAPI - api IIS для связи со сторонними приложениями (есть реализация для Apache). Через этот api 1С связывается с веб-сервером. Другие сервера его не поддерживают
26. cheshirshik 66 14.12.23 22:07 Сейчас в теме
Статья интересная. + на инфостате и в карму. Но вот мысли:

* На счет приема данных. Вот честно. У меня напрашивается все буфер обмена. Как бы я сделал, при большой нагрузке, если надо только забирать данные с НТТР сервиса. Я бы сделал буферный обмен. Пусть некий пул (сайт с Мускулом) накапливает данные от пользователей, а 1С время от времени запрашивает данные с сервера и загружает к себе. Я бы курил в эту сторону.
* СОМ в 2023 году? Серьезно? Не обижайтесь, но использовать СОМ это моветон. Имхо. Лучше АПИ и НТТР запросы. Будет гарантированно работать и в винде и на линуксе.
dkoder; itmind; +2 Ответить
27. bayselonarrend 1542 14.12.23 22:25 Сейчас в теме
(26)
Имхо. Лучше АПИ и НТТР запросы. Будет гарантированно работать и в винде и на линуксе.


Ну нету у 1С других механизмов связи со сторонним софтом - я же не буду получать http на node.js чтобы потом передавать на http-сервисы. Моветон, не моветон - в моем случае так работает быстрее.

Может я не очень понимаю, что вы имеете ввиду под АПИ и HTTP, но если это про http-сервисы, то эта статья как раз о том, что даже долбаный допотопный COM с более производительным решением в качестве сервера на конце работает быстрее и стабильнее, чем эти самые сервисы
28. cheshirshik 66 14.12.23 22:29 Сейчас в теме
(27)
Может я не очень понимаю, что вы имеете ввиду под АПИ и HTTP, но если это про http-сервисы, то эта статья как раз о том, что даже долбаный допотопный COM с более производительным решением в качестве сервера на конце работает быстрее и стабильнее, чем эти самые сервисы


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


(27)
Ну нету у 1С других механизмов связи со сторонним софтом - я же не буду получать http на node.js чтобы потом передавать на http-сервисы. Моветон, не моветон - в моем случае так работает быстрее.


Да. Я бы шел в эту сторону. Есть же всякие там кафки, либо писать свой веб сервис, который будет накапливать в своем СУБД запросы от пользователей, а потом передавать их в 1С.
31. bayselonarrend 1542 14.12.23 22:38 Сейчас в теме
(28)
Как только мы телепортируемся в мир сервера на линукс, там это решение вообще работать не будет.


Да, это виндовое решение.


(28)
Да. Я бы шел в эту сторону. Есть же всякие там кафки, либо писать свой веб сервис, который будет накапливать в своем СУБД запросы от пользователей, а потом передавать их в 1С.


Не очень понимаю что это за сторона - кафка работет не по http. Писать запросы в субд от пользователей можно, но мне кажется сомнительным, что так будет быстрее. Какое бы там ни было COM соединение, процесс, при котором нужна запись в одну базу, потом чтение этого в 1С (как, кстати, его читать? Опять бесконечно гонять фоновое?) и уже только после этого обработка на стороне 1С, будет совсем не легким по ресурсам и скорости. Тут же просто все время висит сеанс, благодаря чему можно моментально передать полученную информацию в обработку, банально вызвав нужную функцию с параметром.
34. cheshirshik 66 14.12.23 23:10 Сейчас в теме
(31)
Не очень понимаю что это за сторона - кафка работет не по http.


Если честно, то я с кафкой лично не работал. Знаю, что это брокер сообщений, который принимает сообщения с разных сервисов и отдает их. Это его основная цель и функция. У кафки есть АПИ, через который 1С по НТТР запросу может получить данные или отдать. Я так понимаю, что там все уже достаточно хорошо оптимизировано, чтобы получать и отдавать большие массивы данных.
35. bayselonarrend 1542 14.12.23 23:26 Сейчас в теме
(34)Это уже обсуждали выше, только для RabbitMQ. Брокер сообщений это хорошо, но Http соединение 1С это тоже не быстрая фигня. Подход с опросом кафки по http, если мы говорим о скорости сопоставимой с http-сервисами, будет требовать как минимум раз в секунду делать http запрос. Еще можно рассматривать работу с брокерами по их нативным протоколам (через сервисы интеграции), где проблема с циклическим вызовом тоже до конца не решена, но хоть сам обмен быстрее, а отправка http запроса раз в секунду (по хорошему, надо было бы и чаще) из 1С, я думаю, не будет производительнее. Тут можно поспорить, но я лично вообще крайне скептически отношусь ко всем подобным процессам, которые построены на принципе бесконечного стучания в циклическом фоновом задании в ожидании данных.
29. bayselonarrend 1542 14.12.23 22:32 Сейчас в теме
(26)
а 1С время от времени запрашивает данные с сервера и загружает к себе. Я бы курил в эту сторону.


Это хороший вариант для обмена, но мне он не подходит. Причина поиска именно подобия сервиса заключается в том, что я хочу как раз иметь механизм, который будет сразу откликаться на входящий запрос с минимальной задержкой. Большая нагрузка тут скорее не просто большой объем данных, а именно большое количество одиночных небольших пакетов, приходящих за короткий промежуток времени и требующих обработки сразу.
30. cheshirshik 66 14.12.23 22:35 Сейчас в теме
(29)
...который будет сразу откликаться на входящий запрос с минимальной задержкой


При всем уважении, это уже скорее не к 1С, а к специализированным веб сервисам. 1С тут уже смотрится, как костыль.
dkoder; sandr13; +2 Ответить
32. bayselonarrend 1542 14.12.23 22:42 Сейчас в теме
(30) Так никто и не спорит, что это костыль. Однако, это не отменяет того факта, что http-серисы используются в 1С, в том числе и для тяжелого обмена. Смысл этого метода

1. Он позволяет почти ничего не менять в 1С при переходе от http-сервисов - надо просто вынести ту же функцию http-сервиса в модуль и сделать экспортной
2. node.js + nginx очень просто и быстро поставить. Там два файла по 100 строк, которые можно написать за вечер по гайдам

При этом оно вот тупо в чистых цифрах работает быстрее
33. bayselonarrend 1542 14.12.23 22:45 Сейчас в теме
(30) Понятно, что если бы такое решение требовало миллион телодвижений и глобальных изменений в инфраструктуре смысла бы в этом никакого не было. Но если нужно выгрузить гигабайты данных по http и в случае http-сервиса это работает медленно и нестабильно, то можно вот так
36. booksfill 15.12.23 11:47 Сейчас в теме
Просто мысли вслух, я тут не спец.

COM соединение - это медленно, не кросплатформенно. Второе сейчас крайне актуально.

RabbitMQ and so on (как про это выше написали) - Это быстро, и для 1С есть нативные (даже бесплатные) компоненты, не требующих медленных http запросов к очереди.

Плюс гарантия того, что ваши сообщения от node.js не потеряются.

Плюс освобождаются ресурсы самого node.js, который не возится с COM, а просто бросает что-то в быструю очередь.

Вообще, без очереди теряется смысл быстро получать запросы на node.js - что в этом толку, если 1С не будет успевать их обрабатывать?

Обычно когда возникает проблема обработки множества запросов, то это ответственное приложение. И все равно придется добавлять балансировку нагрузки - возможность отправки в несколько очередей в этом сильно поможет.
Я уж не говорю про то, что разные очереди могут иметь разный приоритет.

Имея единый брокер сообщений, можно поднимать несколько экземпляров node.js, обеспечивая дополнительную отказоустойчивость и распределение нагрузки.

Упоминалось ("однопоточный node.js требует правильной работы с неблокирующими вызовами"), что node.js не поддерживает многопоточность,.
Если ничего не путаю (и, вообще, верно понял к чему эта фраза относилась), то это не так, см. worker-threads.
37. bayselonarrend 1542 15.12.23 12:33 Сейчас в теме
(36)
COM соединение - это медленно, не кросплатформенно. Второе сейчас крайне актуально.


Это актуально в том плане, что решение нельзя использовать для Linux. В рамках одного проекта никто не скачет каждый день/неделю/месяц с винды на линукс и обратно. Если переход на линукс не предполагается, то проблемы никакой нет

RabbitMQ and so on (как про это выше написали) - Это быстро, и для 1С есть нативные (даже бесплатные) компоненты, не требующих медленных http запросов к очереди.


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

Плюс освобождаются ресурсы самого node.js, который не возится с COM, а просто бросает что-то в быструю очередь.


Никто не знает, насколько действительно COM с использованием сторонней библиотеки winax проседает и с чем он там возится. Тем не менее, это единственный доступный способ обращаться напрямую к методам конфигурации и держать одно постоянное соединение, не поднимая его каждый раз, даже если оно не очень быстрое. Если вообще абстрагироваться от способо связи - проблемы производительностью на больших нагрузках происходят не столько за счет быстродействия обмена, сколько из-за того, что процессор не успевает выполнять обработку. И node.js с com surrogate требуют меньше ресурсов для работы, чем IIS/Apache и нативные сервисы, даже с учетом того, что ISAPI точно быстрее чем COM

Вообще, без очереди теряется смысл быстро получать запросы на node.js - что в этом толку, если 1С не будет успевать их обрабатывать?


Есть инфографика выше. На большой нагрузке IIS с сервисами потеряли пакеты, а node.js с COM нет. Если мы говорим уже про действительно большие нагрузки и сравниваем node + com не с http-сервисами, а с node + брокер, то, конечно, второе надежнее, но:
1. Пакеты могут не доходить даже до брокера. Брокер связывается с node более быстрым и оптимальным способом, но все равно они не одно целое
2. Если 1С не будет их успевать обработать, то брокер просто сохранит их и они не пропадут. Но если на другой стороне ждут ответа, то там все равно будет timeout

Имея единый брокер сообщений, можно поднимать несколько экземпляров node.js, обеспечивая дополнительную отказоустойчивость и распределение нагрузки.


Если мы остаемся в области 1С, то 90% нагрузки все равно в 1С и такой оптимизации там скорее всего не понадобится - бутылочное горлышко все равно желтое

worker-threads


Это для продвинутых юзеров) А мое решение все равно использует одно COM соединение, поэтому тема не раскрыта.
По умолчанию при построении простого сервера без дополнительной магии nodejs работает с одним потоком через Event Loop


Что я хочу сказать - я задумывал эту статью не совсем так, как ее понимают) Идея не в том, что я нашел какой-то волшебный механизм для обмена данными. Идея в том, что в 1С есть htpp-сервисы - вот такой механизм есть в 1С. http-сервисы это не брокер сообщений и не буфер, для его работы не требуется постоянно запрашивать новые данные у кого-то и он не требует работы с внешними компонентами. Там просто есть метод, который принимает один параметр ровно тогда, когда на web-сервер приходит запрос, а потом дает ответ. И этот механизм не очень быстрый и не очень понятно, что у него внутри. И в этой статье я хотел показать: есть вот такое решение, которое работает точно так же - в момент прихода на веб-сервер запроса вызывает метод в 1С. Это выглядит сомнительно из-за COM соединения, я это понимаю, но для этого я провел стресс тесты и вот показываю цифры. Все) Конечно есть много других способов, с тем же брокером, например. Но он работает не так, по другим принципам и требует для реализации гораздо больше знаний. Если у вас есть готовые http-сервисы и они должны быть именно что http-сервисами - вот это самый быстрый способ практически ничего не меняя в 1С сделать их немного быстрее (во всяком случае, я так это увидел по результатам тестов)
38. MarryJane 31 15.12.23 16:26 Сейчас в теме
Может я чего то не понимаю, но по-хорошему (IIS или Апача) через DLL wsisapi запускает сеанс на сервере 1С, разве это не так
40. bayselonarrend 1542 15.12.23 17:00 Сейчас в теме
(38)А кто ж его знает, что у нее внутри. wsisapi нужен для работы по ISAPI, который поддерживается в Apache и IIS. Тут либо эта часть запускает сеансы, когда веб-сервер подает сигнал, либо перенаправляет какой-нибудь другой части, которая за это отвечает (лицензирование там, кластер). В любом случае, в других серверах (или никаком софте в принципе?) ISAPI не используется, следовательно и запускать сеансы через него никто не умеет
39. MarryJane 31 15.12.23 16:53 Сейчас в теме
Пардон Апача использует wsap24.dll(wsap22.dll)
41. alex_bob 246 15.12.23 17:10 Сейчас в теме
1. Кроме IIS и Apache с некоторых пор есть Автономный сервер.
2. Для создания пула COM-соединений в винде есть COM+.
42. bayselonarrend 1542 15.12.23 17:18 Сейчас в теме
(41)Если честно, не разбирался с автономным, только слышал. Если работаете с ним, было бы очень интересно узнать, как там вообще все устроено: SSL сертификаты, маршрутизация и пр. Или под него еще что-то надо, что будет за это отвечать? Просто инфы реально немного

Второе, на самом деле, еще интереснее) Можно управлять пулом COM-соединений с 1С?
43. MarryJane 31 15.12.23 17:19 Сейчас в теме
И при том что если у вас не серверная база, то ИИС или Апача запустит сеанс на файловой базе
44. alex_bob 246 15.12.23 17:39 Сейчас в теме
(42) Все равно нужен nginx.
По второму вопросу - тынц
bayselonarrend; +1 Ответить
45. bayselonarrend 1542 15.12.23 19:00 Сейчас в теме
(44)
По второму вопросу - тынц

Ого, вот это для данного способа выглядит очень неплохо! Не видел раньше, спасибо
46. dreamadv 156 15.12.23 23:34 Сейчас в теме
(45) Да это ком пулл прослойка. Использовал такую с 7.7 реализованные через нее аля HTTP сервисы работали быстрее чем сервисы в 8-ке.
47. bayselonarrend 1542 15.12.23 23:55 Сейчас в теме
(46)Можете, пожалуйста, примерно описать принцип? Написано, что можно указывать максимальное количество одновременных подключений и таймаут, при котором они закрываются. Просто я у себя держу постоянно поднятое подключение - создаю COM объект 1 раз при старте сервера node.js, а в том варианте каждый раз во время запроса создается новый COM объект, но если есть уже созданный и доступный в пуле, то берется он. При этом получается, что если запросов долго не было, то при следующем запросе новый COM объект создастся (так как в пуле ничего не будет) и будет доступен некоторое время для переиспользования?
49. dreamadv 156 16.12.23 00:00 Сейчас в теме
(47) Вам нужно настроить ком+ приложение, а у себя в NodeJS создавать уже ком объект не напрямую 1С, а объект ком+ приложения. Все таймауты через сколько процесс умирает настраивается в ком+, там же и сколько процессов можно максимально создать.
bayselonarrend; +1 Ответить
54. zhenyat 6 18.12.23 13:50 Сейчас в теме
(46)А можете рассказать про это подробнее (про 7.7)?
56. dreamadv 156 18.12.23 23:46 Сейчас в теме
(54) Через использование такой COM прослойки можно сделать веб сервис на 1С 7.7 который будет отвечать на запросы быстрее чем веб-сервис 8-й 1С. Нужно настроить ком+ приложение прокси dll, apache с php, скрипт на php. С созданием ком объекта прослойки и вызовом функции 1С. Подробнее тут: https://www.1cpp.ru/forum/YaBB.pl?num=1179245025
Правильная dll в сообщении Ответ #71.

Есть до сих пор работающая реализация в продакшене.
48. dreamadv 156 15.12.23 23:58 Сейчас в теме
Мы много экспериментировали с сервисами по ощущениям apache 2.4 x64 работает быстрее всего. Так же очень сильно влияет на производительность включенный дебаг у сервиса и сервера соответственно. Вообще самым идеальным вариантом было бы прикрутить бы wsap24.dll к NGINX каким-то образом. Какая-то обвязка ввиде FastCGI сервера который использует wsap24.dll
bayselonarrend; +1 Ответить
57. dmarenin 351 29.12.23 14:50 Сейчас в теме
(48) я смотрел в эту сторону если пореверсить обёртки (расширения иис/апача) там тупо интерфейсы (прокси фактически) дальше по com объекту все, прямых отображений нет. Отсюда и просадка
dreamadv; +1 Ответить
58. dmarenin 351 29.12.23 14:51 Сейчас в теме
(48) в теории сделать можно нжинкс умеет в расширения, но это не даст рост производительности, так как проблемы там ещё раз не на этом уровне
Оставьте свое сообщение