it-swarm-vi.com

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

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 P.S đượ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)

Output of running xhprof on local instance

16
Dipen

Nhận một bộ nhớ cache của trang web của bạn. xdebug hoặc xhprof có thể tạo một cái. Đ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.

4
mikeytown2

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).


Drupal tính năng động cốt lõi 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ả tối ưu hóa APC, hướng dẫn sử dụng 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ề các tệp nhỏ, bắt buộc PHP để thực hiện I/O trên FS mỗi lần 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 nghĩ đến việc thực hiện tinh chỉnh. Nếu bạn đang sử dụng dịch vụ lưu trữ chia sẻ, nếu đó không phải là Drupal cụ thể (hoặc sẵn sàng) DBMS và PHP có thể sẽ bị định cấu hình sai hoặc không được điều chỉnh, 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 tùy chỉnh PHP (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ó để 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).

1
Pierre