Vụ án kỳ lạ của ông Time To First Byte

Tôi đã có một máy chủ web trên Linode 1024 VPS dựa trên

• Ubuntu 11.10
• Nginx 1.0.5
• PHP 5.3.6 (với PHP-FPM, APC)
• Véc ni 3.0.2

Và một vài blog ở đó dựa trên WordPress 3.3.1. Một trong số đó là một blog đơn giản, với cấu hình, chủ đề mặc định và chỉ bài đăng "Hello World", để kiểm tra máy chủ. Một cái khác là một blog được nhân bản từ máy chủ khác với gần 10k bài đăng và hơn 10k bình luận. Blog này đã thu được 5k đơn vị mỗi ngày.

Máy chủ cho số lượng tốt trong bài kiểm tra ab cho blog thử nghiệm , nhưng thử nghiệm tương tự với blog nhân bản là không thể thực hiện: thử nghiệm ab tải máy chủ quá nhiều và tôi phải dừng quá trình, dù sao cũng khiến ab hiển thị kết quả thực sự nghèo này .

Htop cũng hiển thị tải "bình thường" khi hoạt động bình thường , nhưng tải lớn bất thường trong quá trình kiểm tra ab.

Có một điều kỳ lạ khác xảy ra (quan trọng nhất đối với tôi): Thời gian đầu tiên Byte cực kỳ cao , nhưng sau đó chờ trang web tải rất nhanh. Điều này có thể dễ dàng được kiểm tra với các dịch vụ như tools.pingdom.com, mang lại kết quả này . Hãy chú ý đến khu vực màu vàng có nghĩa là "Thời gian chờ".

Tại sao chuyện này đang xảy ra? Ý tưởng có thể:

• Cấu hình PHP-FPM xấu
• Thời gian phản hồi Linode DNS là khủng khiếp. Vô nghĩa - blog thử nghiệm giải quyết DNS tốt, TTFB thật tuyệt vời
• Cấu hình Nginx xấu

Trong trường hợp ai đó cần thêm thông tin,

• Dưới đây bạn đã có nhân bản trên blog hiện tại tập tin cấu hình nginx ( /etc/nginx/sites-available/muycomputerpro.com )
• Ở đây bạn đã có cấu hình my.cnf hiện tại ( /etc/mysql/my.cnf ) (Tôi biết, hiện tại không lưu vào bộ nhớ cache, điều này không tạo ra sự khác biệt trên TTFB trong quá khứ)
• Ở đây bạn đã có cấu hình PHP-FPM hiện tại ( /etc/php5/fpm/pool.d/www.conf )

Thứ nhất, đây không phải là một câu trả lời, nhiều như một phương pháp chẩn đoán.

Điều này không có nghĩa là toàn diện - hoặc thậm chí bất cứ điều gì gần gũi, nó chỉ là một điểm khởi đầu.

Thời gian để Byte đầu tiên

Thời gian để byte đầu tiên (TTFB) có một số thành phần:

