IIS? Apache? Node.js? Или может быть Go?

Предисловие

Статья вдохновлена публикацией IIS? Apache? А может быть, Node.js?. Рекомендую сначала прочитать её, а потом уже мой "отчет об эксперименте".

Проблема

Наткнувшись недавно на статью IIS? Apache? А может быть, Node.js? я узнал о новом способе обработки HTTP запросов, о котором я даже никогда не задумывался. Суть была в том, что бы использовать в качестве обработчика HTTP запросов не 1С, а Node JS, в коде которого создается COM соединение с 1С которое выполняет в себе обработку запроса. Идея прекрасна, так как в таком раскладе можно использовать NGINX, который гораздо лучше ведет себя в нагрузках, да и в целом он более современный и является де-факто в современном мире WEB. 

В комментариях основной претензией к такому способу стало использование COM объекта, так как этот механизм стар и уже изжил своё (с чем я не могу не согласится). И я задумался о том, как еще можно обрабатывать HTTP запросы в 1С не используя HTTP сервисы.

Идея

Мне пришла в голову идея: что если создать сервис, который будет принимать на себя HTTP запросы и иметь HTTP интерфейс для обработки этих запросов.

Алгоритм следующий:

1. Запрос, например /test попадает в Сервис обработки запросов (далее СОЗ) и ждёт, когда его смогут обработать.
2. В 1С запущен фоновый обработчик (или обработчики, что бы увеличить количество потоков обработки), который в бесконечном цикле делает long-polling запрос к СОЗ (например /request) и ждёт от него запрос для обработки.
3. 1С получает в ответ на /request запрос для обработки с какими то данными, что-то с ними делает и снова отправляет HTTP запрос в СОЗ (например /response) с результатом обработки.
4. СОЗ получает результат обработки и отвечает клиенту.

Реализация

Для написания простейшего СОЗ я выбрал Go так как он, по моему мнению, лучше всего подходит для этих целей. Он "простой", быстрый, надежный и многие позиционируют его как язык для написания микросервисов, коим наш СОЗ и является.

Сервис написан в стиле "простыня" или "на коленке" и не является "production ready" решением. Если хотите использовать его для себя, то необходимо внести доработки: сделать хоть какую то модульность, предусмотреть обработку ошибок, логирование и т.д.

package main

import (
	"io"
	"net/http"
	"strconv"
	"sync"
)

type ReqContainer struct {
	req  *http.Request
	w    http.ResponseWriter
	done chan struct{}
}

type ResQueue struct {
	m      sync.Mutex
	lastId uint64
	q      map[string]*ReqContainer
}

func (rq *ResQueue) Push(reqC *ReqContainer) string {
	rq.m.Lock()
	defer rq.m.Unlock()

	rq.lastId++
	id := strconv.FormatUint(rq.lastId, 36)

	rq.q[id] = reqC

	return id
}

func (rq *ResQueue) Pop(id string) *ReqContainer {
	rq.m.Lock()
	defer rq.m.Unlock()

	reqC := rq.q[id]
	delete(rq.q, id)

	return reqC
}

var reqQueue = make(chan *ReqContainer)
var resQueue = ResQueue{
	q: make(map[string]*ReqContainer),
}

func anyRequest(w http.ResponseWriter, req *http.Request) {
	reqC := ReqContainer{
		req:  req,
		w:    w,
		done: make(chan struct{}),
	}

	select {
	case <-req.Context().Done():
	case reqQueue <- &reqC:
	}

	select {
	case <-req.Context().Done():
	case <-reqC.done:
	}
}

func request(w http.ResponseWriter, req *http.Request) {
	select {
	case <-req.Context().Done():
	case reqC := <-reqQueue:
		for key, headers := range reqC.req.Header {
			for _, value := range headers {
				w.Header().Add(key, value)
			}
		}

		id := resQueue.Push(reqC)
		w.Header().Add("x-req-id", string(id))
		w.Header().Add("x-req-url", reqC.req.RequestURI)

		defer reqC.req.Body.Close()
		body, _ := io.ReadAll(reqC.req.Body)
		w.Write(body)
	}
}

func response(w http.ResponseWriter, req *http.Request) {
	id := req.Header.Get("x-req-id")
	reqC := resQueue.Pop(id)

	select {
	case <-req.Context().Done():
	default:
		for key, headers := range req.Header {
			for _, value := range headers {
				reqC.w.Header().Add(key, value)
			}
		}

		defer req.Body.Close()
		body, _ := io.ReadAll(req.Body)
		reqC.w.Write(body)
		reqC.done <- struct{}{}
	}
}

