Tất cả những gì đóng góp cho thời gian thực hiện trang drupal?


17

Tôi có một trang web tôi đang điều tra có vấn đề về hiệu suất lớn, sử dụng memcache tôi có thể giảm số lượng truy vấn cả về số lượng và tổng thời gian thực hiện (từ 3 giây xuống còn 230 ms) nhưng thời gian thực hiện trang đang lảng tránh tôi (tôi nhìn vào các giá trị được đưa ra bởi devel) tôi hiểu rằng thời gian thực hiện trang = thời gian để php thực thi do đó tôi đã cài đặt APC và tôi có thể thấy opcode php được lưu trong bộ nhớ cache và các số liệu thống kê hiển thị các lần truy cập trong bảng điều khiển APC (apc.php được gửi cùng với APC) nhưng thời gian thực hiện trang của tôi không đi xuống. Vì vậy, tôi nghĩ rằng câu hỏi của tôi là hai lần:

  • Tất cả những gì đóng góp vào (tốt hơn làm chậm) thời gian thực hiện trang? Có phải chỉ cần thời gian để thực hiện php?
  • Những cách tiếp cận nào tôi nên làm để giảm thời gian thực hiện trang. Tôi đã thử APC nhưng không giúp được gì nhiều

Số lượng mô-đun PS được sử dụng trên trang web này chỉ là rất lớn (168) nhưng hiện tại tôi không ở vị trí để đưa ra khuyến nghị đó, nó giống như một đám cháy trong tình huống lỗ hổng.

Chỉnh sửa: Đầu ra của việc chạy xhprof trên cá thể cục bộ (được đề xuất bởi mikeytown), điều này có vẻ điên rồ Tôi nghĩ rằng kết quả sau này là do đập? diff chạy cho cùng một url có sự khác biệt lớn và việc sử dụng tài nguyên của nó quá nhiều. Cũng không chắc chắn tại sao nó hiển thị các giá trị không phải từ hôm nay: | (Tôi vừa cài đặt xhprof trên máy tính xách tay này)

Đầu ra của việc chạy xhprof trên cá thể cục bộ

Câu trả lời:


4

Nhận một bộ nhớ cache của trang web của bạn. Xdebug hoặc xhprof có thể tạo ra một. Điều này sẽ cho bạn biết những chức năng nào mất nhiều thời gian nhất để chạy. Cho đến khi bạn làm điều này, đó là một trò chơi đoán xấu.


Xin chào, cảm ơn vì lời đề nghị tôi vừa chạy xhprof trên phiên bản phát triển cục bộ của tôi (máy tính xách tay không phải trên máy chủ) và tôi thấy điều này - picasaweb.google.com/lh/photo/ trộm Đây có phải là sự thật không? Ý tôi là thậm chí một trang có thể tiêu thụ 750Mb bộ nhớ?
Dipen

Nó có thể là coz của đập? dữ liệu được định hình sau này cho cùng một url, nếu bạn nhìn vào cùng một url thì sẽ tốn ít tài nguyên hơn nhưng việc chạy khác biệt cho thấy việc sử dụng tài nguyên hoàn toàn khác và cực kỳ khó khăn.
Dipen

1
Nó thực sự phụ thuộc, nhưng đối với 99,9% thiết lập nếu bạn sử dụng hơn 100 MB ram thì có gì đó không ổn.
mikeytown2

Ngoài số lượng các mô-đun, có thể có bất cứ điều gì khác sai? Tôi không chắc chắn nếu các mô-đun có thể được gỡ bỏ khỏi sản xuất ngay lập tức. Btw, trên địa phương tôi đang sử dụng nginx + php-fpm và trên sản xuất trang web đang sử dụng lighspeed với cgi nhanh.
Dipen

1
Bạn cần đi sâu vào bộ nhớ cache và liệt kê chức năng nào đang ăn hết thời gian của bạn. img715.imageshack.us/i/cgrindout.png
mikeytown2

1

EDIT: Tôi đọc sai bài gốc. 168 mô-đun là rất nhiều và 300 đến 700ms truy vấn SQL là rất lớn . Càng sử dụng nhiều mô-đun, chúng sẽ càng có nhiều truy vấn ngay khi các mô-đun thực hiện.

Sử dụng bộ đệm ẩn tích cực trong khi bạn có thể, lưu trữ mọi thứ, nếu không đủ, hãy thử bộ đệm proxy ngược. Sử dụng CDN cho các tập tin có thể cải thiện toàn bộ. Bộ đệm proxy ngược cũng có thể giúp bạn bằng cách xóa một số cookie xác thực khi nhấn các trang không cần đến nó (khi đó core sẽ nghĩ người dùng ẩn danh cho những người đó và tối đa hóa bộ nhớ đệm).


Sự năng động cốt lõi của Drupal làm cho toàn bộ bình minh chậm lại ngay khi bạn có quá nhiều mô-đun tương tác cùng một lúc.

