Влияет ли медленный дисковый ввод-вывод на производительность остальных приложений Node.js? - PullRequest
0 голосов
/ 08 января 2019

Я работаю в небольшой команде, разрабатывающей одностраничное приложение, которое в значительной степени опирается на запросы с низкой задержкой через WebSockets. Серверная часть работает на Node.js + Redis. Он должен поддерживать от сотен до тысяч одновременных соединений, а запросы должны обслуживаться в течение 50-100 мс (при хороших условиях сети на стороне клиента). Мы очень довольны нашей первоначальной реализацией этой части сервера, она работает как положено.

Нам также нужно обслуживать множество статических файлов по HTTP. Эти запросы не чувствительны ко времени. Из-за больших требований к хранилищу мы хотели бы выбрать массив жестких дисков вместо твердотельных накопителей по соображениям стоимости.

Существует ли риск медленного дискового ввода-вывода, который может ухудшить производительность остальной части приложения Node.js (часть WebSocket, использующая только базу данных в памяти), или это сильно повлияет на часть обслуживания HTTP / статического файла сервера? Насколько я понимаю, Node.js с его асинхронной природой хорошо бы подходил для такой ситуации, поскольку он позволял бы модулю WebSockets обрабатывать запросы в обычном режиме, пока модуль HTTP ожидает чтения / записи дисков?

Возможно, большое количество HTTP-запросов "в ожидании обслуживания" может каким-то образом засорить сервер (в конце концов, они должны где-то храниться, и, вероятно, нет возможности опроса, если доступно чтение и запись), и нам нужно рассмотреть возможность использования отдельного процесса Node.js для обслуживания статических файлов или даже отдельного выделенного сервера?

Я могу думать о следующих вещах:

  • HTTP-запрос «ожидает обслуживания» будет использовать ограниченное количество доступных одновременных TCP-соединений
  • HTTP-запросы «ожидающие обработки» также будут занимать некоторое количество оперативной памяти
  • системные файлы, вероятно, должны находиться на диске, который не будет занят обслуживанием статических файлов

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

Ответы [ 2 ]

0 голосов
/ 10 января 2019

Краткий ответ: Да Существует огромный риск: p

https://nodejs.org/api/fs.html#fs_threadpool_usage

Использование пула потоков #

Все API файловой системы, кроме fs.FSWatcher () и тех, которые явно синхронно использовать пул потоков libuv, который может удивительные и негативные последствия для производительности для некоторых Приложения. Смотрите документацию UV_THREADPOOL_SIZE, чтобы узнать больше. информация.

http://docs.libuv.org/en/v1.x/design.html#file-i-o

UV Threadpool поддерживается системными потоками, поэтому профиль масштабирования будет сильно отличаться от остальной части приложения. ИМО, это не так уж и рискованно, просто ... разные и точные данные помогут увидеть профиль масштабирования вашего приложения.


Я думаю, Общая рекомендация - разгрузить обслуживание статических файлов, если это вообще возможно. Может помочь прокси-сервер перед вашим приложением, способный быстро обслуживать статические файлы (nginx) (не потому, что он решает основную проблему блокировки чтения файловой системы, а потому, что может обеспечивать более равномерную / предсказуемую производительность или масштабирование, так как оно должно управлять только обслуживающими файлами, в то время как вашему приложению потребуется переключение контекста между пользователями и обслуживающими файлами. Я лично изучил бы ваши рекомендации по использованию отдельного процесса или CDN, чтобы попытаться полностью удалить обслуживание статических файлов из вашего приложение.

0 голосов
/ 08 января 2019

Если у вас много запросов от клиентов, вам нужно использовать балансировщик нагрузки через Cluster API https://nodejs.org/api/cluster.html Вы также должны рассмотреть возможность использования кэша, потому что операции с http и диском действительно дороги. И если этих вещей недостаточно, вы просто добавляете новые серверы. Так я понимаю и решаю проблемы с высокой нагрузкой.

P. S. Я не думаю, что node.js - это проблема, это хорошая платформа для таких вещей, как обслуживание статических файлов. У вас просто много запросов, и вам нужно решить эту проблему с помощью методов, которые я описал.

...