Tái cấu trúc Wordpress để cải thiện hiệu năng bộ nhớ [đã đóng]

Tôi đã có một cái nhìn cận cảnh về mức tiêu thụ bộ nhớ Wordpress. Trên trang web của tôi, dường như với mỗi trang, 20 MB RAM được phân bổ, chỉ để chuẩn bị môi trường thoải mái cho tất cả các plugin chạy. Tôi đã vẽ nó như vậy:

Không có điểm duy nhất để tối ưu hóa, không có kẻ xấu nào ăn hầu hết bộ nhớ. Tiêu thụ là tất cả trải rộng trên nhiều nhiều mô-đun php.

Làm cách nào chúng ta có thể khiến Wordpress khởi tạo môi trường của nó trong bộ nhớ chỉ một lần và sau đó sử dụng lại nhiều lần cho mỗi lần nhấn? Tôi không muốn PHP chậm ăn 20 MB mỗi lần nhấp chuột của người dùng - ngay cả trên một máy chủ có nhiều bộ nhớ, phải mất vài giây để hoàn thành công việc. Về cơ bản, bạn sẽ cần các đoạn bộ nhớ chỉ đọc có thể được sử dụng lại.

Ngoài ra ... tại sao 20MB? Bất cứ ai có thể cung cấp cái nhìn sâu sắc về điều này?

Chỉnh sửa: Đây là đầu ra WinCacheGrind trên Wordpress đang chạy trên máy phát triển của tôi (nhanh hơn rất nhiều so với lưu trữ được chia sẻ). Như bạn có thể thấy, phải mất một giây giòn giã chỉ để tạo HTML của trang chính. Làm chậm nó xuống bằng cách chia sẻ lưu trữ và bạn có một công thức cho rắc rối. Tôi chọn phương pháp mất phần lớn thời gian. Làm thế nào bạn sẽ đi về tối ưu hóa điều này?

Chỉnh sửa: Dưới đây là số liệu thống kê truy vấn từ công cụ định hình hàm.php tuyệt vời này .

Tải: 12 truy vấn - 532ms - 19.1MB - 43 lần truy cập bộ đệm / 53
Truy vấn: 15 truy vấn - 563ms - 19.0MB - 72 lần truy cập bộ đệm / 86
Hiển thị: 21 truy vấn - 705ms - 19,2MB - 234 lần truy cập bộ nhớ cache / 257

Chỉnh sửa: Bạn có muốn thấy một cái gì đó được đảm bảo để làm bạn hoảng sợ? Chèn các dòng này vào cuối index.php:

echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

Tôi đã cố gắng đếm bao nhiêu lần cơ thể của bài hiện tại được lưu trữ trong bộ nhớ. Tôi đếm được 20 trường hợp. Sau đó, tôi nhận ra rằng PHP có tính năng tham chiếu, vì vậy số lượng bản sao giảm xuống chỉ còn ba: hai dường như trong WP_Query, một trong bộ đệm của đối tượng. Tôi đang điều tra thêm.

Đây là lý do tại sao tôi nghĩ rằng WordPress cần tái cấu trúc nhắm mục tiêu các vấn đề bộ nhớ. Bạn không còn có thể đổ lỗi cho việc tiêu thụ bộ nhớ của nó về sự phức tạp tuyệt đối của những gì nó làm. Nó chỉ đơn giản là làm một loạt những điều sai .

Chỉnh sửa: Sau một ngày cố gắng để tìm ra điều này, đây là những phát hiện của tôi:

1) 88% của tất cả bộ nhớ đến từ yêu cầu hoặc bao gồm hoặc bao gồm loại cuộc gọi:

2) Tệp php bao gồm hầu hết xảy ra trong phần đầu tiên của việc phục vụ một yêu cầu (không đáng ngạc nhiên), đó cũng là nơi tất cả bộ nhớ bị ăn hết:

3) Khá thú vị khi vẽ tất cả các chức năng đang được thực hiện trong khi thực hiện một yêu cầu. Tổng cộng có hơn 12000 cuộc gọi. Tôi đã xáo trộn chúng để làm cho nó rõ hơn (trục Cấp cơ bản là độ sâu của ngăn xếp):

4) Cách duy nhất mà tôi có thể nghĩ đến là giảm thiểu số lượng tệp .php đi kèm. Nếu tôi phân chia các chức năng cho mỗi tệp mà chúng xuất phát, bạn có thể thấy rằng nhiều tệp được nhấn nhiều nhất một hoặc hai lần. Chúng ta cần một cách để bỏ qua những thứ đó khi chúng không cần thiết. Ví dụ, plugin sao lưu cơ sở dữ liệu từ xa của tôi được tải và đăng ký, hoàn toàn không bao giờ được sử dụng. Dưới đây là âm mưu chia ở trên theo tên tệp:

