- PVSM.RU - https://www.pvsm.ru -
Привет! Представляю вашему вниманию перевод статьи "Everything you need to know about Node.js" [1] автора Jorge Ramón.
В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's. Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT.
Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её. Этот пост главным образом пытается быть путеводителем по тому, как Node.js работает на самом деле.
Давайте же начнём!!
О чем пойдёт речь:
Многопоточный сервер
Веб-приложения, написанные следуя клиент/серверной архитектуре, работают по следующей схеме — клиент запрашивает нужный ресурс у сервера и сервер отправляет ресурс в ответ. В этой схеме сервер, ответив на запрос, прерывает соединение.
Такая модель эффективна поскольку каждый запрос к серверу потребляет ресурсы (память, процессорное время и т.д.). Для того чтобы обрабатывать каждый последующий запрос от клиента, сервер должен завершить обработку предыдущего.
Значит ли это, что сервер может обрабатывать только один запрос за раз? Не совсем! Когда сервер получает новый запрос он создаёт отдельный поток для его обработки.
Поток, если простыми словами, это время и ресурсы, что CPU выделает на выполнение небольшого блока инструкций. С учётом сказанного, сервер может обрабатывать несколько запросов одновременно, но только по одному на поток. Такая модель так же называться thread-per-request model.
Для обработки N запросов серверу нужно N потоков. Если сервер получает N+1 запросов, тогда он должен ждать пока один из потоков не станет доступным.
На рисунке выше, сервер может обрабатывать до 4 запросов (потоков) единовременно и когда он получает следующие 3 запроса, эти запросы должны ждать пока любой из этих 4 потоков не станет доступным.
Один из способов избавиться от ограничений — добавить больше ресурсов (памяти, ядер процессора и т. д.) на сервер, но это не самое лучшее решение….
И, конечно, не забываем о технологических ограничениях.
Блокирующий ввод/вывод
Ограниченное число потоков на сервере не единственная проблема. Возможно, Вам стало интересно почему один поток не может обрабатывать несколько запросов одновременно? Все из-за блокирующих операций ввода/вывода.
Допустим, Вы разрабатываете онлайн магазин и Вам нужна страница где пользователь может просматривать список всех товаров.
Пользователь стучится на http://yourstore.com/products [7] и сервер рендерит HTML файл со всеми продуктами с базы данных в ответ. Совсем не сложно, да?
Но, что же происходит за кулисами?
/products
особый метод или функция должна выполниться, что бы обработать запрос. Маленький кусочек кода (Ваш или фреймворка) анализирует URL-адрес запроса и ищет подходящий метод или функцию. Поток работает. SELECT * FROM products
, выполняет свою работу, но угадайте что? Да-да, это блокирующая операция ввода/вывода. Поток ждёт. На сколько медленны операции ввода/вывода? Ну это зависит от конкретной. Давайте обратимся к таблице:
Операция | Количество CPU тактов |
---|---|
CPU Registers | 3 такта |
L1 Cache | 8 тактов |
L2 Cache | 12 тактов |
RAM | 150 тактов |
Disk | 30,000,000 тактов |
Network | 250,000,000 тактов |
Операции сети и чтения с диска слишком медленные. Представьте сколько запросов или обращений к внешним API ваша система могла бы обработать за это время.
Подбивая итоги: операции ввода/вывода заставляют поток ждать и тратить ресурсы в пустую.
Проблема
C10k (англ. C10k; 10k connections — проблема 10 тысяч соединений)
В ранние 2000-ые, серверные и клиентские машины были медленными. Проблема возникала при параллельной обработке 10 000 клиентских соединений к одной машине.
Но почему традиционная модель thread-per-request (поток на запрос) не могла решить эту проблему? Что ж, давайте используем немного математики.
Нативная реализация потоков выделает больше 1 Мб памяти на поток, выходя из этого – для 10 тысяч потоков требуется 10 Гб оперативной памяти и это только для стека потоков. Да, и не забывайте, мы в начале 2000-х!!
В наши дни серверные и клиентские компьютеры работают быстрее и эффективней и почти любой язык программирования или фреймворк справляются с этой проблемой. Но фактически проблема не исчерпана. Для 10 миллионов клиентских соединений к одной машине проблема возвращается вновь (но теперь она C10M Problem [8]).
JavaScript спасение?
Осторожно, спойлеры!!!
Node.js на самом деле решает проблему C10K… но как?!
Серверный JavaScript не был чем-то новым и необычным в начале 2000-х, на тот момент уже существовали реализации поверх JVM (java virtual machine) – RingoJS и AppEngineJS, что работали на модели thread-per-request.
Но если они не смогли решить проблему, тогда как Node.js смог?! Все из-за того, что JavaScript однопоточный.
Node.js
Node.js это серверная платформа, что работает на движке Google Chrome – V8, который умеет компилировать JavaScript код в машинный код.
Node.js использует событийно-ориентированную модель и неблокирующую ввод / вывод архитектуру, что делает его легковесным и эффективным. Это не фреймворк, и не библиотека, это среда выполнения JavaScript.
Давайте напишем маленький пример:
// Importing native http module
const http = require('http');
// Creating a server instance where every call
// the message 'Hello World' is responded to the client
const server = http.createServer(function(request, response) {
response.write('Hello World');
response.end();
});
// Listening port 8080
server.listen(8080);
Non-blocking I/O
Node.js использует неблокирующие ввод/вывод операции, что же это значит:
Давайте напишем пример, в котором на запрос к /home
сервер в ответ шлёт HTML страницу, а для всех других запросов 'Hello World'. Что бы отослать HTML страницу сначала ее нужно прочитать с файла.
home.html
<html>
<body>
<h1>This is home page</h1>
</body>
</html>
index.js
const http = require('http');
const fs = require('fs');
const server = http.createServer(function(request, response) {
if (request.url === '/home') {
fs.readFile(`${ __dirname }/home.html`, function (err, content) {
if (!err) {
response.setHeader('Content-Type', 'text/html');
response.write(content);
} else {
response.statusCode = 500;
response.write('An error has ocurred');
}
response.end();
});
} else {
response.write('Hello World');
response.end();
}
});
server.listen(8080);
Если запрашиваемый url-адрес /home
, тогда используется нативный модуль fs
для чтения файла home.html
.
Функции что попадают в http.createServer
и fs.readFile
как аргументы — колбэки. Эти функции будут выполнены в какой-то из моментов в будущем (Первая, как только сервер получит запрос, а вторая — когда файл будет прочитан с диска и помещён в буфер).
Пока файл считывается с диска, Node.js может обрабатывать другие запросы и даже считывать файл снова и все это в одном потоке… но как?!
Цикл событий
Цикл событий — это магия, которая происходит внутри Node.js. Это буквально бесконечный цикл и на самом деле один поток.
Libuv — C библиотека которая реализует этот паттерн и является частью ядра Node.js. Вы можете узнать больше о libuv здесь [9].
Цикл событий имеет 6 фаз, каждое исполнение всех 6 фаз называют tick-ом.
setTimeout()
и setInterval()
;close
, таймеров и setImmediate()
;setImmediate()
, выполняються на этом этапе;socket.on('close', ...)
;Хорошо, есть только один поток, и этот поток и есть цикл событий, но тогда кто выполняет все операции ввода/вывода?
Обратите внимание!!!
Когда циклу событий нужно выполнить операцию ввода/вывода он использует поток ОС с тредпула (thread pool), а когда задача выполнена, коллбэк ставится в очередь во время фазы pending callbacks.
Разве это не круто?
Node.js кажется идеальным! Вы можете создавать все, что захотите.
Давайте напишем API для вычислений простых чисел.
Простое число – это целое (натуральное) число больше единицы и делимое только на 1 и на само себя.
Дано число N, API должен вычислять и возвращать первые N простых чисел в список (или массив).
primes.js
function isPrime(n) {
for(let i = 2, s = Math.sqrt(n); i <= s; i++) {
if(n % i === 0) return false; return n > 1;
}
}
function nthPrime(n) {
let counter = n;
let iterator = 2;
let result = [];
while(counter > 0) {
isPrime(iterator) && result.push(iterator) && counter--;
iterator++;
}
return result;
}
module.exports = { isPrime, nthPrime };
index.js
const http = require('http');
const url = require('url');
const primes = require('./primes');
const server = http.createServer(function (request, response) {
const { pathname, query } = url.parse(request.url, true);
if (pathname === '/primes') {
const result = primes.nthPrime(query.n || 0);
response.setHeader('Content-Type', 'application/json');
response.write(JSON.stringify(result));
response.end();
} else {
response.statusCode = 404;
response.write('Not Found');
response.end();
}
});
server.listen(8080);
prime.js
это реализация нужных вычислений: функция isPrime
проверяет есть ли число простым, а nthPrime возвращает N таких чисел.
Файл же index.js
отвечает за создание сервера и использует модуль prime.js
для обработки каждого запроса на /primes
. Число N прокидывается через строку запроса в URL-адресе.
Что бы получить первых 20 простых чисел нам нужно сделать запрос на http://localhost:8080/primes?n=20
.
Предположим, к нам стучаться 3 клиента и пытаются получить доступ к нашему не блокирующемуся вводом/выводом API:
Когда третий клиент шлёт запрос – главный поток блокируется и это главный признак проблемы CPU-ёмких задач. Когда главный поток занят исполнением «тяжёлой» задачи он стает недоступен для других задач.
Но как насчёт libuv? Если Вы помните, эта библиотека помогает Node.js исполнять операции ввода/вывода с помощью потоков ОС избегая блокировки главного потока и Вы абсолютно правы, это решение нашей проблемы, но для того, что бы это стало возможным, наш модуль должен быть написан на языке C++, что бы libuv могла с ним работать.
К счастью, начиная с v10.5 в Node.js добавлен нативный модуль Worker Threads.
Как говорит нам документация [10]:
Воркеры полезны для выполнения CPU-ёмких JavaScript операций; не используйте их для операций ввода/вывода, уже встроенные в Node.js механизмы справляться более эффективно с такими задачи чем Worker thread.
Исправление кода
Пришло время переписать наш код:
primes-workerthreads.js
const { workerData, parentPort } = require('worker_threads');
function isPrime(n) {
for(let i = 2, s = Math.sqrt(n); i <= s; i++)
if(n % i === 0) return false;
return n > 1;
}
function nthPrime(n) {
let counter = n;
let iterator = 2;
let result = [];
while(counter > 0) {
isPrime(iterator) && result.push(iterator) && counter--;
iterator++;
}
return result;
}
parentPort.postMessage(nthPrime(workerData.n));
index-workerthreads.js
const http = require('http');
const url = require('url');
const { Worker } = require('worker_threads');
const server = http.createServer(function (request, response) {
const { pathname, query } = url.parse(request.url, true);
if (pathname === '/primes') {
const worker = new Worker('./primes-workerthreads.js', { workerData: { n: query.n || 0 } });
worker.on('error', function () {
response.statusCode = 500;
response.write('Oops there was an error...');
response.end();
});
let result;
worker.on('message', function (message) {
result = message;
});
worker.on('exit', function () {
response.setHeader('Content-Type', 'application/json');
response.write(JSON.stringify(result));
response.end();
});
} else {
response.statusCode = 404;
response.write('Not Found');
response.end();
}
});
server.listen(8080);
В файле index-workerthreads.js
при каждом запросе на /primes
создаётся экземпляр класса Worker
(с нативного модуля worker_threads
) для выгрузки и исполнения файла primes-workerthreads.js
в поток воркера. Когда список простых чисел просчитан и готов, инициируется событие message
– результат попадает в главный поток из-за того, что у воркера не осталось работы он также инициирует событие exit
, позволяя основному потоку отправлять данные клиенту.
primes-workerthreads.js
изменён немного. Он импортирует workerData
(это копия параметров, переданных с основного потока) и parentPort
через который результат роботы воркера передаётся назад в главный поток.
Теперь давайте испробуем наш пример снова и посмотрим, что случиться:
Основной поток больше не блокируются !!!!!
Теперь все работает как нужно, но плодить воркеры без всяких на то причин все же не лучшая практика, создавать потоки не дешёвое удовольствие. Обязательно создайте пул потоков перед этим.
Node.js мощная технология, которую стоит изучить при возможности.
Моя личная рекомендация – всегда будьте любопытными! Если Вы знаете, как что-то работает изнутри, Вы сможете работать с этим более эффективно.
Это все на сегодня, ребята. Я надеюсь этот пост был полезен для Вас и вы узнали что-то новое о Node.js.
Спасибо за прочтение и до встречи в следующих постах.
Автор: DemjanUA
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/324441
Ссылки в тексте:
[1] "Everything you need to know about Node.js": https://dev.to/jorge_rockr/everything-you-need-to-know-about-node-js-lnc#theproblemwithcpuintensivetasks
[2] Мир до Node.js: #p1
[3] Проблема C10K: #p2
[4] Node.js и цикл событий: #p3
[5] Проблема CPU-ёмких задач: #p4
[6] Воркеры и их потоки: #p5
[7] http://yourstore.com/products: http://yourstore.com/products
[8] C10M Problem: http://c10m.robertgraham.com/p/manifesto.html
[9] здесь: https://nikhilm.github.io/uvbook/introduction.html
[10] документация: https://nodejs.org/api/worker_threads.html
[11] Источник: https://habr.com/ru/post/460661/?utm_campaign=460661&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.