Bộ nhớ đệm Drupal


10

Tôi tò mò liệu có ai đã cố gắng "lưu trữ" quá trình bootstrap trong Drupal không.

Thông thường, Drupal sẽ chạy 7 giai đoạn bootstrap cho mỗi yêu cầu, nhưng có lẽ trên một hệ thống sản xuất được triển khai, người ta có thể "làm mất" với một số hoặc tất cả những điều này?

Những gợi ý có thể tôi có trong đầu có thể là

  1. Nối tiếp trạng thái bootstrapping và dán nó vào memcache
  2. Một tập lệnh có thể tạo ra một bản vá cho bootstrap.inc sẽ mã hóa một số thông tin nhất định vào tệp.
  3. Tôi tin rằng David Strauss đã cố gắng để một Drupal được khởi động hoạt động tốt.
  4. Sự điên rồ khác?

Những nỗ lực nào ở đó, và được biết là (phần nào) đáng tin cậy?


Điều này bằng cách nào đó liên quan đến câu hỏi của tôi về việc biên dịch Drupal: drupal.stackexchange.com/q/11738/2916
Refineo

Câu trả lời:


12

PHP là một kiến ​​trúc không chia sẻ. Điều đó có lợi thế và bất lợi của nó.

Một nhược điểm là không dễ để làm một cái gì đó như thế này. Không có nhiều trạng thái có thể được lưu trữ ở đâu đó.

Tôi đã thực hiện một số thử nghiệm nhanh và khi đăng nhập, thì boostrap dường như chiếm khoảng ~ 17% tổng thời gian và hơn 50% trong số đó thực sự đang tải tất cả các tệp .module và .inc. Đó không phải là thứ mà bạn có thể lưu trữ trong memcache. Ngoài ra, nó dường như không quan trọng lắm nếu tôi sử dụng memcache hoặc bộ đệm cơ sở dữ liệu.

Tôi đã cố gắng để có được một số kết quả khi bật bộ đệm trang, nhưng Xhprof dường như không trả lại kết quả đáng tin cậy sau đó; toàn bộ điều này dường như quá nhanh Nhưng ngay cả khi đó, phần lớn nhất liên quan đến việc thực hiện các hook init / exit và tải các tập tin có vẻ như. Tôi đã tìm thấy một vấn đề thú vị ở đó: Có vẻ như mô-đun Người dùng đang làm chậm nghiêm trọng phản hồi của trang được lưu trong bộ nhớ cache vì nó kích hoạt sổ đăng ký do bộ điều khiển thực thể trong tệp .module.

Điều đó nói rằng, David Strauss đã cho thấy một số công việc thử nghiệm ở Copenhagen, nơi ông đã tạo ra một ảnh chụp nhanh bộ nhớ sau khi bootstrapping và sau đó quay lại đó một khi trang được phục vụ. Ông đã sử dụng Drupal 6 cho điều đó. Sau khi nhìn vào những con số ở trên, tôi tưởng tượng rằng hiệu suất đạt được khi làm điều này trong Drupal 7 sẽ nhỏ hơn một chút. Một lý do cho điều này là kết nối cơ sở dữ liệu được tải lười biếng (Và bạn có thể đi khá xa trong bootstrap khi sử dụng, ví dụ Memcache trước khi bạn cần thực hiện truy vấn đầu tiên) và có rất nhiều bộ nhớ cache.

Điều thực sự tồi tệ ở Drupal 7 là lớp kết xuất với các mảng lớn và các vòng lặp và vòng lặp vô tận. Đó là một trong số rất nhiều công việc hiệu suất đã đi vào Drupal 7. Hãy xem nó trông như thế nào trong Drupal 8, nếu Twig biến nó thành cốt lõi.

Cuối cùng, về những lợi thế được đề cập. Một lợi thế lớn là các tỏi tây bộ nhớ khá không liên quan vì mọi thứ đều được giải phóng sau mỗi yêu cầu. Tôi đã thấy nhiều ứng dụng Java trong đó việc sử dụng bộ nhớ liên tục tăng và cần khởi động lại thường xuyên.


4
Tôi rất thích có bạn trên trang web @Berdir;)
Letharion

Alex Bronstein đã đề cập đến nó trong giai đoạn nước rút rằng việc đưa các tệp tpl.php trở nên hơi chậm ngay cả với APC, nó yêu cầu một thống kê - nhưng Twig biên dịch thành các lớp để có thể giành chiến thắng trên các trang như nút + nhiều bình luận. Chúng ta sẽ thấy.

Tôi đoán bạn có thể tạo một hệ thống trong đó, đối với các trang được lưu trong bộ nhớ cache, bạn tạo ra một loạt các quy tắc viết lại và đặt chúng vào .htaccess, kèm theo các trang html để bỏ qua PHP hoàn toàn. Có thể không đáng để gặp rắc rối: IIS, nginx, người dùng đã đăng nhập, ...
Bart

1
@Bart: Bạn vừa phát minh lại Boost: drupal.org/project/boost :)
Berdir

5

Không, đó là David Strauss, người đã thử nghiệm với sự kiện kargo (bây giờ được gọi là Kellner) tại https://code.launchpad.net/~fourk Kitchen / pressflow / 6 - nhưng tôi nghi ngờ bất cứ điều gì nghiêm trọng đã xảy ra.

Drupal 7 không có nhiều bootstrap đã được lưu trữ, có một cache_bootstrapbin cho điều đó. Bạn có thể dán nó vào memcached.

Bạn có thể quá tải và giảm tải mã khi chuyển một số / rất nhiều mã Drupal sang C. Damien và dhthwy đã tạo tiện ích mở rộng PHP tại http://drupal.org/project/drupal_php_ext không được thực hiện nhiều với nó. Hoặc làm hiphop. Tôi không biết tình trạng hiện tại của hiphop & Drupal 7.

Tuy nhiên, vào cuối ngày, bạn cần xem xét kỹ các chi phí kỹ thuật, giả sử, làm việc hiphop với Drupal 7 (và tất cả các đóng góp!) Và so sánh với việc thuê thêm một vài máy chủ. Nếu bạn có thể lưu, giả sử 5% máy chủ của bạn và bạn có 100 000 máy chủ, hãy truy cập nó, nhưng bạn có phải là Facebook không? Hãy cẩn thận và kinh tế với tối ưu hóa.


Cảm ơn, tôi đã cập nhật câu hỏi và xóa tên của bạn khỏi nó. :) Tôi nhận ra rằng trong nhiều trường hợp, có nhiều cách hiệu quả hơn để đối phó với hiệu suất, tôi chủ yếu là tò mò.
Letharion

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.