Tôi đang cung cấp một tiền thưởng xứng đáng với tất cả danh tiếng của tôi :) cho các phép tái cấu trúc sẽ dẫn đến việc cắt giảm 30% dung lượng bộ nhớ blog của tôi.

Chỉnh sửa: Tôi đã cài đặt WP 3.1, đây là so sánh với phiên bản cũ.

Màu xanh là WP 3.1, màu đỏ là 3.0.4. WP mới nhanh hơn, nhưng cũng ăn nhiều bộ nhớ hơn.

Đây là một danh sách bao gồm tập tin.

Điều này cho tôi nhận ra "Bộ nhớ SEO All In One" đã ăn bao nhiêu bộ nhớ - một cách duy nhất là chỉ sử dụng một phần nhỏ chức năng của plugin để có được những gì tôi muốn. Ngoài ra, các plugin của riêng tôi có vẻ khá tệ.

Tôi muốn thử tải có điều kiện vào ví dụ bình luận.php (Tôi không cho phép nhận xét trên blog của mình) và một số người khác. Tôi đã xóa tất cả các mã không dùng nữa. Tôi đã cắt bớt kodes.php để chỉ tải các bảng toàn cầu của nó theo yêu cầu. Tôi đã đơn giản hóa l10n (tôi không bản địa hóa), làm cho các hàm của nó trả về chuỗi ngay lập tức mà không cần tra cứu. Tôi vẫn còn cách xa mốc 30% mà tôi tự ý thiết lập.

Chỉnh sửa: Tôi đã tải xuống và kích hoạt APC với cài đặt mặc định (bộ nhớ cache opcode 32 MB). Đây là so sánh:

Bạn có thể thấy rằng việc tải mã được tăng tốc ồ ạt và mã cũng chiếm ít không gian hơn trong bộ nhớ (có lẽ vì chúng ta chỉ xử lý các opcodes chứ không phải nguồn gốc). Tiêu thụ bộ nhớ tuy nhiên vẫn còn khá cao.

Không đáng để gặp rắc rối. WordPress không ăn nhiều bộ nhớ chỉ vì. Nó ăn rất nhiều bộ nhớ vì nó chạy rất nhiều chức năng dưới mui xe.

Sẽ dễ dàng và hiệu quả hơn rất nhiều khi kết quả bộ đệm (trang được tạo) với plugin bộ đệm tĩnh và phục vụ điều đó. Bằng cách đó, hầu hết khách truy cập thậm chí sẽ không nhấn WP.

Và đây là lý do tại sao tôi nghĩ rằng WordPress đang rất cần viết lại. Bạn không còn có thể đổ lỗi cho việc tiêu thụ bộ nhớ của nó về sự phức tạp tuyệt đối của những gì nó làm. Nó chỉ đơn giản là làm những điều sai trái.

Thật là một kết luận ngây thơ. Đọc Những điều bạn không bao giờ nên làm, Phần I .

Cảm ơn cho các lô sử dụng bộ nhớ, mặc dù.

Chỉnh sửa sau này: Autommatic đã phát hành một thư viện có tên prefork dường như làm những gì bạn yêu cầu: chỉ tải mã WordPress trong RAM một lần.

Bắt đầu với WordPress 3.2, PHP 5.2 sẽ là yêu cầu tối thiểu. Tôi nghĩ với điều đó dưới vành đai của chúng tôi, các bit của lõi có thể bắt đầu được cấu trúc lại và sử dụng các lớp với tính năng tự động tải. Điều này sẽ cho phép chúng tôi tránh tải một số đoạn mã trừ khi chúng thực sự cần thiết. Ví dụ: nếu không có nhúng hoặc phòng trưng bày trong chế độ xem trang, chúng tôi có thể tránh tải nhiều mã phương tiện.

Tuy nhiên, ngay cả khi họ quyết định đi theo con đường đó, tôi sẽ hy vọng đó là một sự tiến hóa chậm (giống như nhiều thay đổi khác đã xảy ra). Nó sẽ yêu cầu xáo trộn xung quanh vị trí của rất nhiều tệp và mã, có thể phá vỡ compat ngược cho một số plugin.

