Как в Node.js контролировать потребление памяти при обработке сетевых запросов

[bankir1980]

Подскажите, а если строгая последовательность не нужна? Например в чанке есть некоторый набор данных, который нужно сохранить в БД, то получается, что при обработке событиями можно же паузой оперировать в зависимости от количества соединений к БД в пуле? Т.е. если пул включает 5 соединений, то получая данные из буфера, достаточные для их отправки в БД можно их туда и запульнуть, а пока бд делает обработку запроса, обрабатывать (принимать) следующий набор данных (и так до 5, после чего уже включать паузу). В случае с for await получается, что мы будем ожидать пока БД не сохранит данные? Т.е. выполнять всё строго последовательно?

[vkugay]

Вы имеете в виду следующий алгоритм?

1. Клиент отправляет составные данные, например, CSV файл, с помощью протокола HTTP

2. Сервер оформляет подписку на событие data c помощью readable.on('data', callback);

3. Обработчик буферизует X байт и инициирует процесс загрузки данных в базу данных

4. Обработчик буферизует еще X байт и снова инициирует процесс загрузки данных в базу данных, пока предыдущие данные загружаются

5. Обработчик ставит потребление данных на паузу, когда суммарно обрабатываемое количество данных достигает размера Y

6. Обработчик продолжает потребление данных, когда один из процессов загрузки X байт завершился

Если я все понял правильно, то, возможно, такой алгоритм позволит ускориться в сравнении с for await, но нужно замерить производительность в среде приближенной к эксплуатационной, потому что я вижу следующие риски:

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

• Усложнится обработка данных, а прироста в скорости загрузки данных не произойдет, т.к. одновременная вставка большого количества данных создаст узкое место в БД

Что точно можно сделать с помощью такого алгоритма, так это обойти лимит на количество параметров SQL в PostgtreSQL, который для libpq составляет 65,535. Но тоже самое можно реализовать, если разбить крупный чанк, полученный с помощью for await ... of, на более мелкие и использовать для их загрузки отдельные подключения.