Реальний досвід досвіду масштабування та налаштування продуктивності


54

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

Ігноруючи той факт, що цей показник звернень, мабуть, дикий оптимізм клієнта, окрім отримання можливих найбільших серверів, який найкращий спосіб налаштовувати Drupal на підтримку великої кількості відвідувачів.

Я читав «Масштабування інфраструктури drupal.org» , блог про ефективність Drupal , « Кращі практики масштабування Drupal» та багато інших сторінок, але те, що я шукаю, - це справжній досвід цього робити, що працює, що ні, а що робити очікувати.

Відповіді:


47

Відповідь Маркдорісона - це загальноприйнятий метод атаки на цю проблему. Я візьму це трохи далі.

Коли у вас є Pressflow для D6 або Drupal для D7, Memcached і Varnish, що все добре працює разом, вам потрібно буде настроїти код вашого файлу VCL . Є безкоштовні, які створюють вихідні точки, але завжди потрібно грати з ними.

Щоб оптимально працювати Varnish, переконайтеся, що ви запускаєте його з -s malloc xG, а не за замовчуванням файлу -s / path / to / file за замовчуванням. Також у Varnish є статичні елементи кешу лаку настільки, наскільки ви можете.

Якщо у вас є більше одного веб-сервера, видаліть ETag із заголовка, надісланого до Varnish у VCL. Я також видаляю Expires і просто покладаюсь на вік та максимальний вік у заголовках, тому повертайте браузери на сайт.

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

Налаштуйте кешування в "Продуктивність" на зовнішнє та встановіть максимальний вік, який надсилатиме правильні заголовки до проксі-сервера кешування, такого як 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. Кінцевим результатом має бути якомога менше таких користувачів, які фактично потрапляють на ваш початковий сервер.

Якщо у вас є частини сторінки, які ви не в змозі кешувати для неанонімних користувачів (специфічні для цього користувача речі, "Ласкаво просимо користувачX" тощо), ви можете вивчити варіанти заповнення цих фрагментів сторінки, наприклад, асинхронних. зворотний зв'язок або крайова сторона включає.

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


Річард: Моє задоволення. Повідомте мене, якщо у вас є додаткові запитання.
Маркдорісон

16

2500 звернень за секунду протягом дня - якщо під "ударом" ви маєте на увазі "сторінку доставлено", то це 216 мільйонів сторінок на день. Скажу вам так: у вас немає 216 мільйонів сторінок на день. Я люблю цих клієнтів ...

Однак, необроблені дані про трафік нічого не говорять. Хоча поради в цій темі звучать щодо Varnish / CDN, якщо у вас є анонімний трафік, але якщо ви ввійшли в трафік, перед вами стоїть проблема. Але перш ніж витратити нечестиву кількість часу та зусиль на вирішення проблеми, переконайтеся, що у вас є проблема. 2500 хітів за секунду, бінг отримує менше за це, ви це розумієте, правда?


2
2500 / сек - номери клієнта, що базується на тому, що, на мою думку, ми всі визнали дикими здогадами; це все, що мені довелося продовжувати. Як виявляється, запуск не був таким успішним, як вони планували (сподівались), і, як не дивно, фактична швидкість досягла 20 (сторінок) в секунду протягом приблизно 10 хвилин - головним чином, анонімна, середньодобова 7,32 сторінки / сек .....
Річард Гаррісон

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

    • Встановіть лак для кешування сторінок для анонімних користувачів.
    • Встановіть стійку кеш-систему (Memcached, APC, Memcache).
    • Використовуйте CDN, такий як Akamai, для обслуговування статичних файлів (JavaScript, CSS, зображення).
  • Кодова сторона

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

    • Переконайтесь, що таблиці правильно індексовані для швидшого пошуку.
    • Не зберігайте зайві записи, до 100-ти вузлових баз даних завжди можна отримати доступ швидше, ніж 3-мільйонна база даних.


4

Хоча дуже складно передбачити шаблони, якщо у вас є чітке уявлення про рівень трафіку. Завантажте тест свого рішення. Існує безліч різних варіантів, і багато чого неможливо буде передбачити, поки ви не будете мати трафік в реальному часі, але якщо ви завантажите тест якнайбільше, принаймні, у вас буде достатньо впевненості, що ваша установка може управляти трафіком.

Вся настройка у світі не допоможе, якщо ви не спробуєте її спочатку.

Це була презентація в DC SF про те, як це зробив економіст. http://sf2010.drupal.org/conference/sesions/performance-testing-economist-online-using-grinder


Посилання на презентацію справді дуже корисна. Спасибі
Річард Гаррісон

4

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

Використання мережі доставки вмісту ( 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).
  • Встановіть інтеграційний модуль інтеграції лаку та лаку HTTP Accelerator , а потім налаштуйте його .
  • Лак + Authcache: Перевірте цей приклад VCL для конфігураційного файлу Authcache Varnish.
  • Розгляньте фунт або NGINX перед лаком. Дивіться: Чому Фунт перед дивовижним лаком дивним .
  • 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"під 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

налаштування.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

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

Після зміни PHP_INI_SYSTEM перезавантажте веб-додаток. Якщо ви хочете дізнатися більше про конфігурацію twigging, перегляньте документацію Microsoft .

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


0

Ви також можете перевірити перерозподіл навантаження на декілька серверів за допомогою рішення, що базується на DNS або програмному та апаратному забезпеченні. Це також призведе до відмови.


Це не є гарною відповіддю, оскільки не стосується того, як цього досягти. як вже згадувалося в OQ, це реальний світовий досвід масштабування, за яким я йду.
Річард Гаррісон

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

Відмінно. Це може бути корисним посиланням. Опублікуйте все одно ...
Річард Гаррісон

Чи отримали Ви дозвіл на повторне оновлення контуру?
Річард Гаррісон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.