Масштабируемый хостинг WordPress для массового сайта?

Dedicated, Dedicated, Dedicated, Dedicated </steveballmer>

Хорошо, это из моей системы. Если бы я серьезно рассматривал сайт с таким высоким трафиком, и на самом деле, 500 кит / час - это МНОГО.

Я действительно действительно рассмотреть возможность создания моей собственной сети и кластера для ее размещения. Я бы начал, наверное, с 4-узловой системы. 2 интерфейса работают Лаковый кеш, и 2 бэкэнда, на которых работают как Apache, так и MySQL. Выполните циклическую репликацию между бэкэндами и запустите memcached для синхронизации сеанса.

Или вы можете разместить Varnish и Apache вместе на серверах, а серверы баз данных будут выполнять только базу данных. Если подумать, это могло бы быть лучшим выбором.

У меня есть серьезные опасения по поводу сайтов с высокой посещаемостью на виртуализированных серверах. В основном из-за производительности ввода-вывода, но также потому, что это может быть весьма пагубным для производительности других виртуальных машин, находящихся на том же сервере, что, вероятно, не является вашей проблемой, но это означает, что трафик других людей может потенциально мешать вашему сайту.

WP не так уж и плох, как вы думаете. Вам нужно будет сделать много оптимизаций, доменов без файлов cookie для мультимедиа, и все, что вы упомянули, поможет. Вам понадобится двухуровневое кеширование или, возможно, 3/4 слоя. CDN, кеш ReverseProxy, а также может выиграть от кеширования запросов с помощью кэша памяти, а также кеширования кода операции с помощью APC.

Можно сделать множество небольших оптимизаций, которые значительно увеличат производительность, и все они заслуживают изучения.

VarnishCache делает отличный кеш обратного прокси, но также и очень хороший балансировщик нагрузки, и поверьте мне, вам понадобится более одного внутреннего сервера. Если ваш веб-сайт важен, а время безотказной работы что-то для вас значит (приносит ли он вам деньги?), Тогда вам определенно понадобится более одного сервера.

Если подумать, если вы доставляете МНОГО медиаресурсов, изображений и т. Д., Я бы определенно рассмотрел еще пару серверов, вероятно, работающих с nginx вместо apache, обслуживающих media.yourdomain.com или совершенно другой без файлов cookie. домен, например домен sstatic.net, который используется на сайтах stackexchange.

Вот один пример того, как это сделать, но вам придется изменить IP-адреса для тех, которые находятся за пределами диапазонов RFC1918, на публично маршрутизируемые IP-адреса;)

Я собираюсь пресечь это в зародыше, пока никто не пожаловался на несколько пластинок A. Не переходя на уровень 3 и не выполняя сторону высокой доступности с помощью BGP или GSLB, выполнение неинтеллектуальной балансировки нагрузки с циклическим перебором DNS - хороший способ сделать это, не слишком дорого, на самом деле, очень недорого по сравнению. Вы можете сделать немного более интеллектуальный DNS с помощью таких сервисов, как Dynect, который выполнит некоторый уровень проверки хоста перед отправкой запросов вашим балансировщикам нагрузки.

Если вы выберете хороший выделенный сервер, они могут сделать некоторые или все вышеперечисленное за вас. Учитывая, что вы ожидаете довольно большой объем трафика, я могу легко сказать, что дешевый выделенный сервер (менее 200-300 долларов США в месяц), вероятно, будет ложной экономией и не сможет поддерживать уровень трафика, который вы ожидая получить.

Для крупномасштабного хостинга WordPress я бы выбрал WordPress VIP

VIP-хостинг WordPress работает на магистрали WordPress.com, которая распределяет нагрузку на 1200 серверов в 3 центрах обработки данных.

что вы получаете:

• Ваш сайт работает в сети WordPress.com (более 1200 серверов в трех дата-центрах)
• Неограниченное пространство и пропускная способность
• 24/7 IT поддержка
• Сеть доставки контента и ежечасное резервное копирование
• Защита от спама Akismet на уровне предприятия
• Отзывы об оптимизации и безопасности темы вашего сайта для более быстрого и безопасного сайта
• Интеграция с функциями WordPress.com, такими как Блоги дня, Мои комментарии, Сёрфер по тегам и Gravatars.
• Продвижение ваших новых блогов в нашем блоге для издателей
• Карта сайта и карта сайта новостей для улучшения работы поисковых систем и новостей Google
• Люди, выполнившие вход на WordPress.com, будут входить в ваш домен, что облегчит им комментирование вашего блога.

