CPU-bound vs I/O-bound work

Node силён в конкурентном I/O-bound — много ожиданий сети/диска на одном потоке. CPU-bound JS (парсинг огромного JSON, resize в JS, тяжёлая агрегация) блокирует event loop и бьёт по всем клиентам.

| Узкое место | Симптомы | Меры | |------------|----------|-------------| | I/O-bound | Ожидание БД/API/диска | Async API, пулы, кэш, батчинг | | CPU-bound (JS) | Скачки delay event loop | Worker threads, native, отдельный сервис | | CPU-bound (libuv sync) | Очередь thread pool | Меньше параллелизма, native, осторожно больший пул |

Сначала измерьте: утилизация event loop, delay через `perf_hooks`, p99 под нагрузкой.

					// Плохо: блокирует все запросы на 200ms
const sorted = hugeArray.sort(expensiveCompare);

// Лучше: worker или чанки с yield через setImmediate
				

На интервью: классифицируйте нагрузку; почему больше workers в cluster — throughput, но не CPU одного запроса на worker.

Типовые ошибки: `JSON.parse` мегабайт на main thread; катастрофический backtracking regex; реплики без устранения блокировок loop.

Компромисс — между простотой, производительностью, безопасностью и эксплуатацией: назовите, что оптимизировали и какую цену приняли.

Чеклист:

• Профиль: CPU vs I/O.
• Тяжёлое вычисление с main thread.
• Кэш для read-heavy I/O.
• Лимиты размера payload на edge.