Express.js заслуженно остаётся одним из самых популярных инструментов для создания бэкенда, но даже он не застрахован от проблем с производительностью. Многие разработчики сталкиваются с ситуацией, когда на локальной машине всё летает, а на продакшене под реальной нагрузкой сервер начинает "задыхаться". Причина часто кроется не в самом Express.js, а в том, как мы его используем.
Знакомая картина: пользователи жалуются на зависания, а мониторинг показывает растущее потребление памяти и CPU. Вы начинаете гуглить "как ускорить Express.js", но находите лишь общие советы вроде "используйте кэширование" или "оптимизируйте запросы к БД". Эти рекомендации верны, но слишком поверхностны, чтобы действительно решить проблему. В боевых проектах улучшение производительности Express.js требуеть системного подхода. Нужно понимать, как работает event loop в Node.js, как выстраивать цепочки middleware, как эффективно взаимодействовать с базами данных и внешними API. Любое неоптимальное решение может стать узким местом, из-за которого ваше приложение будет тормозить сильнее, чем должно.
Базовые принципы производительности Express.js
Асинхронные обработчики маршрутов
В основе Node.js лежит однопоточная модель с событийным циклом. Это значит, что блокировка основного потока — смертный грех. Даже одна синхронная операция может заставить все приложение "зависнуть", пока она не завершится.
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Плохо: блокирующий обработчик
app.get('/user/:id', (req, res) => {
// Синхронное чтение файла блокирует весь сервер
const userData = fs.readFileSync(`./users/${req.params.id}.json`);
res.json(JSON.parse(userData));
});
// Хорошо: асинхронный подход
app.get('/user/:id', async (req, res) => {
try {
// Асинхронное чтение с промисами не блокирует event loop
const userData = await fs.promises.readFile(`./users/${req.params.id}.json`);
res.json(JSON.parse(userData));
} catch (err) {
res.status(500).send('Что-то пошло не так');
}
}); |
|
Эффективная обработка запросов
Express — минималистичный фреймворк, который не делает многого за вас. Это и плюс, и минус одновременно. Вот несколько приемов, которые помогут обрабатывать запросы эффективнее:
1. Используйте метод res.json() вместо res.send() для JSON-ответов — он автоматически устанавливает правильные заголовки и конвертирует данные.
2. Прекращайте цепочку обработки рано с помощью return или next():
| JavaScript | 1
2
3
4
5
6
7
| app.use((req, res, next) => {
if (!req.headers.authorization) {
return res.status(401).json({ error: 'Отсутствует токен' });
}
// Продолжаем только если авторизация есть
next();
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| app.get('/data', async (req, res, next) => {
try {
const data = await fetchSomeData();
res.json(data);
} catch (error) {
// Передаем ошибку middleware для обработки ошибок
next(error);
}
});
// Глобальный обработчик ошибок
app.use((err, req, res, next) => {
console.error(err.stack);
res.status(500).json({ error: 'Что-то сломалось, но мы уже чиним' });
}); |
|
Минимизация блокировок event loop
Понимание event loop критично для производительности. Это механизм, который позволяет Node.js быть асинхронным, несмотря на однопоточность. Вот частые причины блокировок:
1. Тяжелые вычисления — обработка больших массивов, сложные математические операции:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Плохо: блокировка event loop
app.get('/calculate', (req, res) => {
let result = 0;
for (let i = 0; i < 10000000; i++) {
result += i;
}
res.json({ result });
});
// Лучше: используйте worker_threads для CPU-интенсивных задач
app.get('/calculate', (req, res) => {
const worker = new Worker('./calculations.js');
worker.on('message', (result) => {
res.json({ result });
});
worker.postMessage({ type: 'calculate' });
}); |
|
3. Рекурсивные функции — могут переполнить стек вызовов, особенно при работе с древовидными структурами данных.
Я работал с проектом, где простой переход от синхронного парсинга файлов CSV к потоковой обработке через csv-parser сократил время ответа с 4 секунд до 300 мс. Казалось бы, мелочь, но пользователи отметили, что приложение стало "гораздо быстрее".
Express.js это не монолит, а конструктор, из которого вы собираете своё приложение. Каждый компонент должен быть оптимизирован для достижения максимальной производительности. В следующих разделах мы рассмотрим более продвинутые техники, которые позволят вам выжать из Express.js максимум скорости.
Установка express
Всем привет. Устанавливаю по инструкции: npm install -g express
Запускаю проект в котором... Не получается установить модуль express
Nodejs Не получается установить модуль express выдает ошибку: Установка express
Собственно выполняю npm i -g express из под винды, загрузка идет, но в консоль только выводятся... Зачем Socket.IO нужен express
Подскажите пожалуйста, есть ли причины использовать express в связке с Socket.IO кроме отдачи...
Проектирование неблокирующей архитектуры маршрутов
Архитектура маршрутов в Express.js — фундамент вашего приложения. Представьте её как транспортную систему мегаполиса: правильно спроектированная, она обеспечивает быстрое перемещение без пробок, а неудачная — вызывает заторы даже при небольшом потоке.
Анатомия неблокирующего маршрута
Неблокирующий маршрут должен быть построен так, чтобы ни одна операция не задерживала event loop надолго. Вот пример маршрута, который выглядит безобидно, но может стать узким местом:
| JavaScript | 1
2
3
4
5
6
7
8
| // Опасный код: последовательные запросы блокируют друг друга
app.get('/dashboard', async (req, res) => {
const userData = await userService.getProfile(req.user.id);
const notifications = await notificationService.getAll(req.user.id);
const stats = await analyticsService.getUserStats(req.user.id);
res.render('dashboard', { user: userData, notifications, stats });
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
| // Лучше: параллельное выполнение независимых запросов
app.get('/dashboard', async (req, res) => {
const [userData, notifications, stats] = await Promise.all([
userService.getProfile(req.user.id),
notificationService.getAll(req.user.id),
analyticsService.getUserStats(req.user.id)
]);
res.render('dashboard', { user: userData, notifications, stats });
}); |
|
Promise.all(), мы запускаем все запросы одновременно, что значительно сокращает время ответа. Но что если один из этих запросов завершится с ошибкой? Тогда весь Promise.all() будет отклонен, и пользователь получит 500-ю ошибку вместо частично заполненной страницы.
Ещё лучший подход — использовать Promise.allSettled(), который выполнит все промисы, независимо от того, были ли ошибки:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| app.get('/dashboard', async (req, res) => {
const results = await Promise.allSettled([
userService.getProfile(req.user.id),
notificationService.getAll(req.user.id),
analyticsService.getUserStats(req.user.id)
]);
// Обработка результатов с учетом возможных ошибок
const [userResult, notificationsResult, statsResult] = results;
const viewData = {
user: userResult.status === 'fulfilled' ? userResult.value : null,
notifications: notificationsResult.status === 'fulfilled' ? notificationsResult.value : [],
stats: statsResult.status === 'fulfilled' ? statsResult.value : {}
};
res.render('dashboard', viewData);
}); |
|
Декомпозиция тяжелых маршрутов
Иногда маршрут слишком сложен для одного обработчика. В таких случаях стоит разделить его на несколькр частей:
1. Разделение на подзапросы — вместо одного "толстого" эндпоинта создайте несколько более мелких, которые фронтенд сможет вызывать параллельно.
2. Потоковая передача данных — для больших объемов данных используйте потоки:
| JavaScript | 1
2
3
4
5
| // Потоковая передача большого JSON-файла
app.get('/large-data', (req, res) => {
const dataStream = fs.createReadStream('./large-data.json');
dataStream.pipe(res);
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| app.get('/product/:id', async (req, res) => {
// Быстрый запрос базовой информации
const basicInfo = await productService.getBasicInfo(req.params.id);
// Отправляем основные данные клиенту
res.write(JSON.stringify({ basic: basicInfo }));
// Получаем более тяжелые данные
const [reviews, relatedProducts] = await Promise.all([
productService.getReviews(req.params.id),
productService.getRelatedProducts(req.params.id)
]);
// Отправляем дополнительные данные
res.write(JSON.stringify({ reviews, relatedProducts }));
res.end();
}); |
|
Маршруты с условной логикой
Часто маршруты содержат условную логику, которая может быть оптимизирована:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Избегаем ненужных операций с ранним выходом
app.get('/search', async (req, res) => {
// Проверяем параметры поиска
if (!req.query.q) {
return res.status(400).json({ error: 'Поисковый запрос обязателен' });
}
// Если запрос короткий, используем кэш или легкий поиск
if (req.query.q.length < 3) {
const quickResults = await searchService.quickSearch(req.query.q);
return res.json({ results: quickResults });
}
// Для сложных запросов используем полноценный поиск
const fullResults = await searchService.fullSearch(req.query.q);
res.json({ results: fullResults });
}); |
|
Оптимизация middleware-цепочек
Middleware — сердце и душа Express.js. Это последовательность функций, через которые проходит каждый запрос, как по конвейеру. Неоптимальные middleware-цепочки могут превратить быстрое приложение в неповоротливого монстра, даже если сами маршруты идеально оптимизированы.
Порядок имеет значение
Последовательность middleware критична для производительности. Тяжеловесные операции, расположенные в начале цепочки, замедляют обработку всех запросов:
| JavaScript | 1
2
3
4
5
6
7
8
9
| // Плохо: тяжелая аутентификация выполняется для всех запросов
app.use(complexAuthentication);
app.use(logger);
app.use(compression());
// Лучше: сначала быстрые операции, тяжелые - только когда необходимы
app.use(logger);
app.use(compression());
app.use('/api', complexAuthentication); // Только для API-маршрутов |
|
Условное применение middleware
Не каждый middleware нужен для каждого запроса. Например, парсинг тела запроса не нужен для GET-запросов:
| JavaScript | 1
2
3
4
5
6
7
8
9
| // Оптимизированный bodyParser
app.use((req, res, next) => {
// Парсим тело только для определенных методов
if (['POST', 'PUT', 'PATCH'].includes(req.method)) {
bodyParser.json()(req, res, next);
} else {
next();
}
}); |
|
Минимизация работы в middleware
Middleware должен делать только то, что действительно нужно:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| // Неэффективно: слишком много работы в одном middleware
app.use(async (req, res, next) => {
req.user = await db.users.findById(req.session.userId);
req.permissions = await db.permissions.findByUserId(req.user.id);
req.settings = await db.settings.getForUser(req.user.id);
next();
});
// Лучше: ленивая загрузка по необходимости
app.use((req, res, next) => {
// Добавляем геттеры, которые загружают данные только при обращении
Object.defineProperty(req, 'user', {
get: async function() {
if (!this._user) {
this._user = await db.users.findById(req.session.userId);
}
return this._user;
}
});
next();
}); |
|
Избегайте тяжелых синхронных операций
Синхронный код в middleware блокирует все запросы — абсолютное табу для высоконагруженных приложений:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| // Плохо: синхронная валидация может блокировать event loop
app.use((req, res, next) => {
const schema = createComplexValidationSchema(); // Тяжелая операция
const valid = schema.validate(req.body);
if (!valid) return res.status(400).send('Невалидные данные');
next();
});
// Лучше: предварительно создаем схемы
const validationSchemas = {
createUser: createComplexValidationSchema('user'),
updateProduct: createComplexValidationSchema('product')
// и т.д.
};
// Используем готовые схемы
app.post('/users', (req, res, next) => {
const valid = validationSchemas.createUser.validate(req.body);
if (!valid) return res.status(400).send('Невалидные данные');
next();
}); |
|
Разделение middleware по маршрутам
Не все middleware нужны глобально. Используйте их только там, где действительно необходимо:
| JavaScript | 1
2
3
4
5
6
7
8
| // Вместо глобальных middleware
app.use(authMiddleware);
app.use(roleCheck('admin'));
// Применяйте их к конкретным маршрутам
app.get('/public', publicHandler); // Без аутентификации
app.get('/profile', authMiddleware, profileHandler); // С аутентификацией
app.get('/admin', authMiddleware, roleCheck('admin'), adminHandler); // С проверкой роли |
|
Объединение взаимосвязанных middleware
Иногда несколько middleware можно объединить в один для уменьшения накладных расходов:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| // Было три middleware
app.use(parseToken);
app.use(validateToken);
app.use(fetchUserByToken);
// Стало один эффективный middleware
app.use(async (req, res, next) => {
try {
const token = req.headers.authorization?.split(' ')[1];
if (!token) return next();
const decoded = jwt.verify(token, secretKey);
req.user = await db.users.findById(decoded.id);
next();
} catch (error) {
next(); // Продолжаем без авторизации при ошибке
}
}); |
|
Техники профилирования и управление памятью
Профилирование и управление памятью — два кита, на которых держится производительность Express.js при долгосрочной работе. Без них даже идеально спроектированное приложение со временем превратится в прожорливого монстра, пожирающего ресурсы сервера.
Инструментарий профилирования
Прежде чем оптимизировать, нужно знать, что именно тормозит. Слепая оптимизация — путь в никуда. Для профилирования Express-приложений есть несколько мощных инструментов:
1. Встроенные средства Node.js:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
| // Измерение времени выполнения участка кода
const start = process.hrtime.bigint();
// Ваш код...
const end = process.hrtime.bigint();
console.log(`Операция заняла ${(end - start) / 1000000n} мс`);
// Альтернативный способ с метками
console.time('operationLabel');
// Ваш код...
console.timeEnd('operationLabel'); // Выведет: operationLabel: 123.45ms |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| // Простой middleware для измерения времени обработки запросов
app.use((req, res, next) => {
req._startTime = process.hrtime.bigint();
// Перехватываем метод end для замера времени ответа
const originalEnd = res.end;
res.end = function(...args) {
const ms = Number(process.hrtime.bigint() - req._startTime) / 1000000;
console.log(`${req.method} ${req.url} - ${ms.toFixed(2)}ms`);
originalEnd.apply(this, args);
};
next();
}); |
|
| Bash | 1
2
3
4
5
6
7
8
| # Установка инструментов
npm install -g clinic autocannon
# Запуск профилирования
clinic doctor -- node app.js
# В другом терминале запускаем нагрузку
autocannon -c 100 -d 20 [url]http://localhost:3000/api/users[/url] |
|
Выявление утечек памяти
Утечки памяти в Node.js коварны: они медленно накапливаются и могут проявиться только после нескольких дней работы сервера. Типичные места утечек:
1. Незакрытые таймеры и сокеты:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
| // Плохо: утечка памяти
function startPolling(userId) {
setInterval(() => fetchUserUpdates(userId), 5000);
}
// Хорошо: сохраняем ссылку для последующей очистки
function startPolling(userId) {
const timer = setInterval(() => fetchUserUpdates(userId), 5000);
return {
stop: () => clearInterval(timer)
};
} |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Опасно: каждый запрос добавляет новый слушатель
app.get('/stream', (req, res) => {
const onData = (data) => res.write(data);
eventEmitter.on('update', onData);
// Нет обработки закрытия соединения и удаления слушателя!
});
// Безопасно: отслеживаем закрытие соединения
app.get('/stream', (req, res) => {
const onData = (data) => res.write(data);
eventEmitter.on('update', onData);
req.on('close', () => {
eventEmitter.off('update', onData);
});
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| // Опасно: безграничный кэш
const cache = {};
app.get('/data/:id', async (req, res) => {
if (!cache[req.params.id]) {
cache[req.params.id] = await fetchExpensiveData(req.params.id);
}
res.json(cache[req.params.id]);
});
// Безопасно: ограниченный LRU-кэш
const LRU = require('lru-cache');
const cache = new LRU({ max: 500 }); // Максимум 500 элементов
app.get('/data/:id', async (req, res) => {
if (!cache.has(req.params.id)) {
cache.set(req.params.id, await fetchExpensiveData(req.params.id));
}
res.json(cache.get(req.params.id));
}); |
|
Практики диагностики и мониторинга
Я столкнулся с проектом, где утечки памяти приводили к перезапуску сервера каждые 8 часов. Решением стало внедрение комплексной системы мониторинга:
1. Периодические снимки кучи (heap snapshots):
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
| // Сохранение снимков кучи по API-запросу
const heapdump = require('heapdump');
app.get('/debug/heapdump', (req, res) => {
if (req.query.secret !== process.env.DEBUG_SECRET) {
return res.status(403).send('Forbidden');
}
const filename = `heapdump-${Date.now()}.heapsnapshot`;
heapdump.writeSnapshot(filename, (err, filename) => {
if (err) return res.status(500).send(err.message);
res.download(filename); // Отправляем файл для анализа
});
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
| // Вывод статистики памяти каждые 5 минут
setInterval(() => {
const memUsage = process.memoryUsage();
console.log({
rss: [INLINE]${Math.round(memUsage.rss / 1024 / 1024)} MB[/INLINE],
heapTotal: [INLINE]${Math.round(memUsage.heapTotal / 1024 / 1024)} MB[/INLINE],
heapUsed: [INLINE]${Math.round(memUsage.heapUsed / 1024 / 1024)} MB[/INLINE],
external: [INLINE]${Math.round(memUsage.external / 1024 / 1024)} MB[/INLINE]
});
}, 300000); |
|
Продвинутые техники оптимизации
Когда базовая оптимизация Express.js исчерпана, наступает время тяжелой артиллерии. Эти техники требуют больше усилий на внедрение, но обеспечивают кратный прирост производительности, особенно под высокой нагрузкой. Именно они разделяют приложения, которые "просто работают", от тех, что "летают" даже при тысячах одновременных пользователей.
Горизонтальное масштабирование
Даже самый оптимизированный однопоточный Node.js-сервер имеет предел производительности, ограниченный одним ядром процессора. Чтобы преодолеть это ограничение, используйте кластеризацию:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| const cluster = require('cluster');
const os = require('os');
const numCPUs = os.cpus().length;
if (cluster.isMaster) {
console.log(`Мастер-процесс ${process.pid} запущен`);
// Создаем рабочие процессы для каждого ядра
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Рабочий процесс ${worker.process.pid} завершен`);
// Перезапускаем упавший процесс
cluster.fork();
});
} else {
// Запускаем Express в рабочих процессах
const app = require('express')();
// ... настройка маршрутов
app.listen(3000);
console.log(`Рабочий процесс ${process.pid} запущен`);
} |
|
Многоуровневое кэширование
Кэширование — мощнейший инструмент оптимизации, но применять его нужно стратегически:
1. In-memory кэш — самый быстрый, но ограничен размером RAM и не сохраняется между перезапусками:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| const NodeCache = require('node-cache');
const cache = new NodeCache({ stdTTL: 600, checkperiod: 120 });
app.get('/products', async (req, res) => {
const cacheKey = `products-${JSON.stringify(req.query)}`;
// Проверяем кэш
const cachedData = cache.get(cacheKey);
if (cachedData) return res.json(cachedData);
// Если нет в кэше, получаем из БД
const products = await db.products.findAll({ where: req.query });
// Сохраняем в кэш и отправляем
cache.set(cacheKey, products);
res.json(products);
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| const redis = require('redis');
const { promisify } = require('util');
const client = redis.createClient();
// Промисификация Redis-клиента
const getAsync = promisify(client.get).bind(client);
const setAsync = promisify(client.set).bind(client);
app.get('/user/:id', async (req, res) => {
const cacheKey = `user:${req.params.id}`;
try {
// Пробуем получить из Redis
const cachedUser = await getAsync(cacheKey);
if (cachedUser) return res.json(JSON.parse(cachedUser));
// Если нет в кэше, запрашиваем из БД
const user = await db.users.findByPk(req.params.id);
// Сохраняем в Redis на 10 минут
await setAsync(cacheKey, JSON.stringify(user), 'EX', 600);
res.json(user);
} catch (error) {
res.status(500).json({ error: 'Не удалось получить данные пользователя' });
}
}); |
|
Оптимизация статических ресурсов
Express отлично справляется с отдачей статических файлов, но есть способы сделать это ещё эффективнее:
| JavaScript | 1
2
3
4
5
6
7
8
9
| // Базовая настройка статики с кэшированием на стороне клиента
app.use(express.static('public', {
maxAge: '1d', // Кэширование на сутки
etag: true, // Поддержка условных запросов
lastModified: true
}));
// Для продакшена лучше использовать CDN или выделенный сервер статики
// например, Nginx, который эффективнее Express для этой задачи |
|
Сжатие ответов
Компрессия данных может значительно уменьшить объем передаваемого трафика:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| const compression = require('compression');
// Стандартное применение сжатия
app.use(compression());
// Продвинутая настройка с условной компрессией
app.use(compression({
// Порог в байтах (не сжимать маленькие ответы)
threshold: 1024,
// Сжимать только определенные типы контента
filter: (req, res) => {
const contentType = res.getHeader('Content-Type');
return /text|json|javascript|css/.test(contentType);
},
// Уровень компрессии (баланс CPU vs размер)
level: 6
})); |
|
Оптимизация JSON-сериализации
Для API, возвращающих большие JSON-объекты, стандартная сериализация может стать узким местом:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| app.get('/huge-dataset', async (req, res) => {
const data = await fetchMillionsOfRecords();
// Вместо прямой отправки JSON
// res.json(data); // Может блокировать event loop на секунды!
// Используем потоковую сериализацию
const { Readable } = require('stream');
const { stringify } = require('JSONStream');
res.setHeader('Content-Type', 'application/json');
Readable.from(data)
.pipe(stringify())
.pipe(res);
}); |
|
В следующих разделах мы углубимся в детали каждой из этих техник и рассмотрим, как их эффективно комбинировать для достижения максимальной производительности Express.js-приложений.
Кластеризация Node.js процессов
Кластеризация – одно из самых мощных средств повышения производительности Express.js, о котором часто забывают. Суть проста: вместо запуска одного процесса Node.js, мы создаём несколько, каждый обрабатывает запросы независимо. Это позволяет задействовать все ядра процессора и распределить нагрузку равномерно.
Продвинутая конфигурация кластера
Базовый пример с модулем cluster я уже показал выше, но в реальных проектах нужен более гибкий подход:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
| const cluster = require('cluster');
const os = require('os');
const express = require('express');
if (cluster.isMaster) {
// Кастомная логика определения числа воркеров
const numWorkers = process.env.NODE_ENV === 'production'
? os.cpus().length // Все доступные ядра на продакшене
: 2; // Минимум для разработки
console.log(`Запуск ${numWorkers} воркеров`);
// Отслеживание состояния воркеров
const workers = {};
// Создание воркеров
for (let i = 0; i < numWorkers; i++) {
const worker = cluster.fork();
workers[worker.id] = {
startTime: Date.now(),
requests: 0
};
// Обмен сообщениями с воркером
worker.on('message', msg => {
if (msg.cmd === 'REQUEST_PROCESSED') {
workers[worker.id].requests++;
}
});
}
// Ротация воркеров для предотвращения утечек памяти
setInterval(() => {
const workerId = Object.keys(workers)[0];
if (workerId && workers[workerId].requests > 10000) {
console.log(`Перезапуск воркера #${workerId} после 10000 запросов`);
cluster.workers[workerId].kill();
delete workers[workerId];
}
}, 60000);
// Перезапуск воркеров при падении
cluster.on('exit', (worker, code, signal) => {
console.log(`Воркер #${worker.id} упал. Код: ${code}, сигнал: ${signal}`);
delete workers[worker.id];
// Небольшая задержка перед перезапуском
setTimeout(() => {
const newWorker = cluster.fork();
workers[newWorker.id] = {
startTime: Date.now(),
requests: 0
};
}, 1000);
});
} else {
// Код воркера
const app = express();
// Настройка маршрутов...
// Отслеживание запросов для статистики
app.use((req, res, next) => {
const originalEnd = res.end;
res.end = function(...args) {
process.send({ cmd: 'REQUEST_PROCESSED' });
originalEnd.apply(this, args);
};
next();
});
app.listen(3000, () => {
console.log(`Воркер #${cluster.worker.id} слушает порт 3000`);
});
} |
|
Стратегии распределения нагрузки
Node.js использует два основных алгоритма распределения запросов:
1. Round-robin (по умолчанию) – запросы распределяются поочерёдно между воркерами. Простой и эффективный для большинства приложений.
2. Алгоритм на основе дескрипторов соединений – используется при установке опции `server.listen({port: 3000, handlersCount: numberOfWorkers})`. Более производительный для долгих соединений (WebSocket, HTTP/2).
Для дополнительной настройки можно использовать кастомное распределение:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
| // Мастер-процесс
if (cluster.isMaster) {
// ...создание воркеров
// Следим за загрузкой воркеров
const workerLoads = {};
// Получаем информацию о загрузке
Object.values(cluster.workers).forEach(worker => {
worker.on('message', msg => {
if (msg.cmd === 'LOAD_REPORT') {
workerLoads[worker.id] = msg.load;
}
});
});
// Периодически опрашиваем воркеры
setInterval(() => {
Object.values(cluster.workers).forEach(worker => {
worker.send({ cmd: 'REPORT_LOAD' });
});
}, 5000);
}
// Воркер
if (cluster.isWorker) {
// ...настройка приложения
// Отправка метрик загрузки
process.on('message', msg => {
if (msg.cmd === 'REPORT_LOAD') {
process.send({
cmd: 'LOAD_REPORT',
load: {
memory: process.memoryUsage(),
activeRequests: server.getConnections() // Требует трекинга соединений
}
});
}
});
} |
|
Стратегии кэширования
Кэширование – золотая пуля в борьбе за производительность Express-приложений. Правильно настроенный кэш может снизить нагрузку на сервер и базу данных в десятки раз. Но важно не просто внедрить кэширование, а подобрать оптимальную стратегию для конкретных сценариев.
Иерархическое многоуровневое кэширование
Наиболее эффективный подход – комбинирование нескольких уровней кэша с разными характеристиками:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| // Многоуровневый кэш: memory -> redis -> источник данных
const memoryCache = new NodeCache({ stdTTL: 60 }); // 1 минута в памяти
const redisClient = redis.createClient();
async function getDataWithCache(key) {
// Уровень 1: Сверхбыстрый memory-cache
const memData = memoryCache.get(key);
if (memData) return memData;
// Уровень 2: Redis-кэш
const redisData = await redisClient.getAsync(key);
if (redisData) {
// Обновляем memory-cache и возвращаем данные
const parsed = JSON.parse(redisData);
memoryCache.set(key, parsed);
return parsed;
}
// Уровень 3: Источник данных (БД, внешний API и т.д.)
const sourceData = await fetchFromDataSource(key);
// Обновляем оба уровня кэша
redisClient.setAsync(key, JSON.stringify(sourceData), 'EX', 300); // 5 минут в Redis
memoryCache.set(key, sourceData);
return sourceData;
} |
|
Стратегии инвалидации кэша
Самый сложный аспект кэширования – поддержание актуальности данных. Существует несколько стратегий:
1. TTL (Time To Live) – самая простая стратегия, но не гарантирует актуальность:
| JavaScript | 1
2
| // Данные живут в кэше 10 минут, затем считаются устаревшими
cache.set(key, data, 600); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
| // При обновлении данных в БД
app.put('/products/:id', async (req, res) => {
const product = await updateProduct(req.params.id, req.body);
// Инвалидируем связанные кэши
cache.del(`product:${req.params.id}`);
cache.del('products:list');
cache.del(`category:${product.categoryId}`);
res.json(product);
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
| // Сервис А (меняет данные)
function updateProduct(id, data) {
const product = await db.products.update(id, data);
eventBus.publish('product:updated', { id, product });
return product;
}
// Сервис Б (поддерживает кэш)
eventBus.subscribe('product:updated', (event) => {
cache.del(`product:${event.id}`);
// Другие связанные кэши...
}); |
|
Условное кэширование
Не всё стоит кэшировать. Персонализированный контент или секретные данные могут создать проблемы безопасности:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Кэшируем только для неавторизованных пользователей
app.get('/popular-articles', (req, res) => {
const cacheKey = req.user ? null : 'popular-articles';
if (cacheKey && cache.has(cacheKey)) {
return res.json(cache.get(cacheKey));
}
const articles = await articlesService.getPopular();
// Кэшируем только для анонимных пользователей
if (cacheKey) {
cache.set(cacheKey, articles, 600);
}
res.json(articles);
}); |
|
Потоковая передача данных и масштабирование
Работа с большими объёмами данных в Express.js может превратиться в настоящий ад, если не использовать потоковую передачу. Представьте, что ваше приложение читает гигабайтный файл целиком в память, а затем отдаёт его клиенту — это верный путь к исчерпанию оперативной памяти и падению сервера.
Мощь Node.js Streams
Streams (потоки) — один из самых недооценённых инструментов Node.js. Они позволяют обрабатывать данные по частям, избегая загрузки всего объёма в память:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Плохо: загружаем весь файл в память
app.get('/download/large-file', (req, res) => {
fs.readFile('./huge-file.csv', (err, data) => {
if (err) return res.status(500).send('Ошибка чтения файла');
res.send(data);
});
});
// Хорошо: потоковая передача без загрузки в память
app.get('/download/large-file', (req, res) => {
const fileStream = fs.createReadStream('./huge-file.csv');
fileStream.pipe(res);
fileStream.on('error', (error) => {
res.status(500).send('Ошибка чтения файла');
});
}); |
|
1. Обработки больших файлов (CSV, логи, видео).
2. Трансформации данных на лету (сжатие, шифрование).
3. Проксирования запросов к другим сервисам.
Трансформация данных в потоке
Мощная особенность потоков — возможность создавать цепочки трансформаций:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| const { Transform } = require('stream');
const zlib = require('zlib');
// Создаем трансформирующий поток
const upperCaseTransform = new Transform({
transform(chunk, encoding, callback) {
// Преобразуем данные в верхний регистр
this.push(chunk.toString().toUpperCase());
callback();
}
});
app.get('/transform-stream', (req, res) => {
// Цепочка потоков: чтение -> преобразование -> сжатие -> ответ
fs.createReadStream('data.txt')
.pipe(upperCaseTransform)
.pipe(zlib.createGzip()) // Сжимаем на лету
.pipe(res);
}); |
|
Горизонтальное масштабирование
Даже с кластеризацией, один сервер имеет физические ограничения. Для действительно высоких нагрузок необходимо горизонтальное масштабирование — добавление новых серверов:
1. Балансировка нагрузки — распределение запросов между несколькими экземплярами приложения. Часто используются Nginx, HAProxy или облачные балансировщики:
| JSON | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| # Пример конфигурации Nginx для балансировки
upstream express_backend {
server express1.local:3000;
server express2.local:3000;
server express3.local:3000;
}
server {
listen 80;
location / {
proxy_pass http://express_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
} |
|
| JSON | 1
2
3
4
5
6
| # Балансировка с поддержкой sticky sessions
upstream express_backend {
ip_hash; # Направляет запросы одного IP на один сервер
server express1.local:3000;
server express2.local:3000;
} |
|
В одном из моих проектов мы обрабатывали загрузку и конвертацию видеофайлов. Простая замена буферного подхода на потоковую обработку позволила уменьшить использование памяти на 85% и сократить время отклика на 40%. Кроме того, дополнительное горизонтальное масштабирование с балансировкой позволило легко справиться с пиковыми нагрузками без деградации производительности.
Оптимизация работы с базами данных
Нерациональное взаимодействие с базами данных — причина №1 медленных Express-приложений. Даже идеально написанный код мгновенно становится черепахой, если БД превращается в бутылочное горлышко. В отличие от других аспектов оптимизации, здесь ставки особенно высоки — одна неоптимальная выборка может положить всё приложение.
Эффективность запросов начинается с индексов
Индексы — тот случай, когда одно небольшое изменение может ускорить запрос в сотни раз. Рассмотрим типичную ситуацию:
| JavaScript | 1
2
3
4
5
6
7
8
9
| // Наивный запрос без учёта индексов
app.get('/users/search', async (req, res) => {
const users = await User.findAll({
where: {
email: { [Op.like]: [INLINE]%${req.query.email}%[/INLINE] }
}
});
res.json(users);
}); |
|
LIKE '%...%' заставит БД выполнить полное сканирование таблицы — настоящее преступление против производительности при большом объёме данных.
Улучшенный вариант с учетом индексов:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
| // Оптимизированный запрос с использованием индексов
app.get('/users/search', async (req, res) => {
// Используем префиксный поиск, работающий с индексами
const users = await User.findAll({
where: {
email: { [Op.like]: [INLINE]${req.query.email}%[/INLINE] } // Без % в начале!
},
limit: 100 // Всегда ограничивайте выборку
});
res.json(users);
}); |
|
Connection Pooling — фундамент масштабируемости
Открытие соединения с БД — дорогостоящая операция. Если каждый запрос будет создавать и закрывать соединение, производительность улетит в пропасть:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| // Антипаттерн: новое соединение на каждый запрос
app.get('/data', async (req, res) => {
const connection = await mysql.createConnection({
host: 'localhost',
user: 'root',
password: 'password',
database: 'mydb'
});
const [rows] = await connection.execute('SELECT * FROM data');
await connection.end(); // Закрываем соединение
res.json(rows);
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| // Создаём пул при инициализации
const pool = mysql.createPool({
host: 'localhost',
user: 'root',
password: 'password',
database: 'mydb',
waitForConnections: true,
connectionLimit: 10, // Адаптируйте под ваши нужды
queueLimit: 0
});
app.get('/data', async (req, res) => {
// Соединение берётся из пула и возвращается обратно автоматически
const [rows] = await pool.execute('SELECT * FROM data');
res.json(rows);
}); |
|
connectionLimit = numCPUs * 2 + количество_дисков.
Многоуровневое кэширование запросов
Лучший запрос — тот, который не нужно выполнять. Кэширование результатов запросов работает как НОС-турбо для бэкенда:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| const cache = new NodeCache({ stdTTL: 300 }); // 5 минут
app.get('/products/popular', async (req, res) => {
const cacheKey = 'popular_products';
// Проверяем кэш
const cachedData = cache.get(cacheKey);
if (cachedData) return res.json(cachedData);
// Выполняем тяжелый запрос с JOIN и GROUP BY
const products = await db.query(`
SELECT p.*, COUNT(o.id) as order_count
FROM products p
JOIN order_items oi ON p.id = oi.product_id
JOIN orders o ON oi.order_id = o.id
WHERE o.created_at > NOW() - INTERVAL 7 DAY
GROUP BY p.id
ORDER BY order_count DESC
LIMIT 10
`);
// Сохраняем в кэш и отвечаем
cache.set(cacheKey, products);
res.json(products);
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
| // При изменении товара
app.put('/products/:id', async (req, res) => {
// Обновляем товар
const product = await updateProduct(req.params.id, req.body);
// Инвалидируем связанные кэши
cache.del('popular_products');
cache.del(`product_${req.params.id}`);
cache.del(`category_products_${product.categoryId}`);
res.json(product);
}); |
|
Batch-операции вместо циклов
Одна из распространенных ошибок — выполнение запросов в цикле. Замените:
| JavaScript | 1
2
3
4
5
6
| // Плохо: N запросов для N пользователей
async function deactivateInactiveUsers(userIds) {
for (const id of userIds) {
await db.query('UPDATE users SET active = false WHERE id = ?', [id]);
}
} |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
| // Хорошо: 1 запрос для N пользователей
async function deactivateInactiveUsers(userIds) {
// Защита от SQL-инъекций при динамическом IN
const placeholders = userIds.map((_, i) => `$${i+1}`).join(',');
await db.query(
[INLINE]UPDATE users SET active = false WHERE id IN (${placeholders})[/INLINE],
userIds
);
} |
|
Тонкая настройка connection pooling
Connection pooling требует балансировки нескольких параметров:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| // Расширенная конфигурация пула для PostgreSQL
const pool = new Pool({
host: DB_HOST,
user: DB_USER,
password: DB_PASSWORD,
database: DB_NAME,
max: 20, // Максимум соединений
min: 5, // Минимум поддерживаемых открытых соединений
idleTimeoutMillis: 30000, // Закрывать после 30 сек простоя
connectionTimeoutMillis: 2000, // Таймаут подключения
// Кастомная фабрика клиентов
Client: CustomPgClient,
// Обработчик ошибок на уровне пула
async error(err, client) {
console.error('Ошибка клиента пула:', err);
// Проверка жизнеспособности соединения
try {
await client.query('SELECT 1');
} catch (e) {
// Закрываем повреждённое соединение
client.release(true);
}
}
}); |
|
max = (cpu_cores * 2) + number_of_disks. Но лучше проводить нагрузочное тестирование для определения оптимума.
Мониторинг запросов в реальном времени
Добавьте логирование медленных запросов для выявления проблем:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| // Middleware для отслеживания медленных запросов
function trackQueryPerformance(query, params) {
const start = process.hrtime.bigint();
return pool.query(query, params)
.then(result => {
const duration = Number(process.hrtime.bigint() - start) / 1000000;
if (duration > 100) { // Логируем запросы дольше 100 мс
console.warn(`Медленный запрос (${duration.toFixed(2)} мс): ${query}`);
// Сохраняем в специальную таблицу для анализа
logSlowQuery(query, params, duration);
}
return result;
});
} |
|
.release() в обработчике ошибок, который медленно "съедал" все доступные соединения. Добавление мониторинга и автоматического закрытия "зависших" соединений старше 5 минут полностью решило проблему.
Оптимизация ORM и пакетная обработка
ORM-библиотеки вроде Sequelize и Mongoose существенно упрощают работу с базами данных, но за это удобство часто приходится платить производительностью. Без правильной настройки даже самая быстрая БД становится "черепахой" в сочетании с ORM.
Проблемные паттерны в Sequelize
Одна из самых коварных проблем Sequelize — N+1 запросы. Они возникают, когда вы получаете список объектов, а затем для каждого объекта делаете дополнительный запрос:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
| // Плохо: N+1 запросов
app.get('/posts', async (req, res) => {
const posts = await Post.findAll();
// Для каждого поста отдельный запрос на получение автора
for (const post of posts) {
post.author = await User.findByPk(post.authorId);
}
res.json(posts);
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
| // Хорошо: всего 1 запрос с JOIN
app.get('/posts', async (req, res) => {
const posts = await Post.findAll({
include: [{ model: User, as: 'author' }]
});
res.json(posts);
}); |
|
Оптимизация Mongoose
MongoDB по природе документоориентирован, но это не значит, что вложенные запросы не могут стать проблемой:
| JavaScript | 1
2
| // Неоптимально: загружаем все поля и всю коллекцию
const users = await User.find({}); |
|
| JavaScript | 1
2
3
4
5
| // Оптимально: запрашиваем только нужные поля активных пользователей
const activeUsers = await User.find(
{ active: true },
{ name: 1, email: 1, lastLogin: 1 }
).lean(); // lean() возвращает обычные объекты вместо документов Mongoose |
|
.lean() критически важен для производительности — он исключает создание тяжелых объектов Mongoose, когда вам нужны только данные.
Пакетная обработка для массовых операций
Обработка больших наборов данных поштучно убивает производительность. Представьте импорт 10,000 товаров:
| JavaScript | 1
2
3
4
5
6
| // Катастрофа: 10,000 отдельных INSERT-запросов
async function importProducts(products) {
for (const product of products) {
await Product.create(product);
}
} |
|
| JavaScript | 1
2
3
4
5
6
| // Намного лучше: один массовый INSERT
async function importProducts(products) {
await Product.bulkCreate(products, {
updateOnDuplicate: ['name', 'price', 'stock'] // Для upsert
});
} |
|
| JavaScript | 1
2
| // Эффективная пакетная вставка в MongoDB
await Product.insertMany(products); |
|
Отложенная загрузка vs Предзагрузка
Для больших наборов данных вместо загрузки всего сразу используйте пагинацию и курсоры:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Пагинация в Sequelize
const LIMIT = 100;
app.get('/users', async (req, res) => {
const page = parseInt(req.query.page) || 1;
const users = await User.findAndCountAll({
limit: LIMIT,
offset: (page - 1) * LIMIT,
order: [['createdAt', 'DESC']]
});
res.json({
users: users.rows,
total: users.count,
pages: Math.ceil(users.count / LIMIT)
});
}); |
|
При работе с очень большими коллекциями в MongoDB используйте потоковую обработку вместо загрузки всех документов:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // Обработка миллионов документов без перегрузки памяти
app.get('/export/users', (req, res) => {
res.setHeader('Content-Type', 'application/json');
res.write('[');
let first = true;
User.find().cursor()
.on('data', (user) => {
if (!first) res.write(',');
res.write(JSON.stringify(user));
first = false;
})
.on('end', () => {
res.write(']');
res.end();
});
}); |
|
Мониторинг и профилирование
Любые оптимизации без измерений — всё равно что стрельба из лука с завязанными глазами. Можете потратить недели на тюнинг приложения, но так и не узнать, принесло ли это реальную пользу. Мониторинг и профилирование — те самые глаза, которые позволяют видеть происходящее с вашим Express.js сервером в реальном времени.
Встроенные инструменты Node.js
Node.js предоставляет базовые, но мощные инструменты диагностики:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| // Собираем базовую метрику производительности
app.use((req, res, next) => {
const start = process.hrtime();
res.on('finish', () => {
const [seconds, nanoseconds] = process.hrtime(start);
const ms = seconds * 1000 + nanoseconds / 1000000;
console.log(`${req.method} ${req.originalUrl} - ${ms.toFixed(2)}ms`);
// Отправляем метрику в систему мониторинга
metrics.recordResponseTime(req.route?.path || req.path, ms);
});
next();
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| // Запуск профайлера CPU на 30 секунд
const profiler = require('v8-profiler-next');
const fs = require('fs');
app.get('/debug/cpu-profile', (req, res) => {
// Защитите этот endpoint в production!
if (req.query.secret !== process.env.PROFILE_SECRET) {
return res.status(403).send('Forbidden');
}
// Начинаем профилирование
profiler.startProfiling('CPU Profile');
// Останавливаем через 30 секунд
setTimeout(() => {
const profile = profiler.stopProfiling();
// Сохраняем результат в файл
profile.export((error, result) => {
fs.writeFileSync('cpu-profile.cpuprofile', result);
profile.delete();
console.log('Профиль CPU сохранен');
});
}, 30000);
res.send('Профилирование запущено на 30 секунд');
}); |
|
Выявление узких мест
Одна из самых недооценёных техник диагностики — flamegraph (пламенный график). Он наглядно показывает, где именно ваше приложение проводит больше всего времени:
| Bash | 1
2
3
4
5
| # Установка clinic.js
npm install -g clinic
# Генерация flamegraph
clinic flame -- node app.js |
|
Для долгосрочного мониторинга я рекомендую вести журнал медленных операций:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| // Логирование медленных маршрутов
app.use((req, res, next) => {
const start = process.hrtime();
onFinished(res, () => {
const [seconds, nanoseconds] = process.hrtime(start);
const ms = seconds * 1000 + nanoseconds / 1000000;
if (ms > 200) { // Логируем "медленные" запросы
console.warn(`Медленный запрос: ${req.method} ${req.originalUrl} - ${ms.toFixed(2)}ms`);
// Здесь можно отправить алерт или сохранить для анализа
}
});
next();
}); |
|
Визуализация и анализ метрик
Цифры важны, но графики гораздо нагляднее демонстрируют тренды. На проде я всегда использую визуализацию ключевых метрик:- Время отклика (мин/макс/средн/медиана/процентили).
- Количество запросов в секунду.
- Потребление памяти и CPU.
- Количество ошибок.
Графики помогают заметить деградацию производительности ещё до того, как она станет критичной. Например, постепенный рост использования памяти может указывать на утечку, даже если приложение ещё работает нормально.
APM-системы и оптимизация логирования
Самые хитрые проблемы производительности проявляются непредсказуемо и исчезают при попытке отладки — классический пример неопределённости Шрёдингера в мире разработки. Здесь на помощь приходят APM-системы (Application Performance Monitoring), которые работают как чёрный ящик в самолёте — непрерывно записывают всё происходящее, чтобы потом можно было разобраться в причинах "крушения".
APM-системы: глаза и уши вашего приложения
New Relic, Datadog, Elastic APM, Dynatrace — все эти инструменты выполняют одну ключевую функцию: автоматически отслеживают производительность вашего приложения во всех измерениях:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
| // Интеграция New Relic в Express
require('newrelic');
const express = require('express');
const app = express();
// Теперь каждый маршрут автоматически отслеживается
app.get('/api/products', async (req, res) => {
// Дополнительная кастомная метрика
newrelic.addCustomAttribute('productCount', await getProductCount());
// ...остальной код
}); |
|
Однако за удобство приходится платить — APM-агенты добавляют оверхэд к производительности. В одном из моих проектов внедрение Datadog снизило максимальную пропускную способность на 7%. Стоило ли это того? Однозначно да, потому что за первую же неделю мы нашли и устранили проблему, замедлявшую всё приложение на 23%.
Оптимизация логирования — недооценённый фактор
Логирование необходимо для отладки, но может стать убийцей производительности. Вы удивитесь, насколько часто именно логи становятся узким местом в высоконагруженных системах:
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| // Плохо: блокирующее логирование на каждый запрос
app.use((req, res, next) => {
console.log(JSON.stringify({
time: new Date(),
method: req.method,
url: req.url,
headers: req.headers,
body: req.body // Логирование всего тела запроса
}));
next();
});
// Лучше: асинхронное логирование с фильтрацией чувствительных данных
app.use((req, res, next) => {
const logData = {
time: new Date(),
method: req.method,
url: req.url,
contentLength: req.headers['content-length']
};
// Асинхронная запись в файл без блокировки event loop
process.nextTick(() => logger.info(logData));
next();
}); |
|
| JavaScript | 1
2
3
4
5
6
7
8
| const pino = require('pino');
const logger = pino({
level: process.env.NODE_ENV === 'production' ? 'info' : 'debug',
transport: {
target: 'pino/file',
options: { destination: 'app.log' }
}
}); |
|
Модуль express-orm-mvc
Нашел модуль express-orm-mvc, он организует паттерн mvc. Вопросы:
1) Насколько он быстрый?... Авторизация на node.js express+passportjs
Хочу вот написать простую авторизацию с помощью passport.
Полазил по интернету, поискал инфу и... Правильный ли подход к разработке на NodeJS с Express?
Итак, как выглядит проект, начинаем с app.js и заканчиваем темплейтом ejs:
1. Все конфиги,... Node.js(Express.js + Sequelize.js ORM): Не получается выполнить правильный запрос
Есть приложение на основе Express. База данных - postgresql, ORM - Sequelize. Это обработчик... "express" не является внутренней или внешней командой, исполняемой программой или пакетным файлом
добрый день
Изучаю node js по урокам Ильи https://learn.javascript.ru/nodejs-screencast
Делаю... Express - получение данных с клиента
Привет, отправляю аяксом пост запрос и посылаю данные в виде джейсона
Не могу понять как теперь... Nodejs express и passportjs
Здравствуйте! Есть такая схема mongoose
var mongoose = require('mongoose');
module.exports =... Express post-обработка
Доброй ночи =)
Делаю сервер на JS + Express;
app.js
var express = require("express");
var... Перезагрузка Express-сервера самим сервером
Как мне из скрипта а) его завершить, б) перезагрузить?
Предполагается, что в скрипте запущен... Express-session установка cookie на разных доменах
При заходе на сайт index.php создается сессия на сервере успешно при обновлении страницы она... Как прально организовать render шаблонов в express
Добрый день,
Не могу понять как правильно делать render, к примеру на сайте нужно выводить... Как установить express на хостинге
Доброго времени суток!
не понимаю как установить express на хостинге.
Есть под домен (например...
|