Một phần của vấn đề (nếu nó thực sự có thể được gọi là vậy) là nếu không có loại tải có điều kiện đó, khung cốt lõi không thể biết trước chức năng nào nó sẽ cần hoặc không cần để tạo chế độ xem nội dung. Vì vậy, rất nhiều chức năng phải được tải lên trong trường hợp cần thiết.

Làm cách nào chúng ta có thể khiến Wordpress khởi tạo môi trường của nó trong bộ nhớ chỉ một lần và sau đó sử dụng lại nhiều lần cho mỗi lần nhấn?

Nó được gọi là opcode-cacheing.

http://en.wikipedia.org/wiki/PHP_accelerator

bạn có thể sẽ không quản lý để giảm việc sử dụng ram nhiều như vậy. Nhưng nếu bạn đang sử dụng mod_php, bạn có thể muốn chuyển sang mod_fcgidthay thế.

trong khi mod_php chậm hơn một chút, nó tải php ngay cả khi không cần, chẳng hạn như phục vụ hình ảnh, tệp tĩnh hoặc thậm chí lưu vào bộ đệm. Nếu bạn có nhiều yêu cầu, đây là rất nhiều ram.

sử dụng fcgid sẽ giảm điều này rất nhiều.

Ngoài ra, sử dụng bộ đệm tĩnh (như bộ đệm w3total) sẽ tránh gọi php hoàn toàn là một lợi thế thực sự: sử dụng ít ram hơn, ít kết nối db hơn.

Hà. Bây giờ tôi đang làm việc trên một ứng dụng web mà tôi hoàn toàn có ý định quá tải dữ liệu và việc sử dụng vượt quá những gì tài khoản lưu trữ chia sẻ của tôi có thể xử lý, vì vậy tôi đã quyết định - trong khi nó rất dễ để xây dựng trong WP - để thử làm việc từ BackPress như một khung và chỉ xây dựng những gì tôi cần cho các trường hợp sử dụng cụ thể của mình.

Vì vậy, tôi đã có thể giảm môi trường cốt lõi của mình từ hàng trăm tệp PHP trong WP xuống chỉ còn hai mươi hoặc tôi thực sự cần, trong khi vẫn có thể tận dụng tất cả db, HTTP, quản lý người dùng, định dạng và cron các chức năng mà tôi yêu thích trong WordPress.

Vấn đề là rất nhiều công việc, và tôi sẽ không bao giờ tin vào hackjob của mình cho bất cứ điều gì ngoài việc sử dụng cá nhân của riêng tôi. Nếu bạn muốn sử dụng môi trường WP đầy đủ, hãy sử dụng nó. Nó tốt như nó là bởi vì hàng trăm nhà phát triển tinh chỉnh nó trong nhiều năm. Giống như mọi người ở đây đã nói, bạn sẽ nhận được nhiều hơn nữa bằng cách tìm một kế hoạch lưu trữ tốt hơn và nghiên cứu các kỹ thuật lưu trữ hơn là bạn có thể có được bằng cách hack lõi.

Có, WordPress tải lên mọi thứ trước và sau đó thực hiện những gì chúng tôi yêu cầu. Tôi có thể nhớ lại ở đâu đó rằng chúng ta có thể tạo một nhóm ảo trong RAM nơi chúng ta có thể đặt các tệp. Tôi đã có ý tưởng đưa toàn bộ WordPress vào bộ nhớ (<10MB) và sau đó chúng ta có thể tiết kiệm rất nhiều I / O mà chỉ một mình sẽ tăng tốc độ. Nhưng tôi chưa bao giờ có cơ hội để thử nó và hơn nữa tôi không thực sự thành thạo trong việc theo đuổi thứ gì đó như thế. Nhưng nó có vẻ đáng thử.

một vài gợi ý cơ bản:

1. w3 tổng bộ đệm cache cho bộ nhớ đệm ..
2. cài đặt và kích hoạt memcache, cũng kích hoạt từ cài đặt bộ đệm tổng w3 (bộ đệm opcode cũng là một tùy chọn tốt nhưng nó không hoạt động tốt với plugin tổng bộ đệm w3)
3. giảm thiểu các truy vấn để liên kết trực tiếp trong các tập tin chủ đề ..
4. Vô hiệu hóa tất cả các plugin không sử dụng thêm và loại bỏ.
5. tối ưu hóa cơ sở dữ liệu.

Tôi đang điều hành một trang web wordpress nổi tiếng với lưu lượng truy cập lớn hàng ngày .. tôi thậm chí không tận tâm, làm rất tốt cho tôi :)