Tối ưu hóa Hiệu năng & Database Tuning

Trả lời: Thường là I/O (Input/Output), đặc biệt là truy vấn Database và gọi các API bên thứ ba. CPU hiếm khi là nguyên nhân chính trừ khi bạn xử lý dữ liệu cực lớn hoặc thuật toán quá tệ.

Trả lời: Nó ép Database phải đọc toàn bộ dữ liệu từ ổ cứng, tốn băng thông truyền tải và tốn bộ nhớ RAM để PHP khởi tạo object Model cho các trường không dùng đến.

Trả lời: Là lưu kết quả của các thao tác tốn kém (như query DB phức tạp) vào một nơi có tốc độ truy xuất nhanh hơn (như RAM/Redis) để dùng lại cho các lần sau.

Trả lời:

1. Sử dụng Laravel Debugbar hoặc Clockwork để xem danh sách query.
2. Bật DB::enableQueryLog() và kiểm tra.
3. Cấu hình slow_query_log trong MySQL để log các query chạy quá X giây.

Trả lời:

• Lazy Loading: Gọi query mới mỗi khi truy cập quan hệ (gây lỗi N+1).
• Eager Loading: Dùng with() để lấy toàn bộ dữ liệu liên quan trong 1-2 câu query bằng phép JOIN hoặc WHERE IN. Giảm thiểu số lần “round-trip” tới DB.

Trả lời:

• chunk(100): Lấy từng nhóm 100 bản ghi vào RAM. Phù hợp khi bạn cần xử lý và thực hiện các logic update trên chính các bản ghi đó.
• cursor(): Dùng PHP Generator để lấy từng bản ghi một (chỉ 1 model duy nhất trong RAM tại một thời điểm). Cực kỳ tối ưu cho bộ nhớ khi cần export dữ liệu khổng lồ.

Trả lời:

• B-Tree (Phổ biến nhất): Dữ liệu được sắp xếp theo cấu trúc cây cân bằng. Hỗ trợ tìm kiếm chính xác, tìm kiếm khoảng (>, <) và sắp xếp.
• Hash Index: Dùng hàm băm để trỏ thẳng tới dữ liệu. Tìm kiếm chính xác cực nhanh O(1) nhưng không hỗ trợ tìm kiếm khoảng và sắp xếp.

Trả lời: Là khi toàn bộ các cột bạn cần lấy (SELECT a, b) đều nằm sẵn trong Index. Lúc này MySQL không cần phải đọc vào bảng dữ liệu thật (Data file) mà trả về kết quả ngay từ Index (Index-only scan), tốc độ nhanh hơn nhiều lần.

Trả lời: Laravel bình thường sẽ khởi động Framework (boot) cho mọi request. Octane khởi động Framework 1 lần duy nhất và giữ nó trong RAM. Các request sau chỉ việc xử lý logic, bỏ qua bước boot tốn kém, giúp tăng throughput lên 5-10 lần.

Trả lời:

1. Vertical Scaling: Tăng RAM, CPU, SSD (có giới hạn).
2. Read/Write Splitting: 1 Master ghi, nhiều Slaves đọc.
3. Partitioning: Chia nhỏ bảng theo thời gian/vùng địa lý (mức vật lý).
4. Sharding: Chia dữ liệu sang nhiều server độc lập (mức ứng dụng).
5. Archiving: Đẩy dữ liệu cũ sang BigQuery/S3.

Trả lời:

1. Mutex Lock: Chỉ cho 1 request đầu tiên được nạp cache, các request sau chờ hoặc lấy giá trị cũ.
2. Soft Expiration: Lưu cache kèm timestamp “hết hạn giả”. Khi gần hết hạn, 1 request ngầm sẽ update cache trong khi người dùng vẫn thấy data cũ.
3. Random TTL: Cộng thêm một số giây ngẫu nhiên vào thời gian hết hạn để tránh việc hàng loạt key chết cùng lúc.

Xử lý:

1. Kiểm tra Network (Ping/Traceroute).
2. Xem Log Access của Nginx/Apache để biết request nào bị chậm.
3. Sử dụng top/htop xem CPU/RAM server có bị kịch trần không.
4. Kiểm tra Slow Query Log của DB.
5. Kiểm tra các dịch vụ bên thứ 3 (SMS, Email, Payment) có bị timeout không.

Xử lý:

1. Chạy EXPLAIN để xem có thiếu Index không.
2. Giảm thiểu số lượng cột SELECT.
3. Thử tách thành các query đơn giản và xử lý gộp ở mức ứng dụng (PHP) nếu logic cho phép.
4. Cân nhắc dùng Denormalization (tạo bảng phẳng) hoặc Materialized Views.