Bạn tối ưu hiệu năng NestJS như thế nào?

Question

Accepted Answer

Tối ưu hiệu năng NestJS trải rộng qua **lựa chọn HTTP adapter** (Express vs Fastify), hiệu quả database, caching, và các thực hành Node.js chung. Như mọi khi: **profile để tìm bottleneck thực sự** — thường là database hoặc I/O, không phải bản thân NestJS.

## Chuyển sang Fastify cho throughput cao hơn

```ts
// NestJS hỗ trợ Fastify như một thay thế cho Express adapter mặc định
import { FastifyAdapter } from "@nestjs/platform-fastify";

const app = await NestFactory.create(AppModule, new FastifyAdapter());
// Fastify nhanh hơn Express đáng kể (~2x trong benchmark) với CÙNG code NestJS
```

Vì NestJS **không phụ thuộc nền tảng**, bạn có thể hoán đổi Express lấy **Fastify** — thường nhanh hơn khoảng 2x cho HTTP throughput — thường không cần thay đổi code ứng dụng. Một thắng lợi dễ dàng cho các API throughput cao.

## Database thường là bottleneck thực sự

```ts
// ❌ N+1 query — lấy dữ liệu liên quan trong một vòng lặp (kẻ giết hiệu năng phổ biến nhất)
for (const user of users) {
  user.posts = await postsRepo.findByUser(user.id);   // 1 query mỗi user!
}

// ✅ eager load / join / gộp trong MỘT query
const users = await usersRepo.find({ relations: ["posts"] });
```

```text
Tối ưu database (các thắng lợi thực sự lớn nhất cho hầu hết API):
  ✓ Sửa N+1 query (dùng join/relation/DataLoader)
  ✓ Thêm index cho các query chậm
  ✓ Chỉ select các cột cần thiết; phân trang các tập kết quả lớn
  ✓ Dùng connection pooling
```

## Cache các thao tác tốn kém

```ts
@UseInterceptors(CacheInterceptor)   // cache các endpoint nhiều đọc (in-memory hoặc Redis)
// hoặc caching thủ công các query/tính toán tốn kém
```

Caching (với Redis cho nhiều instance) tránh lặp lại công việc tốn kém — một trong những tối ưu hóa tác động cao nhất.

## Async/concurrency và gỡ bỏ

```ts
// song song hóa các thao tác async độc lập
const [users, products] = await Promise.all([getUsers(), getProducts()]);

// gỡ bỏ công việc CPU nặng sang queue/worker (đừng chặn event loop)
await this.queue.add("process-image", data);
```

Song song hóa các I/O độc lập với `Promise.all`, và gỡ bỏ công việc nặng về CPU sang các queue/worker trong nền để nó không chặn event loop đơn luồng của Node.

## Các kỹ thuật khác

```text
✓ Bật compression (gzip/brotli) cho response
✓ Dùng streaming cho payload/file lớn
✓ Scale ngang (nhiều instance + load balancer; cluster/PM2)
  — giữ ứng dụng KHÔNG TRẠNG THÁI (session/cache trong Redis, không phải bộ nhớ process)
✓ Lazy-load các module khi phù hợp; tối thiểu hóa công việc khởi động
✓ Profile với clinic.js / node --prof để tìm các hotspot thực tế
```

## Đo lường trước

```text
Đừng đoán. Profile (clinic.js, autocannon để load testing) để tìm bottleneck
THỰC SỰ — với hầu hết API đó là database hoặc I/O bên ngoài, không phải code Nest/Node.
```

## Tại sao điều này quan trọng

Tối ưu hiệu năng là giá trị để xây dựng các service NestJS có khả năng mở rộng, và hiểu các lựa chọn là kiến thức cấp senior quan trọng — nhưng nó phải dựa trên **đo lường** (profile để tìm bottleneck thực tế, mà với hầu hết API là database hoặc I/O chứ không phải bản thân NestJS).

Một số kỹ thuật đặc thù NestJS và chung quan trọng: **Fastify adapter** cung cấp một thắng lợi HTTP-throughput dễ dàng, đáng kể (khoảng 2x) nhờ NestJS không phụ thuộc nền tảng, thường không cần thay đổi code; **tối ưu database** (sửa N+1 query, lập index, phân trang, pooling) mang lại các thắng lợi thực tế lớn nhất vì database thường là bottleneck thực sự; **caching** (in-memory hoặc Redis) tránh lặp lại công việc tốn kém; **song song hóa** các thao tác async độc lập và **gỡ bỏ công việc nặng về CPU sang queue** giữ cho event loop đơn luồng của Node phản hồi nhanh; và **scale ngang** (với một ứng dụng không trạng thái và trạng thái dùng chung được Redis hỗ trợ) xử lý tải cao.

Biết bộ công cụ này — và đặc biệt là kỷ luật profile trước, nhắm vào bottleneck thực sự (thường là DB), và áp dụng đúng fix thay vì đoán hoặc micro-optimize quá sớm — là điều cho phép bạn xây dựng các ứng dụng NestJS nhanh, có khả năng mở rộng.

Nó phản ánh cách tiếp cận trưởng thành, có hệ thống với hiệu năng vốn phân biệt các lập trình viên senior và là một chủ đề phổ biến, quan trọng về mặt thực tế cho công việc back-end production.