Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Với nội dung sinh dần, Content-Length buộc server sinh hết rồi mới gửi được (byte đầu ~530ms), còn chunked stream từng khối (~105ms) — nhanh gấp 5 lần tới byte đầu. Nhưng dán đúng header mà vẫn buffer hết thì streaming bốc hơi hoàn toàn. Đo thật, kèm hợp đồng ba bên của streaming.
pgbench cho tôi 203189 tps read-only và tôi mừng rơn. Nhưng con số đó gần như vô nghĩa cho production: không ghi, đĩa VM fsync gần như miễn phí, 150MB nằm gọn trong RAM. Đổi bất kỳ điều kiện nào về phía thật là tps sụp mười mươi. Cách đo tải đúng với pgbench, và vì sao một con số thiếu điều kiện là một con số nói dối.
INSERT rồi COMMIT xong, tôi đinh ninh dữ liệu đã nằm an toàn trong file trên đĩa. Đo pg_buffercache mới ngã ngửa: 16320 trang vẫn bẩn trong shared_buffers, chưa hề chạm file data. Cái làm COMMIT bền là WAL fsync; trang data xuống đĩa muộn hơn, cả lô ở checkpoint — một cú bùng I/O 79ms. Vì sao max_wal_size nhỏ làm CSDL giật, và cách làm phẳng.
O(n log n) tốt hơn O(n²) — nên tôi định dùng merge sort cho mọi trường hợp. Nhưng đo ra ở n=64 insertion sort nhanh hơn (292 so 375 ns) vì hằng số ẩn. Big-O là hình dạng đường cong khi n tiến vô cùng, không phải tốc độ ở n cụ thể; phải đo cả đường cong, không đo một điểm. Tôi đo bằng C.
Thử lại ngay dội 2000 request vào một server chỉ lỗi 2 giây, đủ giết nó. Tôi tưởng exponential backoff là đủ. Nhưng backoff KHÔNG jitter vẫn khiến 50 client thử lại thành từng đợt ~50 gói đồng bộ ở giây 1, 2, 4, 8 — jitter mới tãi chúng ra mượt. Đo thật với 50 client.
Thấy EXPLAIN ghi read=12760, tôi đinh ninh 12760 trang đó lôi từ đĩa lên nên hẳn phải chậm. Nhưng thời gian 17ms ổn định y hệt suốt ba lần quét — chúng do OS page cache phục vụ từ RAM, không phải đĩa. 'read' chỉ nghĩa là 'không có trong shared_buffers', không phải 'từ đĩa'. Đo tận mắt hai tầng cache, và vì sao shared_buffers to hết cỡ lại chậm hơn.