func main() {
	http.HandleFunc("/", anyRequest)
	http.HandleFunc("/request", request)
	http.HandleFunc("/response", response)
	http.ListenAndServe(":8090", nil)
}

На стороне 1С реализация тоже максимально простая:

Процедура ОбработчикЗапросов() Экспорт
	
	Соединение = Новый HTTPСоединение("localhost", 8090,,,, 60);	
	
	Пока Истина Цикл
		Попытка
			Запрос = Новый HTTPЗапрос("/request");
			Ответ = Соединение.Получить(Запрос);
		Исключение
			Продолжить;
		КонецПопытки;
		
		ИДЗапроса = Ответ.Заголовки.Получить("X-Req-Id");
		URL = Ответ.Заголовки.Получить("X-Req-Url");
		ПроизвольнаяСтрока = Ответ.ПолучитьТелоКакСтроку();
		
		Тело = API.Тест(ПроизвольнаяСтрока);
		
		Запрос = Новый HTTPЗапрос("/response");
		Запрос.Заголовки.Вставить("X-Req-Id", ИДЗапроса);
		Запрос.Заголовки.Вставить("Content-Type", "application/json");
		Запрос.УстановитьТелоИзСтроки(Тело);
		Соединение.ОтправитьДляОбработки(Запрос);	
	КонецЦикла;
	
КонецПроцедуры

#Область ПрограммныйИнтерфейс

Функция Тест(ПроизвольнаяСтрока = "") Экспорт
	
	N = Константы.N.Получить();
	
	НачалоЗамера = ТекущаяУниверсальнаяДатаВМиллисекундах();
	Результат = Факториал(N) / Факториал(N + 1);
	ВремяВыполнения = ТекущаяУниверсальнаяДатаВМиллисекундах() - НачалоЗамера;
	
	Данные = Новый Структура;
	Данные.Вставить("comment", ПроизвольнаяСтрока);
	Данные.Вставить("result", Окр(Результат, 10));
	Данные.Вставить("time_result", ВремяВыполнения);
	
	Возврат ВJSON(Данные);
	
КонецФункции

#КонецОбласти


#Область СлужебныеПроцедурыИФункции

Функция Факториал(N)
	 
	Если N <= 2 Тогда
		Возврат N;
	КонецЕсли;
	
	Результат = 2;
	
	Для Итератор = 3 По N Цикл
		Результат = Результат * Итератор;
	КонецЦикла;
	
	Возврат Результат;
	
КонецФункции

Функция ВJSON(Данные)

	Запись = Новый ЗаписьJSON;
	Запись.УстановитьСтроку();
	
	ЗаписатьJSON(Запись, Данные);
	
	Возврат Запись.Закрыть();
	
КонецФункции

#КонецОбласти

API.Тест(...) делает довольно простую работу: немного математики, преобразование в JSON, один запрос константы. Но в нагрузке способен заставить поработать процессор, что нам и нужно. При N = 1000 на моей машине этот код выполняется ~10мс.

Тесты

Для тестирования я использовал свой рабочий компьютер

Для нагрузки на API использовался k6. Настройка простая: тестируется один путь, 50 виртуальных пользователей в течении 5-ти минут.

import http from 'k6/http';
import { randomString } from 'https://jslib.k6.io/k6-utils/1.2.0/index.js';

export const options = {
    duration: "5m",
    vus: 50,
};

export default function () {
    const body = randomString(1, 30)
    http.post('http://localhost:8090/test', body);
}

Для тестирования классического HTTP сервиса конфигурация такая же, только другой путь к конечной точке.

Классический HTTP сервис:

Обработка через СОЗ (10 потоков обработчиков запросов):

Выводы

Результаты тестирования показали, что обработка запросов через СОЗ дало ~20% прироста производительности в рамках req/s (запросы в секунду). Так же можно увидеть  значительное улучшение результатов во времени обработки запроса.

Так же во время тестирования я наблюдал за нагрузкой на систему и в связке СОЗ + 1С можно заметить больший процент утилизации процессора rphost'ом ~89-93% против ~71-75%, что скорее всего и дало положительные результаты по производительности.

Еще из положительных аспектов: работа через СОЗ дает контролируемое количество сеансов 1С.

Из минусов: повышенная сложность алгоритма обработки запроса и баги, которые пока еще не выявлены.

Для кого подошло бы такое решение?

Наверное только для тех, у кого есть большие нагрузки на HTTP сервис, который дает просадки по производительности, случайные длинные ответы и другие артефакты HTTP сервисов от 1С.

P.S.

В архиве, приложенном к статье, лежит файл GO, файлы k6 и dt базы в которой я делал тестирование.

UPD

Проект СОЗ на Github