Phần trước đo được thông lượng PostgreSQL đạt đỉnh ở đúng số lõi CPU. PgBouncer là câu trả lời khi ứng dụng có nhiều máy chủ — nó nhồi 300 client vào 17 kết nối. Nhưng chế độ transaction có một cái giá không phải hiệu năng: trạng thái phiên của một client rò sang client khác.
'Tỉ lệ trúng đệm phải trên 99%' là một trong những lời khuyên được lặp nhiều nhất về PostgreSQL. Tôi đo xem nó thật sự nói lên điều gì: 19.184 trang bị đánh dấu 'read' chỉ tốn 27,75 ms — 1,4 micro giây mỗi trang, tức tốc độ bộ nhớ, vì có một lớp đệm mà con số đó không nhìn thấy.
'Truy vấn tràn ra đĩa thì tăng work_mem' là lời khuyên có trong mọi bài tinh chỉnh PostgreSQL. Tôi đo nó trên ba loại thao tác và cả ba đều đi ngược — cấu hình có ghi tệp tạm lại nhanh hơn cấu hình chạy hết trong bộ nhớ, vì nút thắt không nằm ở dung lượng RAM.
WAL là nhật ký ghi trước, lý do PostgreSQL sống sót sau mất điện. Tôi đo nó sinh ra bao nhiêu cho mỗi thao tác, và tìm ra một cấu hình phổ biến làm mọi thứ tệ đi theo cách ngược đời: hạ giới hạn để tiết kiệm đĩa lại đóng một vòng lặp khiến tốn nhiều đĩa hơn.
Phần trước đo WAL sinh ra bao nhiêu; phần này đo chuyện xảy ra khi PostgreSQL đẩy tất cả xuống đĩa. Kết quả bất ngờ: cấu hình có nhiều checkpoint nhất lại mượt nhất — và con số trung bình mà mọi bảng theo dõi hiển thị giấu sạch mười giây người dùng thấy hệ thống đứng.
Tắt synchronous_commit cho 3,42 lần thông lượng. Tắt fsync không nhanh hơn chút nào — mà rủi ro thì thuộc một loại khác hẳn. Tôi đo cả bốn mức độ bền, và chỉ ra vì sao hai cái núm trông giống nhau thật ra là hai canh bạc rất khác nhau.