Hàm PHP nhìn vô hại nhưng tốn tài nguyên

1) file_get_contents() gọi API hoặc file lớn

Vì sao nguy hiểm: Hàm này là blocking I/O. Khi gọi API chậm hoặc đọc file lớn, worker PHP sẽ bị giữ lại cho tới khi xong.

Lỗi thường gặp:

• Gọi API ngoài trong mỗi request
• Không set timeout
• Dùng trong loop

Hậu quả: PHP-FPM hết worker rất nhanh khi traffic tăng.

// Rất tệ nếu gọi thường xuyên
$data = file_get_contents('https://api.example.com/data');

Giải pháp: cache kết quả, set timeout bằng cURL, hoặc xử lý async/cron.

2) unserialize() với dữ liệu lớn hoặc không kiểm soát

Vì sao nguy hiểm: unserialize tốn CPU và RAM, đặc biệt với dữ liệu mảng sâu.

Lỗi thường gặp:

• Unserialize option autoload lớn
• Unserialize trong mỗi request frontend

Hậu quả: CPU tăng đều theo traffic, rất khó nhận ra bằng mắt thường.

$data = unserialize($row['meta_value']);

Giải pháp: tránh lưu data phức tạp bằng serialize, ưu tiên JSON nhẹ và cache đúng chỗ.

3) json_encode() / json_decode() trong vòng lặp

Vì sao nguy hiểm: Encode/decode JSON là thao tác CPU-bound.

Lỗi thường gặp:

• Decode JSON trong foreach lớn
• Làm trung gian xử lý data không cần thiết

Hậu quả: request đơn lẻ không chậm, nhưng cộng dồn thì rất đau.

foreach ($items as $item) {
  $data = json_decode($item['payload'], true);
}

Giải pháp: decode một lần, hoặc xử lý sẵn khi lưu dữ liệu.

4) preg_match() và regex phức tạp

Vì sao nguy hiểm: Regex xấu có thể khiến CPU spike mạnh.

Lỗi thường gặp:

• Regex quá tổng quát
• Dùng nhiều lookahead/lookbehind
• Chạy regex trong loop lớn

Hậu quả: CPU tăng đột ngột, khó debug.

// Regex phức tạp chạy nhiều lần
preg_match('/(.*)(foo|bar)(.*)/i', $text);

Giải pháp: đơn giản hóa regex, hoặc dùng string function khi có thể.

5) array_merge() với mảng lớn

Vì sao nguy hiểm: array_merge tạo mảng mới, copy toàn bộ dữ liệu.

Lỗi thường gặp:

• Merge mảng lớn trong loop
• Merge nhiều lớp data

Hậu quả: RAM tăng, garbage collection nhiều.

$data = array_merge($data, $newData);

Giải pháp: append thủ công hoặc thiết kế lại cấu trúc data.

6) in_array() không strict với mảng lớn

Vì sao nguy hiểm: in_array là O(n), không strict còn tốn thêm so sánh kiểu.

Lỗi thường gặp:

• Dùng in_array trong loop
• Check trên list dài

if (in_array($id, $bigArray)) {}

Giải pháp: dùng array_flip hoặc set key để check O(1).

7) strlen(), strpos() trên string rất lớn

Vì sao nguy hiểm: PHP phải scan toàn bộ chuỗi.

Lỗi thường gặp:

• Xử lý HTML dài
• Log, content lớn

Đặt trong loop là “đòn chí mạng”.

8) DateTime tạo mới liên tục

Vì sao nguy hiểm: DateTime là object nặng.

Lỗi thường gặp:

• Tạo DateTime trong foreach
• Không reuse object

$date = new DateTime($time);

Giải pháp: reuse object hoặc xử lý timestamp thuần.

9) function_exists() / class_exists() gọi liên tục

Vì sao nguy hiểm: Mỗi lần gọi đều phải tra symbol table.

Lỗi thường gặp:

• Check trong loop
• Check trong hook chạy nhiều lần

10) var_dump() / print_r() còn sót trong production

Vì sao nguy hiểm: Xuất data lớn ra output buffer cực kỳ tốn tài nguyên.

Hậu quả: request chậm, log phình to, leak thông tin.

Dấu hiệu nhận biết bạn đang dính mấy hàm này

• Traffic tăng nhẹ nhưng CPU tăng mạnh
• PHP-FPM full worker dù query MySQL không nhiều
• TTFB cao nhưng không rõ bottleneck

Nguyên tắc sống còn khi dùng PHP function

• Đừng đặt hàm tốn CPU/IO trong loop
• Cache kết quả nếu hàm cho cùng input
• Đo trước khi tối ưu, nhưng phải nghi ngờ loop
• Code chạy được chưa chắc chạy tốt

Kết luận: PHP chậm hiếm khi do PHP, mà do cách dùng

Không có hàm PHP nào “xấu”, chỉ có hàm bị dùng sai chỗ. Những hàm nhìn vô hại ở trên là sát thủ thầm lặng, đặc biệt nguy hiểm với web tăng trưởng dần. Nhận ra sớm, sửa sớm, bạn sẽ tiết kiệm được rất nhiều CPU, RAM và… tiền VPS.