Tại sao phải Benchmark thay vì chỉ nhìn vào thông số RAM/CPU?
Lúc mới bắt đầu làm các hệ thống Core hay E-commerce có lượng truy cập lớn, mình luôn đau đầu với câu hỏi: “Con Database này chịu tải được bao nhiêu giao dịch mỗi giây trước khi sập?”. Đọc tài liệu của hãng thì lúc nào cũng thấy quảng cáo rất kêu, nhưng khi đưa vào môi trường thực tế với hàng nghìn query lồng chéo, mọi thứ khác xa hoàn toàn.
Sau khoảng 6 tháng ròng rã tối ưu hiệu năng cho cả SQL Server và PostgreSQL chạy trên Ubuntu Server, mình nhận ra rằng việc chạy Benchmark không chỉ để khoe con số, mà để tìm ra “điểm gãy” của hệ thống. HammerDB là công cụ mình tin tưởng nhất hiện nay để giả lập kịch bản TPC-C (giao dịch bán hàng thực tế) vì nó hoàn toàn miễn phí, open-source và cực kỳ khắt khe.
Khái niệm cốt lõi: TPC-C, TPM và NOPM là gì?
Trước khi bắt tay vào gõ lệnh, bạn cần nắm rõ những chỉ số mà HammerDB sẽ trả về, nếu không bạn sẽ bị lạc giữa một rừng số liệu.
- TPC-C: Đây là một tiêu chuẩn công nghiệp mô phỏng hoạt động của một công ty bán buôn. Nó không chỉ là đọc (Read) hay ghi (Write) đơn thuần, mà là sự kết hợp của đặt hàng, thanh toán, kiểm tra kho và giao hàng.
- TPM (Transactions Per Minute): Tổng số giao dịch mỗi phút. Chỉ số này ở SQL Server thường rất cao vì nó đếm cả các lệnh nội bộ, trong khi PostgreSQL lại đếm khác.
- NOPM (New Orders Per Minute): Đây mới là con số “vàng”. Nó đo lường số lượng đơn hàng mới được xử lý thành công. Khi so sánh hiệu năng giữa hai hệ quản trị cơ sở dữ liệu (DBMS) khác nhau, mình luôn nhìn vào NOPM để đảm bảo tính công bằng.
Chuẩn bị môi trường trên Linux
Mình thường cài HammerDB trực tiếp trên một máy Client (hoặc máy ảo riêng) cùng dải mạng với Database Server để tránh việc tiêu tốn tài nguyên của chính con DB đang cần test.
Tải và giải nén HammerDB (phiên bản 4.9 tại thời điểm mình viết bài này):
wget https://github.com/TPC-Council/HammerDB/releases/download/v4.9/HammerDB-4.9-Linux.tar.gz
tar -zxvf HammerDB-4.9-Linux.tar.gz
cd HammerDB-4.9
Để chạy được giao diện đồ họa trên Linux, bạn cần cài đặt thư viện X11, nhưng thực tế mình hay dùng chế độ CLI (command line) thông qua file script để tự động hóa quá trình test.
Thực hành Benchmark PostgreSQL
Với PostgreSQL, điều quan trọng nhất là bạn phải cấu hình file postgresql.conf ổn định trước khi test. Mình đã từng quên tăng max_connections và kết quả là HammerDB báo lỗi ngay khi vừa nâng số Virtual Users lên 50.
Bước 1: Tạo Schema và nạp dữ liệu mẫu
Bạn mở HammerDB (giao diện GUI hoặc dùng ./hammerdbcli). Ở đây mình ví dụ các bước logic:
- Chọn Benchmark: PostgreSQL -> TPC-C.
- Vào mục Schema Build: Thiết lập số lượng Warehouses. Đây là độ lớn của database. Ví dụ: 100 Warehouses tương đương khoảng 10GB dữ liệu.
- Nhấn Build và đợi. Quá trình này khá tốn I/O đĩa cứng.
Bước 2: Chạy Driver Script
Sau khi nạp xong dữ liệu, bạn cần cấu hình Driver Script để chỉ định cách test:
# Ví dụ cấu hình trong HammerDB CLI
dbset db pg
dbset bm tpcc
display adconf
vuset logot 1
vuset numvu 10 # Số lượng người dùng ảo song song
Thực hành Benchmark SQL Server trên Linux
Nhiều người vẫn nghĩ SQL Server chỉ chạy tốt trên Windows, nhưng trải nghiệm của mình với bản 2019/2022 trên Ubuntu cực kỳ ấn tượng. Tuy nhiên, để HammerDB kết nối được, bạn cần cài đặt thêm driver ODBC của Microsoft trên máy chạy HammerDB.
# Cài đặt Microsoft ODBC Driver trên Ubuntu
sudo su
curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
curl https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/prod.list > /etc/apt/sources.list.d/mssql-release.list
exit
sudo apt-get update
sudo ACCEPT_EULA=Y apt-get install -y msodbcsql18
Khi cấu hình HammerDB cho SQL Server, hãy chú ý mục Authentication. Nếu bạn dùng user sa, hãy chắc chắn rằng SQL Server đã bật chế độ Mixed Mode Authentication.
Kinh nghiệm thực tế: Những lỗi dễ mắc phải
Sau nhiều lần ngồi đợi cả tiếng đồng hồ để rồi nhận được kết quả sai lệch, mình rút ra được vài kinh nghiệm xương máu:
- Quên Warm-up: Đừng bao giờ lấy kết quả của lần chạy đầu tiên. Database cần thời gian để nạp dữ liệu vào Buffer Pool (RAM). Mình luôn chạy nháp 5-10 phút trước khi bắt đầu đo thật.
- Số lượng Warehouses quá ít: Nếu bạn test với 100 Virtual Users mà chỉ có 1 Warehouse, hiện tượng tranh chấp (Locking) sẽ xảy ra liên tục. Quy tắc của mình là số Warehouse nên gấp ít nhất 10 lần số Virtual Users để phản ánh đúng hiệu năng xử lý song song.
- Không dọn dẹp sau khi test: Mỗi lần chạy Benchmark, dữ liệu trong các bảng như
ORDERS,ORDER_LINEsẽ phình to ra. Hãy nhớ xóa và rebuild schema nếu muốn có một kết quả khách quan cho lần cấu hình tiếp theo.
Phân tích kết quả: Chọn PostgreSQL hay SQL Server?
Khi bạn nhấn nút Run, HammerDB sẽ vẽ biểu đồ biến thiên của TPM theo thời gian. Đừng quá chú trọng vào đỉnh (Peak), hãy nhìn vào đường trung bình. Nếu đường biểu đồ nhảy lên xuống như răng cưa, chứng tỏ hệ thống của bạn đang bị nghẽn cổ chai ở Disk I/O hoặc CPU đang bị quá tải nhiệt.
Trong một dự án mình từng làm, PostgreSQL cho chỉ số NOPM rất ổn định ở mức tải trung bình, nhưng khi đẩy lên cực hạn (hàng nghìn VU), SQL Server trên Linux lại giữ nhịp tốt hơn nhờ cơ chế quản lý bộ nhớ đệm rất hiệu quả. Tuy nhiên, PostgreSQL lại thắng thế về chi phí và khả năng tùy biến sâu vào kernel.
Kết luận
Sử dụng HammerDB không khó, cái khó là cách bạn thiết lập kịch bản sao cho sát với thực tế nhất. Đừng chỉ tin vào những bài review trên mạng, hãy tự mình chạy benchmark trên chính hạ tầng (Server, Storage, Network) mà bạn đang có. Chỉ khi cầm trong tay con số NOPM thực tế, bạn mới có đủ tự tin để tư vấn cho sếp hoặc khách hàng về khả năng mở rộng của hệ thống trong tương lai.
