WordPress có quy mô tốt như thế nào?

Với WordPress mới và các tính năng mới của nó, có vẻ như WordPress có khả năng nhiều hơn một công cụ blog đơn giản. Nhưng quy mô WordPress được sử dụng tốt như thế nào khi nói 10k -> 100k người dùng mỗi ngày?

Với nhiều người dùng, phần lớn sẽ là có một chiến lược bộ nhớ cache tốt, nhưng WordPress được phát triển tốt như thế nào để giúp đỡ, làm cho điều này trở nên dễ dàng và cung cấp cho bạn quyền kiểm soát mà bạn cần. Fx có thể lưu trữ một phần của trang và chỉ hiển thị các phần tùy chỉnh của người dùng, hỗ trợ thiết lập db master / Slave và những thứ tương tự?

Rõ ràng không có quy mô cũng như các tệp tĩnh được cung cấp bởi một máy chủ web nhanh và bất kỳ CMS nào phải tìm ra những gì cần tải và sau đó tải nó sẽ không hoạt động tốt, WordPress hay cách khác. Một trong những vấn đề là số lượng truy vấn cơ sở dữ liệu cần thiết cho mỗi yêu cầu URL và kinh nghiệm 2 năm trước của tôi làm việc riêng với Drupal và bây giờ hơn 2 năm với WordPress là WordPress tốt hơn nhiều trong bộ phận đó.

Điều đó nói rằng, hầu như không có gì với bất kỳ quyền lực nào sẽ mở rộng quy mô "ngoài luồng" ; tất cả là về những gì bạn có thể làm khi nhu cầu mở rộng của bạn tăng lên?

Ở mức thấp của "nhiều lưu lượng truy cập", có các plugin và bộ nhớ đệm tuyệt vời với các CDN rẻ tiền, bạn có thể thực hiện công việc khá tốt với ngân sách không có CNTT và ngân sách lưu trữ thấp. Dưới đây là một số câu hỏi và câu trả lời khác để xem xét:

• Các bước để tối ưu hóa WordPress trong tải trọng máy chủ?
• Tùy chọn cho CDN với WordPress Bao gồm các Plugin hỗ trợ?
• Cấu hình WordPress cho bộ nhớ đệm Amazon CloudFront?

Có các tùy chọn để định hình để xác định các tắc nghẽn hiệu suất :

• Cấu hình một trang web WordPress để triển khai trên Hosting chia sẻ?

Khi các nút cổ chai được xác định, bạn có thể thực hiện tối ưu hóa cục bộ với những thứ như API Transents . Câu hỏi và trả lời này đưa ra một ví dụ có thể được tối ưu hóa bằng API Transents và chỉ ra cách:

• Sử dụng WP_Query để truy vấn nhiều danh mục với số lượng bài viết giới hạn trên mỗi danh mục?

Nếu bạn thực sự muốn rút ra những khẩu súng lớn, bạn có thể định cấu hình Memcached , HyperDB , Nginx và / hoặc nhiều thứ khác để tăng tốc mọi thứ (có vẻ như sau này thực sự đang phát triển thành cách để có được khả năng mở rộng đáng kinh ngạc của WordPress):

• Kích hoạt Memcached cho WordPress của bạn
• Cách tăng tốc WordPress với Nginx và WP Super Cache
• HyperDB
• Nginx là bộ đệm proxy phía trước cho WordPress

Và cuối cùng, có những webhost tập trung vào WordPress mới nổi chuyên về hiệu suất như WP Engine , ZippyKid và các trang khác:

• Các tính năng tốt nhất của máy chủ web WordPress cao cấp?

Vì vậy, tin tốt là tất cả các quy mô rất độc đáo ; từ đầu rất thấp miễn phí và dễ dàng với độ phức tạp kỹ thuật và chi phí chỉ tăng lên khi lưu lượng truy cập tăng đáng kể. Bắt đầu nhỏ với WordPress và nó sẽ rất tuyệt. Nếu lưu lượng truy cập của bạn tăng lên và bạn đang kiếm tiền thậm chí là hợp lý, bạn sẽ thấy nó có hiệu quả rất lớn về quy mô khi bạn cần.

Ít nhất là IMO. :)

