Реальный мировой опыт в масштабировании и настройке производительности


54

Веб-сайт, на котором я работаю, вскоре после запуска получит огромный рейтинг популярности . Клиент говорит о возможности около 2500 обращений в секунду в течение дня или около того.

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

Я читал «Масштабирование инфраструктуры drupal.org» , блог о производительности Drupal , « Лучшие практики для масштабирования Drupal» и многие другие страницы, но я ищу реальный опыт, как это делать, что работает, что нет, и что нужно делать. ожидать.

Ответы:


47

Ответ Маркдорисона - в основном принятый метод решения этой проблемы. Я возьму это немного дальше.

Когда у вас есть Pressflow для D6 или Drupal для D7, Memcached и Varnish, все прекрасно работают вместе, вам нужно будет индивидуально кодировать ваш VCL- файл. Есть бесплатные, которые дают стартовые очки, но вам всегда нужно играть с ними.

Для оптимальной работы Varnish убедитесь, что вы запускаете его с -s malloc xG, а не по умолчанию -s file / path / to / file. Также с Varnish есть статичные элементы кеша Varnish так долго, как вы можете.

Если у вас более одного веб-сервера, удалите ETag из заголовка, отправленного Varnish в VCL. Я также удаляю Expires и просто полагаюсь на Age и max-age в заголовках, чтобы браузеры возвращались на сайт.

Версия 1.5 (по состоянию на 3 марта 2011 г.) по-прежнему является самой быстрой версией модуля Memcached от Drupal.org. Я обычно развертываю его, используя одну ячейку на сервер, чтобы уменьшить трафик tcp для соединений с несколькими ячейками в больших масштабах)

Сконфигурируйте кэширование в «Производительности» для внешнего и установите максимальный возраст, который будет отправлять правильные заголовки на прокси-сервер кэширования, такой как Varnish.

Если вы не можете заставить определенные страницы кэшироваться должным образом в Varnish, проверьте сообщения в блоге в Интернете, в которых подробно описано, как проверять запросы. Вот пример сообщения, которое я написал некоторое время назад: Что мешает Varnish и Drupal Pressflow от кэширования просмотров страниц анонимными пользователями

Вы должны выбрать InnoDB (или одно из его других имен от других провайдеров, таких как XtraDB) для MySQL и переместить все таблицы в него. Затем ознакомьтесь с этим сообщением в блоге для получения базовых советов по настройке http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/.

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

Другие основы включают использование APC для PHP. Если вы предпочитаете быстрый CGI, а не mod_php, потратьте некоторое время на попытки сделать кэш APC общим для всех экземпляров php, настроив хороший скрипт-обертку. Также убедитесь, что кэш APC находится в файле отображения памяти, чтобы выжать каждый последний бит из PHP.


«Если вы предпочитаете быстрый CGI, а не mod_php, потратьте некоторое время, пытаясь сделать кэш APC общим для экземпляров php, настроив хороший скрипт-обертку. Также убедитесь, что кэш APC находится в файле отображения памяти, чтобы сжать каждый последний бит вне PHP. " Ок, как там все сделано? Спасибо
Джон

1
Для памяти, сопоставленной apc, это зависит от флагов компиляции ... php.net/manual/en/apc.configuration.php
Стюарт Робинсон,

23

Я бы порекомендовал начать с Pressflow (при использовании Drupal 6), Memcache , Varnish и некоторой формы сети распространения контента (CDN), такой как Akamai. Конечный результат должен заключаться в том, чтобы как можно меньше таких пользователей действительно попадало на ваш исходный сервер.

Если у вас есть части страницы, которые вы не можете кэшировать для неанонимных пользователей (вещи, характерные для этого пользователя, «Welcome userX» и т. Д.), Вы можете изучить варианты заполнения этих частей страницы, например асинхронные. обратные вызовы или боковая сторона включает.

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


Ричард: С удовольствием. Дайте мне знать, если у вас есть дополнительные вопросы.
Маркдорисон

16

2500 посещений в секунду в течение дня - если под «попаданием» вы подразумеваете «доставленная страница», то это 216 миллионов страниц в день. Позвольте мне сказать вам следующее: у вас нет 216 миллионов страниц в день. Я люблю этих клиентов ...

Тем не менее, необработанные данные о трафике ничего не говорят. Несмотря на то, что совет в этой теме звучит правдоподобно в отношении Varnish / CDN, если все, что у вас есть, это анонимный трафик, но если вы вошли в трафик, вы столкнулись с проблемой. Но прежде чем тратить безбожное количество времени и усилий на решение проблемы, убедитесь, что у вас есть проблема. 2500 попаданий в секунду, bing получает меньше, понимаешь?


2
2500 / сек - это числа клиентов, основанные на том, что, как мне кажется, мы все признали дикой догадкой; это все, что мне нужно было сделать. Как оказалось, запуск был не таким успешным, как планировалось (на что надеялись), и, как ни странно, реальная скорость достигла пика в 20 (страниц) в секунду в течение примерно 10 минут - в основном анонимно, со средним ежедневным значением 7,32 стр / сек .....
Ричард Харрисон

