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

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

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

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

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

Когда у вас есть 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.

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

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

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

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

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

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

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

• Сторона кода

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

• База данных

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

Я также послушал бы этот подкаст Lullabot о том, как они создали сайт Grammys.com для взрыва трафика в течение недели. Это было довольно образовательное объяснение.

http://www.lullabot.com/podcasts/podcast-92-grammycom

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

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

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

Для сайтов с большим трафиком вы должны использовать несколько серверов и балансировщик нагрузки или просто использовать 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?

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

• 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 секунд.

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