Расходы

начинается примерно с 2500 долларов в месяц.

Мы используем Rackspace Cloud, оно очень хорошо масштабируется для наших нужд. Не путайте это с облачными сайтами, а скорее с облачными серверами. По сути, вы создаете свой собственный кластер и можете масштабировать его как хотите.

Я управляю хостинг-компанией, работающей только на WordPress, но, честно говоря, я не сталкивался с объемом трафика, о котором вы говорите, поэтому я не хочу терять свою шляпу, я был бы более чем счастлив помочь и узнайте из своего опыта, что сработало, а что нет.

VPS.net - это полностью масштабируемое решение с высокой отказоустойчивостью. Это недорого, но при этом мощный и гибкий. MediaTemple - еще один хороший поставщик, потому что вы можете начать с менее мощной виртуальной машины, а затем масштабировать ее вплоть до своего собственного сервера (ов) простым нажатием кнопки. Вам следует искать поставщика, который может быстро масштабироваться по горизонтали (избыточность / кластер) и вертикально (больше памяти / ЦП / ОЗУ).

Я не могу говорить из личного опыта, но Двигатель WP была создана специально для этого вопроса.

Сайед Карим спросил: "Где / как вы в конечном итоге разместили сайт ..." так что вот мои "заметки с начала":

Я не нашел ни одной «автомагической» услуги или решения. Wordpress.com VIP Hosting, WP Engine и некоторые другие выглядят довольно интересно, но не подходят под этот счет. Итак, мы разместились непосредственно на Amazon Web Services (AWS).

Мы использовали (несколько больших) экземпляров сервера EC2 + Elastic Load Balancer + S3 / CloudFront, разгрузку ввода-вывода + оптимизация / минификация + кеширование + CloudWatch Monitoring + SNS-уведомления + Python / bash автоматизация / сценарии + репликация на основе Mercurial.

TL; DR детали:

Этот сайт был флеш-мобом для мероприятия с участием более 1 миллиона человек. За 15 дней до соревнования у него были только номинальные посетители, но затем он начал ускоряться до резкого склона, агрессивного подъема на Т-3 днях или около того. С помощью Google Analytics или мониторов производительности сайта вы можете наблюдать, как нагрузка заметно увеличивается с каждым часом.

Мы использовали серверы EC2 под управлением Ubuntu «Natty Narwhal», MySQL 5.1 и WordPress 3.x. За ними отвечал Elastic Load Balancer. Нам пришлось перенести DNS на сервис Amazon Route 53, чтобы обеспечить правильную работу ELB с нашим основным доменом (например, domain.tld, а не www.domain.tld).

Что касается серверов, мы предпочли масштабирование больше, чем масштабирование, чтобы избежать многих сложностей и потенциальных режимов отказа общих / реплицированных / кластеризованных пулов файлов MySQL и NFS / CFS. Мы могли и сделали горизонтальное масштабирование, но «в конечном итоге согласованным» и «все узлы используют свое собственное локальное хранилище». Изменения сайта были внесены на главный сервер, а затем изменения файлов и базы данных были реплицированы на остальную часть пула WP. Репликация выполнялась комбинацией Mercurial и SCP (есть более изящные способы, они просты и отлично работают).

В этой конфигурации в конечном итоге согласовано <= ~ 3 минуты. То есть некоторые пользователи могли видеть более старый контент в течение нескольких минут после его обновления.

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

Мы рассмотрели конфигурацию автомасштабирования, но, зная короткую продолжительность пиковых нагрузок и вероятную кривую спроса, а также имея хорошие показатели производительности и сигналы тревоги (начиная с CloudWatch и SNS), мы выбрали ручное масштабирование - еще один успешный выбор KISS.

Наиболее распространенной операцией масштабирования была активация экземпляра следующего по величине размера, автоматическая загрузка необходимого программного обеспечения, автоматическая репликация содержимого сайта и добавление его в группу ELB. Начиная с нуля активация экземпляра обычно занимает менее 3 минут. После подтверждения человеком сервер работал правильно и после добавления его в балансировщик нагрузки масштабирование заняло в общей сложности 5-10 минут. Затем мы обычно приостанавливаем работу замененного им экземпляра сервера. За те же 5-10 минут мы могли бы запустить несколько десятков новых серверов; мы тестировали, но на самом деле никогда не нуждались в этом.

