user94
  • 0
Новичок

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

  • 0

С новым WordPress и его новыми функциями кажется, что WordPress способен на гораздо большее, чем простой движок блога. Но насколько хорошо масштабируется WordPress при использовании, скажем, 10 000 -> 100 000 пользователей в день?

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

Share
  1. Ясно, что ничто не масштабируется так хорошо, как статические файлы, обслуживаемые быстрым веб-сервером, и любая CMS, которая должна выяснить, что загружать, а затем загрузить это, не будет работать так же хорошо, как WordPress или что-то другое. Одной из проблем является количество запросов к базе данных, необходимых для каждого URL-запроса, и мой 2-летний опыт работы исключительно с Drupal, а теперь более 2 лет с WordPress, показывает, что WordPress намного лучше в этом отношении.

    Тем не менее, почти ничто с любой мощностью не будет масштабироваться «из коробки» ; все дело в том, что вы можете сделать по мере роста ваших потребностей в масштабируемости?

    На нижнем уровне «большого трафика» есть отличные плагины кэширования и интеграции с недорогими CDN, с которыми вы можете неплохо справиться без бюджета на ИТ и с небольшим бюджетом на хостинг. Вот некоторые другие вопросы и ответы для обзора:

    Существуют варианты профилирования для выявления узких мест в производительности :

    После выявления узких мест вы можете выполнить локальную оптимизацию с помощью таких вещей, как Transients API. В этом разделе вопросов и ответов приводится пример, который можно оптимизировать с помощью Transients API, и показано, как:

    Если вы действительно хотите вытащить большие пушки, вы можете настроить Memcached, HyperDB, Nginx и / или что-то еще, чтобы ускорить работу (похоже, что последний действительно эволюционирует в способ получить потрясающую масштабируемость из WordPress):

    И, наконец, появляются веб-хосты, ориентированные на WordPress, специализирующиеся на производительности, такие как WP Engine, ZippyKid и другие:

    Итак , хорошая новость заключается в том, что все масштабы очень хорошие ; от самого низкого уровня до бесплатного и простого, а техническая сложность и стоимость только растут по мере значительного роста трафика. Начните с WordPress с малого, и все будет отлично. Если ваш трафик действительно растет, и вы достаточно хорошо его монетизируете, вы обнаружите, что масштабирование по мере необходимости очень эффективно с точки зрения затрат.

    По крайней мере, ИМО. 🙂

    • 0
    • Спасибо за такой обстоятельный ответ. Интересно, как API-интерфейсы WordPress работают с кэшированием частей страницы, поэтому вам нужно создавать только части, специфичные для пользователя, а не всю страницу для вошедших в систему пользователей или использовать Edge SideIncludes для сайтов с высоким трафиком.

      • 0
    • Майк, ты зверь! Куда бы я ни пошел на этом сайте, я натыкаюсь на ваши ответы, и все они великолепны!

      • 0
    • @googletorp : Вы определенно можете это сделать, для этого нужен код, созданный вручную. Я хотел бы посмотреть, можно ли разработать фреймворк, чтобы упростить его, но в настоящее время я сосредоточен на попытке реализовать надежные и многофункциональные настраиваемые поля сообщений. Может быть, когда-нибудь в ближайшее время. 🙂 @Voyagerfan5761 : Спасибо. 🙂

      • 0
    • kiragiannis.com/cloud-computing/… Это может привести к обсуждению некоторых показателей.

      • 0
    1. Не ожидайте многого от виртуального хостинга — не обвиняйте WordPress в медлительности, если вы находитесь на виртуальном хостинге. Общие хосты могут втиснуть тысячи учетных записей на один сервер. Таким образом, вы можете потратить весь день на оптимизацию аккаунта за 10 долларов в месяц, и это не будет иметь значения. Также следите за модными маркетинговыми словечками — то, что в нем говорится «облако», не означает, что вы не делите один сервер с сотнями или тысячами людей.

    2. Я не думаю, что плагины кеша необходимы на данный момент. Если вы посмотрите на исходный код WP, в ядро ​​уже встроено расширенное кэширование. Кэш кеша кеша кеша — будьте осторожны, это может привести к обратным результатам.

    3. Главное, что замедляет вас, — это медленные запросы MySQL, и готовый WordPress не должен доставлять вам проблем. Однако мне пришлось «ОГРАНИЧИТЬ» мои запросы комментариев, потому что у меня было более 50 000 комментариев. (Это уже исправлено?) Кроме того, если вы делаете что-то нетипичное (например, тысячи категорий?), это тоже может быть проблемой.

    4. Я использую Linode 512 с NginX, и «верхний» показывает, что PHP и NginX выполняют свою работу менее чем за 1/100 секунды на запрос. Почти все процессорное время связано с MySQL. Вы можете обслуживать 1 миллион страниц в месяц с помощью Linode за 20 долларов, но как только вы начнете добавлять плагины и фотографии, я думаю, вам понадобится 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;        
    } 
    
    • 0
  2. В конечном итоге есть 3 вещи, которые замедляют работу WordPress в масштабе, и они сводятся к следующему:

    • Стек хостинга — вам нужен хороший хост с новейшим программным обеспечением — PHP 7, Nginx, Varnish, Redis, fail2ban и PerconaDB — хороший выбор.
    • Никакого сканирования таблиц — многие плагины написаны программистами-любителями, которые даже не знают, что такое сканирование таблиц. Чтобы избежать сканирования таблицы, необходимы две вещи: полезный индекс и запрос, написанный таким образом, чтобы он мог использовать индекс.
    • Нет или мало SQL-запросов внутри PHP-циклов — код некоторых плагинов явно был протестирован только на крошечных сайтах, и по той или иной причине он будет перебирать каждый продукт в вашей базе данных и делать новый вызов SQL для каждого продукта/сообщения. В идеале вам нужно менее 100 SQL-запросов на страницу — звучит много, но на самом деле это не так, и с < 100 вы получите некэшированный TTFB около 200 мс.

    После того, как у вас есть все вышеперечисленное, вы можете добавить кэширование — например, Varnish, CDN, кэширование страниц и т. д.

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

    • 0

Оставить ответ

You must login to add an answer.