7
  • Серверная сторона

    • Установите Varnish для кэширования страниц для анонимных пользователей.
    • Установите постоянную систему кэширования (Memcached, APC, Memcache).
    • Используйте CDN, такой как Akamai, для обслуживания статических файлов (JavaScript, CSS, изображения).
  • Сторона кода

    • Используйте Pressflow, он позволяет Varnish обслуживать кэшированную страницу для анонимных пользователей.
    • Очистить сторожевой стол Друпала. Каждый раз, когда регистрируется ошибка сторожевого таймера, он потребляет ресурсы ЦП на веб-сервере и сервере базы данных. Это также значительно увеличивает время загрузки.
    • Реализовать статические и постоянные кэш - стратегии до тех пор , журнал медленных запросов не приходит в чистоте.
    • Избегайте ошибок PHP, которые возникают во вложенных циклах foreach любой ценой.
    • Удалите неиспользуемые модули.
    • Включите кеширование для основных блоков Drupal и Views.
  • База данных

    • Убедитесь, что таблицы правильно проиндексированы для быстрого поиска.
    • Не храните ненужные записи, база данных из 100 узлов всегда будет доступна быстрее, чем база данных из 3 миллионов узлов.


4

Пока очень сложно прогнозировать закономерности, если у вас есть четкое представление об уровнях трафика. Загрузите тест вашего решения. Существует множество различных опций, и многое будет невозможно предсказать до тех пор, пока у вас не будет живого трафика, но если вы максимально загрузите тестирование, по крайней мере, у вас будет достаточная степень уверенности в том, что ваши настройки могут обрабатывать трафик.

Все настройки в мире не помогут, если вы сначала не протестируете их.

Это была презентация в DC SF о том, как это сделал экономист. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online-using-grinder


Ссылка на презентацию действительно очень полезна. Спасибо
Ричард Харрисон

4

Для сайтов с большим трафиком вы должны использовать несколько серверов и балансировщик нагрузки или просто использовать CDN. Также очень важно максимально кэшировать данные, чтобы минимизировать нагрузку на веб-серверы.

Использование Content Delivery Network ( CDN ) помогает распределить ресурсы по нескольким доменам (разделение доменов), что снижает нагрузку на веб-сервер.

Использование CDN помогает в распределенном кэшировании и удаленном ускорении, а также помогает смягчить атаки DDoS из-за множества конечных точек. Это помогает с безопасностью, потому что кешированный контент труднее использовать.

Пример провайдеров: быстро , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Вот еще несколько предложений:

  • В CDN используйте домены без cookie-файлов для статического кэширования компонентов (например, sstatic.net ). Поскольку некоторые прокси могут отказываться кэшировать компоненты, которые запрашиваются с помощью файлов cookie.
  • Согрейте свои кеши после очистки кешей (используя wget, Cache Warmer , Drush ECL ).
  • Используйте мониторинг производительности (например, New Relic или Yottaa, которые имеют интеграцию для Drupal).
  • Используйте инструмент мониторинга для вашего сайта (например, Nagios).
  • Установите модуль интеграции Varnish и Varnish HTTP Accelerator , затем настройте его .
  • Varnish + Authcache: проверьте этот пример VCL для файла конфигурации Authcache Varnish.
  • Рассмотрим фунт или NGINX перед лаком. Смотрите: почему Pound великолепен перед Varnish .
  • NGINX может работать как обратный прокси-сервер и балансировщик нагрузки, поэтому он может заменить Pound и Varnish.
  • Рассмотрим коммерческую версию Varnish или NGINX, чтобы использовать функции, недоступные в «открытой» версии с открытым исходным кодом.
  • Рассмотрим аппаратный балансировщик нагрузки / кэширование для замены лака и фунта (например, BIG-IP F5 ).
  • Используйте такие инструменты, как abJMeter для TTFB , нагрузочное и стресс-тестирование в вашем веб-приложении.

Таким образом, ваша веб-архитектура с точки зрения пользователя может выглядеть так:

  1. Пользователь (локальное кеширование браузера).
  2. NGINX или Pound + Varnish (балансировщик нагрузки, обратный прокси-сервер в качестве HTTP-ускорителя).
  3. Apache (веб-сервер).
  4. PHP-FPM (менеджер процессов PHP FastCGI).
  5. MariaDB (база данных).

Для предложения оптимизации Drupal, проверьте: Как вы улучшаете производительность Drupal?


1

Включить два расширения:

  • Zend OPcache
  • wincache

Ваше выступление будет работать лучше.

Если вы хотите подключить Zend OPcache и Wincache в Microsoft Azure, сначала создайте имя папки ini«under D:\home\site\». Кроме того, создайте 2 файла, ' .user.ini' и ' settings.ini'

Добавьте следующую конфигурацию в каждый файл:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Кроме того, добавьте параметр приложения в ваше веб-приложение с ключом PHP_INI_SCAN_DIR и значением d:\home\site\ini

После изменения PHP_INI_SYSTEM перезапустите ваше веб-приложение. Если вы хотите узнать больше о конфигурации веток, обратитесь к документации Microsoft .

После вышеупомянутой настройки мой сайт Drupal (Drupal 8.3) загружается в течение 3 секунд.


0

Вы также можете проверить перераспределение нагрузки между несколькими серверами с помощью решения на основе DNS или программного / аппаратного балансирования нагрузки. Это также испечь в отказоустойчивости.


Это не очень хороший ответ, поскольку в нем не говорится, как этого добиться. как упоминалось в OQ, это опыт масштабирования в реальном мире, который мне нужен.
Ричард Харрисон

Если решающие силы решат, что мы сможем запустить drupal на работе, я буду рад предоставить блог-пост на 5+ страниц с описанием нашего оборудования и конфигурации.
Джеймс Сталлингс

Отлично. Это может быть полезной ссылкой. Отправьте это так или иначе ...
Ричард Харрисон

Вы получили разрешение опубликовать свой план?
Ричард Харрисон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.