Наскільки добре масштабується WordPress?

З новим WordPress та його новими можливостями здається, що WordPress здатний набагато більше, ніж простий блог. Але наскільки добре використовується масштаб WordPress, який говорять 10k -> 100k користувачів на день?

Зважаючи на це багато користувачів, велика частина цього полягатиме в тому, щоб мати гарну стратегію кешування, але наскільки добре розроблено WordPress, щоб допомогти, полегшивши це і надавши вам необхідний контроль. Fx, здатний кешувати частину сторінки та лише рендерувати користувальницькі деталі, підтримувати налаштування основного / підлеглого DB та подібні речі?

Зрозуміло, що нічого не масштабує, а також статичні файли, що обслуговуються швидким веб-сервером та будь-якою CMS, яка повинна з'ясувати, що завантажити та потім завантажити, вона не буде працювати, як WordPress чи іншим способом. Одне з питань - кількість запитів до бази даних, необхідних для запиту URL, і мій досвід попередніх років, що працював виключно з Drupal, а тепер 2+ роки з WordPress, полягає в тому, що WordPress набагато кращий у цьому відділі.

Але це означає , що майже нічого з будь-якою владою не збирається масштабувати "поза межами" ; це все про те, що ти можеш зробити, коли зростає потреба в масштабованості?

На низькому кінці "багато трафіку" є чудові плагіни кешування та інтеграції з недорогими CDN, ви можете зробити досить непогану роботу за відсутності ІТ-бюджету та низького бюджету хостингу. Ось деякі питання та відповіді на розгляд:

• Кроки з оптимізації WordPress щодо завантаження сервера?
• Варіанти для CDN з WordPress, включаючи допоміжні плагіни?
• Налаштування WordPress для Amazon CloudFront кешування?

Існують варіанти профілювання для виявлення вузьких місць продуктивності :

• Профілювання веб-сайту WordPress для розгортання на спільному хостингу?

Після виявлення вузьких місць ви можете зробити локалізовану оптимізацію з такими речами, як API перехідних процесів . Це запитання дає приклад, який можна оптимізувати за допомогою API Transients та показує, як:

• Використання WP_Query для запиту кількох категорій з обмеженими повідомленнями на категорію?

Якщо ви дійсно захочете витягнути великі гармати, ви можете налаштувати Memcached , HyperDB , Nginx та / або більше для прискорення роботи (схоже, остання дійсно перетворюється на спосіб отримати дивовижну масштабованість з WordPress):

• Увімкніть Memcached для вашої WordPress
• Як пришвидшити WordPress за допомогою кешу Nginx та WP Super
• HyperDB
• Nginx як кеш-проксі кеш для WordPress

І нарешті з'являються нові веб-хости, орієнтовані на WordPress, які спеціалізуються на таких характеристиках , як WP Engine , ZippyKid та інші:

• Найкращі функції веб-хостингу високого класу WordPress?

Тож гарна новина - це всі масштаби дуже гарно ; з дуже низького кінця - вільного та легкого з технічною складністю та витратами тільки зростають у міру зростання трафіку. Почніть з малого WordPress, і це буде чудово. Якщо ваш трафік зростає, і ви монетизуєте його навіть розумно, ви вважаєте, що це дуже вагомий ефект, щоб масштабувати, як вам потрібно.

Принаймні ІМО. :)

1. Не чекайте багато від спільного хостингу - не звинувачуйте WordPress у повільності, якщо ви перебуваєте на спільному хості. Спільні хости можуть зв'язати 1000 тисяч облікових записів на одному сервері. Таким чином, ви можете витратити цілий день на оптимізацію рахунку в $ 10 на місяць, і це не має значення. Також слідкуйте за маркетинговими словниками - лише тому, що там написано, що "хмара" не означає, що ви не ділите один сервер зі 100-мами або 1000-ма людьми.

2. Я не думаю, що плагіни кешу потрібні на даний момент. Якщо ви подивитеся на вихідний код WP, у ядрі вже є розширене кешування. Кеш-пам'ять кеш-пам’яті кеша - пильнуйте, це може бути контрпродуктивним.

3. Головне, що сповільнює вас - це повільні запити MySQL, і WordPress нестабільний не повинен створювати тут проблем. Однак мені довелося "ОБМЕЖИТИ" свої запити коментарів, оскільки у мене було 50 000+ коментарів. (Це ще виправлено?) Також, якщо ви робите щось нетипове (наприклад, 1000 тисяч категорій?), Це теж може бути проблемою.

4. Я використовую Linode 512 з NginX і "вгорі" показує, що PHP і NginX роблять свою роботу менше ніж на 1/100 секунди за запит. Майже весь час процесора пов'язаний з MySQL. Ви можете обслуговувати 1 мільйон сторінок щомісяця за допомогою $ 20 Linode, але як тільки ви почнете додавати плагіни та фотографії, я думаю, вам знадобиться Linode "1 Гб". З моєї точки зору, це майже лінійно: якщо перегляд сторінок подвійний, просто подвойте розмір вашого Linode.

Відмова: Я не працюю для Linode.

Оновлення (~ 2 роки пізніше), оскільки ви хочете кешувати частини сторінки за допомогою PHP, ось просте рішення, яке я використовую, це напрочуд швидко. Я кешую кілька окремих частин / частин на сторінці протягом 1/100-ї секунди. Здається, що рамковий диск може зробити це ще швидше, але це досить швидко для моїх потреб:

$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;        
} 

У кінцевому рахунку є три речі, які уповільнюють WordPress в масштабі, і вони зводяться до цього:

• Хостинг стека - вам потрібен хороший хост із найновішим програмним забезпеченням - PHP 7, Nginx, Varnish, Redis, fail2ban і PerconaDB - все це хороший вибір
• Без сканування таблиці - багато плагінів написані аматорськими кодерами, які навіть не знають, що таке сканування таблиці. Дві речі потрібні, щоб уникнути сканування таблиць - корисний індекс та запит, написаний таким чином, що він може використовувати індекс
• Ніяких або декількох запитів SQL всередині циклів PHP - якийсь код плагіна явно був протестований лише на крихітних сайтах, і з тієї чи іншої причини буде проглядати кожен продукт у вашій базі даних і робити новий дзвінок SQL для кожного продукту / публікації. В ідеалі ви хочете менше 100 запитів SQL на сторінку - це звучить як багато, але це не дуже, і з <100 ви отримаєте TTFB близько 200 мс без збереження.

Після того, як у вас буде зазначене вище, ви можете додати кешування - наприклад, лак, CDN, кешування сторінок тощо.

Якщо вам потрібно масштабувати, ви можете створити кластер, використовуючи PerconaDB XtraDB для бази даних та Unison для файлів. Таким чином, ви можете мати 1 вузол як свого wp-адміністратора та бігуна cron, а також інші вузли, що обслуговують веб-трафік за балансиром навантаження.