Tôi muốn nói, ví dụ, nếu bạn sử dụng nhiều mô-đun tải dữ liệu tại thời điểm hook_node_load () thay vì sử dụng các trường, nó sẽ tạo ra nhiều truy vấn trong khi việc sử dụng trường sẽ đảm bảo hiệu quả lưu trữ.

Việc kết xuất cũng có thể mất rất nhiều thời gian, drupal numnder () (API kết xuất đôi khi được gọi) là một đoạn API đẹp (thực sự hữu ích) nhưng cũng hơi chậm. Chuyển sang PDO (D7) và DBTNG đầy đủ (rất tuyệt vời) cũng thêm độ trễ không thể phủ định.

Điều đó nói rằng, bản thân lõi khá nhanh (nhưng nó thực hiện quá nhiều truy vấn SQL, thậm chí gần như không có gì được cài đặt), các mô-đun được mã hóa kém thường là nút cổ chai.

APC có thể phân chia thời gian thực hiện cho mỗi 2 hoặc 3, tùy thuộc vào mã chạy. nếu bạn định cấu hình tốt (bật tất cả các tối ưu hóa APC, hướng dẫn APC chính thức được viết tốt và sẽ hướng dẫn bạn).

Nếu bạn đang ở trên một hộp có hệ thống tệp chậm (hệ thống tệp mạng hoặc ổ cứng chậm), nó có thể ngụ ý tác động rõ ràng đến thời gian thực hiện. Drupal được tạo từ rất nhiều tệp nhỏ, điều này buộc PHP phải thực hiện I / O trên FS mỗi khi nó tải một trong số chúng (APC cũng giúp ích rất nhiều cho việc đó).

Một DBMS được cấu hình sai cũng có thể là một nút cổ chai xấu xí, nếu bạn đang sử dụng MySQL, hãy suy nghĩ về việc điều chỉnh tốt. Nếu bạn đang sử dụng dịch vụ lưu trữ chia sẻ, nếu đó không phải là DBMS và ngăn xếp DBMS cụ thể (hoặc sẵn sàng) của Drupal có thể sẽ bị định cấu hình sai hoặc không được điều chỉnh, điều này có thể dẫn đến các trang web thực sự chậm.

Đừng quên kích hoạt tất cả các bộ nhớ cache. Nếu trang web của bạn không được xác thực theo định hướng người dùng, thì hãy kích hoạt bộ đệm ẩn trang nhanh chóng (nó thực sự tuyệt vời).

Bạn càng có nhiều khối, càng nhiều trang sẽ càng chậm, khối mô-đun của Lượt xem sẽ là nút cổ chai bình minh (tùy thuộc vào các plugin Lượt xem bạn sử dụng, khối OG có thể là một nỗi đau thực sự) nếu bạn không hạn chế khả năng hiển thị của chúng trên cơ sở mỗi trang hoặc với mã PHP tùy chỉnh (bất kỳ khối nào khác cũng vậy, luôn đặt chế độ hiển thị khối của bạn theo cách thủ công, giúp ích rất nhiều cho khung bằng cách tránh nó cố gắng hiển thị các khối trống).

Tránh các mô-đun sử dụng hook_init (), hook_init () đang được chạy trên mọi trang, ngay cả khi bạn nhận được 403 hoặc 404, làm chậm mọi thứ (thậm chí làm chậm thời gian tạo hình ảnh | và lỗi 404 trên các tệp sẽ là bình minh chậm chỉ để cho bạn biết các tập tin không tồn tại).


Xin chào, ở đây khi tôi nói thời gian thực hiện trang, ý tôi là giá trị được hiển thị bởi mô-đun phát ở cuối trang và không sử dụng nó theo nghĩa chung của chu kỳ yêu cầu / phản hồi drupal cũng bao gồm các truy vấn SQL, v.v. trong bối cảnh của người dùng xác thực. Vì vậy, khi báo cáo thời gian thực hiện trang báo cáo cũng bao gồm các truy vấn sql?
Dipen

Tôi không chắc chắn nếu hệ thống tập tin sẽ là một nút cổ chai như tôi trên hệ thống tập tin linux 15k RPM. Các truy vấn SQL đang mất khoảng 300-700ms tùy thuộc vào trang nhưng thời gian thực hiện trang ~ = 3 giây (được báo cáo bởi devel). Không chắc chắn những gì khác có thể là vấn đề.
Dipen

Oh xin lỗi, tôi đọc sai bài viết gốc của bạn. Giá trị phát được tính từ khởi động đến tắt máy (mô-đun devel có trình xử lý tắt máy PHP riêng để thực hiện nhiều công việc bao gồm cả việc này). Tôi không chắc chắn chính xác khi nào nó bắt đầu và dừng, nhưng gần như toàn bộ thời gian xây dựng trang Drupal và các chi tiết cụ thể về doanh nghiệp được bao gồm trong thời gian thực hiện trang đó. Có, nó bao gồm mọi thứ (bao gồm thời gian và độ trễ truy vấn SQL) và độ trễ của chính nó (ghi nhật ký truy vấn phát cũng có tác động hiệu suất).
Pierre
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.