• Tra cứu DNS: Tìm địa chỉ IP của tên miền (có thể cải thiện: nhiều máy chủ DNS phân tán / đáp ứng hơn)
• Thời gian kết nối: Mở một ổ cắm cho máy chủ, đàm phán kết nối (giá trị điển hình nên ở khoảng thời gian 'ping' - một chuyến đi khứ hồi thường là cần thiết - giữ lại sẽ giúp cho các yêu cầu tiếp theo)
• Chờ đợi: yêu cầu xử lý ban đầu trước khi byte đầu tiên có thể được gửi (đây là nơi cải thiện của bạn - điều này sẽ có ý nghĩa nhất đối với nội dung động.

Khi bạn nhìn vào một đầu ra ApacheBench, bạn cũng thấy:

• Xử lý: Đây là tổng số chờ đợi + chuyển hoàn toàn nội dung (nếu thời gian truyền dài hơn đáng kể so với dự kiến ​​tải xuống số lượng dữ liệu nhận được, xử lý thêm (sau khi byte đầu tiên nhận được) xảy ra (ví dụ: trang là nội dung tuôn ra như nó có sẵn)

So sánh để loại bỏ các thành phần

Với một vài ngoại lệ, vấn đề của bạn sẽ nằm ở việc xử lý phụ trợ, thường là do mã quá phức tạp / kém hiệu quả hoặc MySQL được cấu hình kém.

Một cách tốt để tiếp cận vấn đề này là thông qua một loạt các so sánh sẽ loại bỏ các khía cạnh khác nhau trong thiết lập của bạn. Một so sánh tốt nên giữ càng nhiều càng tốt để giúp thu hẹp vấn đề. Hiện tại, bạn đã cung cấp các so sánh sau:

1. Trang web giống hệt (nhân bản) chạy trên máy chủ cũ và máy chủ mới:
   • Sự khác biệt: Máy chủ
   • Kết quả: máy chủ cũ nhanh; máy chủ mới chậm
   • Lưu ý: Điều bạn cần ở đây là định lượng sự khác biệt giữa các máy chủ này - cả về ngăn xếp được sử dụng (Nginx, v.v.) và phần cứng (máy chủ cũ có nhanh hơn vì đây là máy mạnh hơn?)
   • Kết luận: mã có thể chạy nhanh khi thiết lập đúng
2. Kiểm tra trang web và trang web đầy đủ trên máy chủ mới
   • Sự khác biệt: nội dung, chủ đề, plugin, v.v.
   • Kết quả: trang web kiểm tra nhanh, trang web đầy đủ chậm
   • Lưu ý: về mặt lý thuyết, thử nghiệm này sẽ giúp bạn loại bỏ rất nhiều khía cạnh của thiết lập - DNS, mạng, thậm chí cả thiết lập nginx / php / mysql của bạn - tuy nhiên, nó không hoàn toàn 'công bằng'.
   • Kết luận: nội dung bổ sung có ảnh hưởng đáng kể đến hiệu suất

Bài kiểm tra lý tưởng sẽ giúp bạn nhân đôi toàn bộ trang web của mình, nhưng sau đó xóa tất cả nội dung ngoại trừ một bài viết và các bình luận liên quan. Điểm quan trọng của bài kiểm tra này là xác định cụ thể xem liệu số lượng lớn nội dung có phải là vấn đề hay không nếu các khía cạnh khác trong thiết lập của bạn (plugin wordpress, chủ đề, v.v.) là nguyên nhân. Về cơ bản, bạn sẽ so sánh hiệu suất của các trang web giống hệt nhau, trên cùng một máy chủ (mới) - tải cùng một trang (cùng độ dài, v.v.) - với sự khác biệt duy nhất là tổng nội dung trang web (ví dụ: rất có thể một số plugin không quy mô tốt với nội dung tăng).

Không thay đổi bất cứ điều gì, có một số so sánh khác bạn có thể làm:

• Kiểm tra từ một vị trí từ xa so với cục bộ - điều này sẽ giúp xác định xem mạng, độ trễ, dns, v.v có phải là nguyên nhân không
  • Bạn đã (phần nào) thực hiện điều này và hầu hết kết luận rằng bạn không gặp sự cố mạng.
• Kiểm tra qua Varnish (tức là cổng 80) so với nginx trực tiếp (cổng 8080) - cố gắng không thay đổi cấu hình của bạn giữa các lần kiểm tra - chỉ cần sử dụng đúng cổng. Điều này sẽ cho bạn thấy tác động của Varnish. Vì Varnish là một lớp lưu trữ, nên nó sẽ phục vụ tất cả các yêu cầu sau yêu cầu đầu tiên rất nhanh - về cơ bản, nó sẽ bỏ qua phần phụ trợ và xử lý cần thiết để tạo một trang động và phục vụ bản sao được lưu trong bộ nhớ cache rất nhanh.
  • Bạn đã làm điều này (mặc dù, không phải tại địa phương) và chứng minh rằng Varnish có tác động tích cực đáng kể đến hiệu suất của bạn.

Điều chỉnh phần cuối của bạn

Đến thời điểm này, bạn nên tìm ra vấn đề hoặc kết luận rằng nó nằm trong phần phụ trợ của bạn. Điều đó khiến bạn Nginx, PHP hoặc MySQL.

(Tôi nên đề cập đến ở đây, đó là nó luôn tiện dụng để biết nếu nút cổ chai của bạn là CPU, RAM, hay I / O - giữa sar, top, iostat, vmstat,free ., Vv bạn sẽ có thể đi đến một số kết luận về vấn đề này)

Nginx

Nginx chỉ nhận các yêu cầu và phục vụ nội dung tĩnh hoặc chuyển các yêu cầu sang PHP-FPM - thường không có nhiều thứ để tối ưu hóa với Nginx.

• Đặt công nhân = # lõi CPU
• Cho phép keepalive (giá trị 10-15 là tốt)
• Vô hiệu hóa đăng nhập không cần thiết
• Tăng kích thước bộ đệm nếu cần
• Tránh nếu các câu lệnh (sử dụng tên tĩnh thay vì biểu thức chính quy nếu có thể, loại bỏ các phần mở rộng không cần thiết)

Lý tưởng nhất là blog thử nghiệm và blog nhân bản của bạn có cấu hình giống hệt nhau, trong trường hợp đó, bạn đã loại bỏ Nginx một cách hiệu quả như là vấn đề.

Ứng dụng

Trong trường hợp bạn đang cố gắng xác định một vấn đề trong mã của mình (ví dụ: plugin chậm, v.v.), các bản ghi chậm là nơi để bắt đầu.

• Kích hoạt nhật ký chậm MySQL và nhật ký chậm PHP-FPM chạy điểm chuẩn của bạn và xem những gì sắp diễn ra là chậm.

MySQL

• Tăng bộ nhớ cache của bạn và chạy mysqltuner.pl để có điểm khởi đầu tốt.

PHP

• vô hiệu hóa các phần mở rộng không cần thiết,
• vô hiệu hóa register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_population_raw_post_data
• tăng bộ nhớ_limit
• open_basingir và safe_mode có ý nghĩa hiệu suất đáng kể, nhưng cũng có thể cung cấp thêm một lớp phòng thủ. Kiểm tra có và không có chúng, để xác định xem tác động của chúng đối với hiệu suất có được chấp nhận hay không.

PHP-FPM

• Điều chỉnh giá trị pm. * - tăng chúng để đối phó với tải cao

Điều đáng chú ý là kết quả htop của bạn hiển thị php-fpm khi tiêu thụ phần lớn CPU - và vấn đề của bạn dường như có liên quan trực tiếp đến điều này.

Bộ nhớ đệm

Khi bạn đã tối ưu hóa từng nút cổ chai có khả năng, hãy bắt đầu lưu trữ.

• Bạn đã có bộ đệm opCode (APC) - đảm bảo rằng nó đang hoạt động (đi kèm với tệp kiểm tra) - kiểm tra tốc độ nhấn bộ đệm của bạn và nếu có thể có bộ đệm APC vào bộ nhớ thay vì vào đĩa.
• Thiết lập mã của bạn thành bộ đệm (ví dụ: sử dụng plugin cho Wordpress, chẳng hạn như W3TC)
• Với nginx bạn có thể thiết lập bộ nhớ đệm FastCGI - nhưng vì bạn có Varnish, điều này tốt nhất nên tránh.
• Thiết lập một lớp bộ nhớ đệm, chẳng hạn như Varnish (mà bạn đã thực hiện) - và đảm bảo rằng nó đang hoạt động (ví dụ: sử dụng var Vecstat, đọc Đạt được Hitrate cao )
• Thêm bộ nhớ đệm cho các thành phần của trang web của bạn - ví dụ: MemCached nếu có thể

Đôi khi, do những hạn chế của ứng dụng và phần cứng của bạn, bạn có thể không thể cải thiện hiệu năng phụ trợ nhiều - tuy nhiên, đó là điểm của bộ đệm - để giảm thiểu việc sử dụng phụ trợ.

đọc thêm

• Điều chỉnh hiệu năng PHP
• Tối ưu hóa PHP
• Tối ưu hóa Nginx cho tải cao