Phần mềm quản lý hiếm khi chậm vì thiếu máy chủ. Nó chậm vì vài truy vấn viết vội, vài màn hình tải quá nhiều dữ liệu, và vì không ai đo trước khi sửa. Bài viết đi từ lớp gần dữ liệu nhất ra ngoài, theo đúng thứ tự nên xử lý.
Bước 0 — Đo trước khi sửa
Tối ưu dựa trên cảm giác là cách nhanh nhất để mất thời gian. Cần biết ba con số trước khi chạm vào mã: yêu cầu nào chậm nhất, chậm ở phần nào (truy vấn dữ liệu, xử lý, truyền tải), và tần suất của nó.
Công cụ tối thiểu: ghi lại thời gian xử lý của từng thao tác, thống kê truy vấn tốn tài nguyên nhất ở phía cơ sở dữ liệu, và xem thời gian tải trang trên trình duyệt. Một thao tác chạy 3 giây nhưng mỗi ngày dùng một lần ít quan trọng hơn thao tác 300 mili giây chạy hàng nghìn lần.
1. Truy vấn — nơi chiếm phần lớn thời gian
Bốn vấn đề chiếm đa số trường hợp trong thực tế:
- Truy vấn lồng trong vòng lặp. Lấy danh sách rồi với mỗi dòng lại gọi thêm một truy vấn. Một trang 50 dòng biến thành 51 lượt đi về cơ sở dữ liệu. Cách chữa: lấy dữ liệu liên quan trong cùng một lần, hoặc nạp trước theo lô.
- Lấy nhiều cột hơn cần. Màn hình danh sách chỉ hiện sáu cột nhưng truy vấn kéo về toàn bộ thực thể, kể cả trường ghi chú dài. Cách chữa: chiếu (project) thẳng sang đối tượng hiển thị.
- Thiếu chỉ mục ở cột dùng để lọc và sắp xếp. Đặc biệt là các cột ngày tháng và khoá ngoại thường xuyên lọc theo.
- Lọc sau khi đã lấy dữ liệu về. Điều kiện viết ở phía ứng dụng khiến cơ sở dữ liệu vẫn phải đọc toàn bộ bảng.
Một mẹo rẻ tiền nhưng hiệu quả: với các màn hình chỉ đọc, tắt việc theo dõi thay đổi của thực thể. Bộ nhớ và thời gian tiết kiệm được là đáng kể trên danh sách lớn.
2. Phân trang và bộ lọc
Không màn hình danh sách nào nên trả về toàn bộ dữ liệu. Vài nguyên tắc:
- Luôn có giới hạn số dòng tối đa ở phía máy chủ, kể cả khi giao diện không gửi.
- Sắp xếp phải ổn định — có thêm khoá phụ, nếu không dữ liệu sẽ nhảy chỗ giữa các trang.
- Đếm tổng số dòng là một truy vấn riêng và thường tốn hơn bản thân việc lấy dữ liệu. Với bảng rất lớn, cân nhắc chỉ hiện "còn trang sau" thay vì tổng số chính xác.
3. Cache đúng chỗ
Cache là công cụ mạnh nhưng dễ gây lỗi khó hiểu. Phân theo loại dữ liệu:
- Danh mục ít đổi (đơn vị, chức danh, loại hợp đồng): cache trong bộ nhớ ứng dụng, xoá khi có thao tác sửa danh mục. Đây là chỗ cache trả lãi nhiều nhất.
- Dữ liệu dùng chung nhiều tiến trình: dùng bộ nhớ đệm ngoài, có thời hạn ngắn.
- Dữ liệu giao dịch: hầu như không nên cache. Số liệu sai còn tệ hơn số liệu chậm.
Quy tắc: chỉ cache khi đã trả lời được câu hỏi "cái gì làm nó hết hạn". Không trả lời được thì đừng cache.
4. Việc nặng đưa xuống nền
Xuất báo cáo lớn, gửi hàng loạt thông báo, đồng bộ dữ liệu với hệ thống ngoài — những việc này không nên chạy trong lúc người dùng đang chờ. Đưa vào hàng đợi, trả kết quả khi xong, và cho người dùng biết tiến trình. Ngoài việc giao diện nhanh hơn, cách này còn giúp việc nặng không kéo sập cả ứng dụng khi có nhiều người cùng bấm.
5. Đường truyền và giao diện
- Nén phản hồi: dữ liệu JSON và tệp tĩnh nén rất tốt, chi phí gần như bằng không.
- Đặt thời hạn cache cho tệp tĩnh có vân tay nội dung; riêng tệp trang chính thì không cache để bản mới có hiệu lực ngay.
- Ảnh: nén và giới hạn kích thước ngay khi tải lên, thay vì để trình duyệt tải ảnh gốc rồi thu nhỏ.
- Tải theo nhu cầu: chia nhỏ mã nguồn giao diện theo từng phân hệ để lần mở đầu tiên không phải tải toàn bộ ứng dụng.
6. Giữ tốc độ đã đạt được
Tối ưu một lần rồi quên là cách chắc chắn để quay lại điểm xuất phát sau một năm. Những việc nên duy trì:
- Cảnh báo tự động khi có thao tác vượt ngưỡng thời gian đặt trước.
- Kiểm tra dữ liệu thật chứ không chỉ dữ liệu mẫu — bảng mười nghìn dòng và bảng mười triệu dòng hành xử rất khác nhau.
- Xem lại truy vấn tốn tài nguyên nhất theo định kỳ; danh sách này thay đổi khi nghiệp vụ thay đổi.
Phần lớn hệ thống quản lý có thể nhanh hơn nhiều lần mà không cần thêm một đồng phần cứng. Điều kiện duy nhất là đo trước, sửa đúng chỗ, và đừng cache những thứ mình không kiểm soát được vòng đời.