Мы оценили размер инстанса до четырех сверхбольших инстансов с высоким объемом памяти для окончательной полной пиковой нагрузки. Мы рассмотрели кластерные вычислительные узлы с еще более высоким ЦП и более высокой пропускной способностью сети, но не развернули их, поскольку для них требуется другая сборка Linux (Amazon AMI, основанная на Red Hat / CentOS, а не на Ubuntu), и мы этого не сделали. хотите инвестировать в автоматизацию сборки или в обеспечение качества второй программной основы.

Мы использовали S3 для файлов, а клиенты обращались к нему через дистрибутив CloudFront (т. Е. Через S3 через CDN) для разгрузки операций ввода-вывода. Если судить по цифрам, самое важное, что мы сделали, - это агрессивное использование разгрузки ввода-вывода. Тоже самое простое.

Мы оптимизировали / минимизировали файлы JS, CSS и PHP для тем и плагинов WP, как могли. Такие изменения играют с нарушением кода, поэтому мы использовали Mercurial для отслеживания изменений и немедленного отката любых изменений, нарушивших работу сайта. К сожалению, дизайнеры выбрали некоторые плагины для галерей изображений и отображения ленты Twitter, которые были хороши, когда вы получаете 50 запросов в час, но не очень хороши в конфигурации масштабирования, прыгая прямо через выделенные ресурсы вашего процессора и Twitter API. Серьезно, Twitter не хочет, чтобы вы стучали в их дверь 100+ раз в секунду! Не сумев найти плагин или службу ленты Twitter, которая была бы гарантированно масштабируемой, я написал свой собственный простой механизм кэширования. Галерею изображений мы не могли исправить, не изменив внешний вид хотя бы тонкими способами, поэтому мы просто купили больше процессора, чтобы компенсировать его плохой дизайн. (В следующий раз: дизайнеры, пожалуйста, выберите тот, который использует только JS, а не PHP!)

Мы использовали инструменты разработчика YSlow, FireBug и Google Chrome для управления процессом оптимизации.

Мы использовали W3 TotalCache для уменьшения нагрузки на сайт. К сожалению, дизайн сайта не был совместим с полным кешированием (сломались некоторые плагины). У нас не было времени исправить эти проблемы, поэтому мы ограничили кеширование тем, что можно было сделать безопасно, и снова купили больше процессорного времени, чтобы компенсировать это.

Большая часть автоматизации была достигнута с помощью сценариев оболочки Bash или программ Python с использованием отличного модуля / API Boto. Мы рассматривали возможность использования средств обеспечения более высокого уровня, таких как Fabric, Chef и Salt, но различные сбои, с которыми мы столкнулись, говорили: «Мы классные, но вернитесь и попробуйте снова немного позже, хорошо?»

Результаты были отличными. Мы ни разу не упали и не прыгнули под нагрузкой. Мы были готовы и могли выдержать в 5 или 50 раз большую нагрузку, которую получили. Есть много вещей, которые мы могли бы сделать более элегантно. Некоторые из них были бы желательны или даже необходимы для сервисов, которые имеют разные требования - например, высокая нагрузка в течение более длительных периодов времени, большая изменчивость нагрузки или непредсказуемые всплески и т. Д. Но многие компромиссы KISS сработали хорошо, добившись практической победы при скромном DevOps. усилия и низкая стоимость исполнения.

Мое самое большое сожаление заключается в том, что мы не автоматизировали процесс обнаружения изменений контента и их репликации во всем парке. Нам требовалась координация вручную между операторами сайта и владельцами контента. Это работало нормально, учитывая короткое окно пиковых значений, но было обременительным. Если бы мне пришлось все это повторить, наблюдение за мастером за изменениями файлов / баз данных и автоматический запуск процесса репликации во всем парке было бы обновлением №1. (Это имело бы вторичное преимущество, состоящее в значительном увеличении масштабируемости предприятия; тогда мы могли бы использовать более мелкие и дешевые экземпляры серверов. Тогда автоматическое масштабирование конфигурации будет более эффективно.)