Це канонічне питання щодо планування потенціалу веб-сайтів.
Пов'язані:
Які деякі рекомендовані інструменти та методи планування потенціалу веб-сайтів та веб-додатків?
Будь ласка, опишіть різні інструменти та методи для різних веб-серверів, фреймворків тощо, а також найкращі практики, що стосуються веб-серверів загалом.
Відповіді:
Коротка відповідь: Ніхто не може відповісти на це питання, крім вас.
Довга відповідь полягає в тому, що тестування вашої конкретної навантаження - це те, що вам потрібно взяти на себе, адже це трохи схоже на запитання "Як довгий шматок струни?".
Простий статичний веб-сайт з однією сторінкою може розміщуватися на Pentium Pro 150 і зберігати тисячі показів щодня.
Основний підхід, який потрібно застосувати, щоб відповісти на це питання - це спробувати його і побачити, що відбувається. Існує безліч інструментів, за допомогою яких можна штучно піддавати вашій системі тиск, щоб побачити, де вона зависає.
Короткий огляд цього:
В основному для того, щоб перевірити деяке навантаження, вам потрібно щось протестувати. Створіть середовище для перевірки проти. Якщо це можливо, це може бути досить близьким до вашої виробничої апаратури, інакше ви не зможете екстраполювати свої дані.
Налаштуйте ваші сервери, акаунти, веб-сайти, пропускну здатність тощо. Навіть якщо ви це робите на віртуальних машинах, це нормально до тих пір, поки ви готові змінити свої результати.
Отже, я збираюся встановити віртуальну машину з середньою потужністю (два ядра, 512 МБ оперативної пам’яті, 4 ГБ жорсткого диска) та встановити улюблений балансир навантаження, haproxyвсередині Red Hat Linux, на VM.
У мене також будуть два веб-сервери за балансиром навантаження, які я буду використовувати для стрес-тестування балансира навантаження. Ці два веб-сервери налаштовані ідентично моїм живим системам.
Вам знадобляться деякі показники для моніторингу, тому я буду вимірювати, скільки запитів потрапляє на мої веб-сервери і скільки запитів я можу стискати за секунду, перш ніж користувачі почнуть отримувати час відповіді понад дві секунди.
Я також збираюсь відстежувати оперативну пам'ять, процесор і використання диска на haproxyприкладі, щоб переконатися, що балансир навантаження може обробляти з'єднання.
Як це зробити, багато що залежить від ваших платформ і виходить за рамки цієї відповіді. Вам може знадобитися переглянути файли журналів веб-сервера, запустити лічильники продуктивності або покластися на здатність звітувати інструмент стрес-тесту.
Кілька речей, які завжди хочеться стежити:
Ви також можете подивитися на тупіки SQL, шукати часу тощо, залежно від того, що ви спеціально тестуєте.
Ось тут справи отримують задоволення. Тепер вам потрібно змоделювати тестове навантаження. Є безліч інструментів, які можуть це зробити, з налаштованими параметрами:
Виберіть номер, будь-яке число. Скажімо, ви бачите, як система реагує на 10 000 звернень в хвилину. Не має значення, яке число ви вибрали, оскільки ви повторите цей крок багато разів, коригуючи це число вгору або вниз, щоб побачити, як реагує система.
В ідеалі, ви повинні розподілити ці 10 000 запитів на декількох клієнтах / вузлах, які перевіряють навантаження, щоб один клієнт не став вузьким місцем запитів. Наприклад, віддалене тестування JMeter забезпечує центральний інтерфейс, з якого можна запустити декілька клієнтів з керуючої машини Jmeter.
Натисніть чарівну кнопку Go і спостерігайте, як ваші веб-сервери тануть і виходять з ладу.
Отже, тепер вам потрібно повернутися до своїх показників, які ви зібрали на кроці 2. Ви бачите, що при 10000 одночасних з'єднань ваше haproxyполе ледве розриває потужність, але час відповіді з двома веб-серверами - це сенсор протягом п'яти секунд. Це не круто - пам’ятайте, ваш час відповіді має на меті дві секунди. Отже, нам потрібно внести деякі зміни.
Тепер вам потрібно пришвидшити свій веб-сайт більш ніж удвічі. Отже, ви знаєте, що вам потрібно або масштабувати, або масштабувати.
Щоб збільшити масштаб, отримуйте більше веб-серверів, більше оперативної пам’яті та швидших дисків.
Щоб розширити масштаб, отримайте більше серверів.
Використовуйте свої показники з кроку 2 та тестування, щоб прийняти це рішення. Наприклад, якщо ви побачили, що затримка диска була величезною під час тестування, ви знаєте, що вам потрібно збільшити масштаб і отримати швидші жорсткі диски.
Якщо ви бачили, що процесор сидів на 100% під час тесту, можливо, вам знадобиться масштабувати, щоб додати додаткові веб-сервери, щоб зменшити тиск на існуючі сервери.
Немає загальної правильної чи неправильної відповіді, є лише те, що підходить саме вам. Спробуйте збільшити масштаб, і якщо це не працює, замість цього наведіть масштаб. Або ні, це залежить від вас і трохи думати поза коробкою.
Скажімо, ми збираємося масштабувати. Тож я вирішив клонувати мої два веб-сервери (вони VM), і тепер у мене є чотири веб-сервери.
Почніть знову з кроку 3. Якщо ви виявите, що все не йде так, як ви очікували (наприклад, ми подвоїли веб-сервери, але час відгуку все ще перевищує дві секунди), тоді загляньте в інші вузькі місця. Наприклад, ви подвоїли веб-сервери, але все ще маєте шалений сервер баз даних. Або ви клонували більше віртуальних машин, але, оскільки вони перебувають на одному фізичному хості, ви домоглися лише більшої суперечки за ресурси сервера.
Потім ви можете скористатися цією процедурою для тестування інших частин системи. Замість того, щоб натискати на балансир завантаження, спробуйте вдарити безпосередньо веб-сервер або SQL-сервер, використовуючи інструмент тестування SQL .
Планування ємності починається з вимірювання, в цьому випадку часу реакції проти навантаження. Коли ви дізнаєтесь про ступінь уповільнення роботи програми з завантаженням, що НЕ є лінійною функцією, ви можете вибрати ціль часу відповіді, а потім виявити, які ресурси будуть потрібні для досягнення цілі для заданої кількості навантаження.
Вимірювання продуктивності завжди проводиться за допомогою одиниць часу , як
Такі речі, як% CPU та IOPS, залежать від системи, тому ви використовуєте їх лише тоді, коли ви запланували систему та виміряли її у попередньому виробництві, щоб діяти як "сурогат" для того, що вас хвилює, часу.
Планування потенціалу - клопіткий звір. Це стільки ж наука, скільки мистецтво (якщо, безумовно, темне).
Ваш найкращий випадок полягає в тому, що ви приймаєте добре обґрунтовані рішення, і удача / удача сприяє вам, реальність відповідає вашим припущенням. Якщо ваш потенціал потребує припущень, що відповідають дійсності, ви виглядаєте як містичний йог. На жаль, якщо ваші припущення перевищують реальність, ви, здається, матимете перевищення та перевитрату. Більше, на жаль, якщо ваші припущення нижчі від можливої реальності (або в іншому випадку невірні), вам не вистачить необхідної потужності, і вам доведеться намагатися зменшити помилки вашої стогінної інфраструктури, завдяки чому ви будете виглядати, як вам не вистачає компетентності.
Ніякого тиску...
На жаль, темне мистецтво планування потужностей більш ніж може бути розумно перероблене в одну відповідь про помилку сервера; дійсно, це тема, гідна книг.
На щастя, є така книга: " Мистецтво планування потенціалу "
Щоб розширити посаду Марка Хендерсона, я пишу це специфічне для Apache. Щоб повторити те, що він сказав: "Коротка відповідь: Ніхто не може відповісти на це питання, крім вас". Текст цієї відповіді сильно запозичений з моєї відповіді на аналогічне запитання про ефективність веб-сайту Drupal .
Можливо, Apache є одним із найпопулярніших веб-серверів (якщо не той). Він є відкритим кодом і досі активно підтримується. Ви можете запускати його як в операційних системах Linux, так і в Windows, але він більш популярний у світі Linux / Unix.
Ніколи не слід використовувати нестандартний конфігурацію Apache. Вам завжди потрібно налаштувати Apache на свій сайт. Основний файл конфігурації Apache у CentOS розташований у /etc/httpd/conf/httpd.conf, а головний конфігураційний файл Apache в системах Ubuntu зазвичай розташований у /etc/apache2/apache2.conf. Додаткові файли конфігурації використовуються для таких речей, як Віртуальні хости .
Як і багато програмного забезпечення, Apache побудований таким чином, щоб бути гнучким та налаштованим відповідно до конкретних потреб веб-сайту. Існують різні модулі багатообробної обробки, які Apache можна налаштувати для прив'язки до мережевого порту та прийому та обробки запитів.
Більшу частину часу в установках Apache за замовчуванням, які поставляються із серверами CentOS та Ubuntu, використовується MPM " mod_prefork ". Якщо припустити, що ви використовуєте mod_prefork (якщо ви не впевнені, то це найбільш ймовірно, але тільки ви можете це визначити) Ось основи налаштування:
MaxClients& ServerLimitзмінним.Це, звичайно, не відповідь у кінці кінців. Налаштування сервера Apache вимагає часу і вимагає досвіду, щоб отримати правильну роботу.