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

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

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

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

54 голоса | спросил Richard Harrison 3 MaramThu, 03 Mar 2011 07:51:40 +03002011-03-03T07:51:40+03:0007 2011, 07:51:40

9 ответов


48

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

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

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

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

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

Настройте кеширование в «Производительности» на внешний и установите максимальный возраст, который отправит правильные заголовки в кеширующий прокси-сервер, такой как 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.

ответил Stewart Robinson 3 MarpmThu, 03 Mar 2011 12:11:37 +03002011-03-03T12:11:37+03:0012 2011, 12:11:37
23

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

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

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

ответил markdorison 3 MaramThu, 03 Mar 2011 07:58:05 +03002011-03-03T07:58:05+03:0007 2011, 07:58:05
16

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

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

ответил 22 MaramTue, 22 Mar 2011 11:46:10 +03002011-03-22T11:46:10+03:0011 2011, 11:46:10
7
  • Серверная сторона

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

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

    • Убедитесь, что таблицы были правильно проиндексированы для более быстрого поиска.
    • Не храните ненужные записи, база данных из 100 узлов будет всегда доступна быстрее, чем база данных с 3 миллионами узлов.
ответил amateur barista 22 MaramTue, 22 Mar 2011 10:08:27 +03002011-03-22T10:08:27+03:0010 2011, 10:08:27
6

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

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

ответил Randy Burgess 3 MaramThu, 03 Mar 2011 08:19:38 +03002011-03-03T08:19:38+03:0008 2011, 08:19:38
4

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

Вся настройка в мире не поможет, если вы не проверите ее в первую очередь.

Это была презентация в DC SF о том, как это сделал экономист. http://sf2010.drupal.org/conference/sessions /производительности тестирования-экономист-онлайн-помощи-шлифовальный станок

ответил Jeremy French 3 MarpmThu, 03 Mar 2011 12:11:32 +03002011-03-03T12:11:32+03:0012 2011, 12:11:32
4

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

Использование сети доставки контента ( CDN ) помогает распределить ресурсы по нескольким доменам ( domain sharding), который уменьшает нагрузку на веб-сервер.

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

Примеры поставщиков: Быстро , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

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

  • С CDN используйте cookieless domains для статических компонентов, которые будут кэшироваться ( например sstatic.net ). Поскольку некоторые прокси-серверы могут отказаться кэшировать компоненты, запрашиваемые с помощью куки-файлов.
  • Обогревайте свои кеши после очистки кешей (используя wget, Warmer cache , Drush ECL ).
  • Использовать мониторинг производительности (например, Новая реликвия или Yottaa , которые имеют интеграцию для Drupal).
  • Используйте инструмент мониторинга для вашего сайта (например, Nagios).
  • Установить лак и Varnish HTTP Accelerator Integration module , затем настроить его .
  • Varnish + Authcache: проверьте это Пример VCL для Authcache Файл конфигурации Varnish.
  • Рассмотрим Фунт или NGINX перед лаком. Смотрите: Почему Фунт является удивительным перед Лак .
  • NGINX может работать как обратный прокси-сервер и балансировщик нагрузки, поэтому он может заменить фунт и лак.
  • Рассмотрим коммерческую версию Varnish или NGINX для использования функций, недоступных в версии с открытым исходным кодом сообщества.
  • Рассмотрим аппаратный loadbalancer /caching для замены Varnish and Pound (например, BIG-IP F5 ).
  • Используйте такие инструменты, как ab, JMeter для TTFB , загрузить и стресс-тестирование вашего веб-приложения.

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

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

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

ответил kenorb 28 J000000Thursday16 2016, 18:51:47
1

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

  • OPCache Zend
  • wincache

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

Если вы ищете флешку Zend OPcache и Wincache в Microsoft Azure, сначала создайте имя папки â € ini â € D: \ home \ site \ â € ™. Кроме того, создайте 2 файла, ini и 'D:\home\site\ â € ™

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

.user.ini

.user.ini

setting.ini

settings.ini

Кроме того, добавьте настройку приложения в свое веб-приложение с помощью клавиши [PHP] post_max_size = 32M memory_limit = 512M zend.enable_gc = On upload_max_filesize = 32M opcache.enable=1 и значения wincache.ocenabled = 1 wincache.ocachesize = 255

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

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

ответил npcoder 11 PM00000090000005831 2017, 21:35:58
0

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

ответил James Stallings 4 MaramFri, 04 Mar 2011 00:37:49 +03002011-03-04T00:37:49+03:0012 2011, 00:37:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132