1. Đừng mong đợi nhiều từ việc chia sẻ lưu trữ - đừng đổ lỗi cho WordPress vì sự chậm chạp nếu bạn đang ở trên một máy chủ được chia sẻ. Các máy chủ được chia sẻ có thể nhồi nhét 1000 tài khoản vào một máy chủ. Vì vậy, bạn có thể dành cả ngày để tối ưu hóa tài khoản $ 10 / tháng và điều đó không thành vấn đề. Ngoài ra, hãy coi chừng buzzwords tiếp thị - chỉ vì nó nói "đám mây" không có nghĩa là bạn không chia sẻ một máy chủ với 100 hoặc 1000 người.

2. Tôi không nghĩ các plugin cache là cần thiết vào thời điểm này. Nếu bạn nhìn vào mã nguồn WP, đã có bộ nhớ đệm nâng cao được đưa vào lõi. Một bộ đệm của bộ đệm của bộ đệm của bộ đệm - xem ra, điều này có thể phản tác dụng.

3. Điều chính làm bạn chậm lại là các truy vấn MySQL chậm và WordPress không sẵn sàng gây rắc rối cho bạn ở đây. Tuy nhiên, tôi đã phải "GIỚI HẠN" các truy vấn bình luận của mình vì tôi có hơn 50.000 bình luận. (Điều này đã được sửa chưa?) Ngoài ra, nếu bạn đang làm bất cứ điều gì không điển hình (như 1000 danh mục?) Cũng có thể là một vấn đề.

4. Tôi sử dụng Linode 512 với NginX và "top" cho thấy PHP và NginX đang thực hiện công việc của họ trong chưa đầy 1/100 giây mỗi yêu cầu. Gần như tất cả thời gian CPU được gắn với MySQL. Bạn có thể phục vụ 1 triệu trang mỗi tháng với Linode 20 đô la, nhưng một khi bạn bắt đầu thêm plugin và ảnh, tôi nghĩ bạn sẽ cần Linode "1GB". Theo quan điểm của tôi, nó khá tuyến tính: Nếu số lần xem trang tăng gấp đôi, chỉ cần tăng gấp đôi kích thước Linode của bạn.

Tuyên bố miễn trừ trách nhiệm: Tôi không làm việc cho Linode.

Cập nhật (~ 2 năm sau) vì bạn muốn lưu trữ các phần của trang bằng PHP, đây là một giải pháp đơn giản mà tôi sử dụng nhanh đến mức đáng ngạc nhiên. Tôi đang lưu trữ một số phần / phần riêng biệt trên mỗi trang trong vòng 1/100 giây. Có vẻ như một ramdisk có thể làm điều này thậm chí nhanh hơn nhưng nó rất nhanh cho nhu cầu của tôi:

$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file);  // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {

    // heavy lifting starts
    $output = 'Heavy!';
    // heavy lifting ends

    if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache    
    echo $output;

} else { 

    // load from cache
    $output = file_get_contents($cache_file); 
    echo $output;        
} 

Cuối cùng, có 3 điều làm chậm WordPress ở quy mô và họ hiểu rõ điều này:

• Ngăn xếp lưu trữ - bạn cần một máy chủ lưu trữ tốt với phần mềm mới nhất - PHP 7, Nginx, Varnish, Redis, fail2ban và PerconaDB đều là những lựa chọn tốt
• Không quét bảng - nhiều plugin được viết bởi các lập trình viên nghiệp dư, những người thậm chí không biết quét bảng là gì. Cần có hai điều để tránh quét bảng - chỉ mục có thể sử dụng và truy vấn được viết theo cách có thể sử dụng chỉ mục
• Không có hoặc một vài truy vấn SQL bên trong các vòng lặp PHP - một số mã plugin rõ ràng chỉ được thử nghiệm trên các trang web nhỏ và vì lý do này hay lý do khác sẽ lặp qua mọi sản phẩm trong cơ sở dữ liệu của bạn và thực hiện cuộc gọi SQL mới cho mỗi sản phẩm / bài đăng. Bạn lý tưởng muốn có ít hơn 100 truy vấn SQL trên mỗi trang - nghe có vẻ nhiều, nhưng thực sự không phải vậy và với <100, bạn sẽ nhận được một TTFB trong khoảng 200ms.

Khi bạn đã có những thứ ở trên, bạn có thể thêm bộ đệm - ví dụ Varnish, CDN, bộ đệm trang, v.v.

Nếu bạn cần mở rộng quy mô, bạn có thể tạo một cụm bằng PerconaDB XtraDB cho cơ sở dữ liệu và Unison cho các tệp. Bằng cách đó, bạn có thể có 1 nút làm người chạy wp-admin và cron của mình và các nút khác phục vụ lưu lượng truy cập web phía sau bộ cân bằng tải.