Визначення реалістичної міри запитів на секунду для веб-сервера

15

Я встановлюю стек nginx і оптимізую конфігурацію перед тим, як перейти в прямому ефірі. Запускаючи ab на стрес-тесті на машині, я був розчарований, побачивши, що на 150 запитів в секунду додається значна кількість запитів, щоб повернутись більше 1 секунди. Як не дивно, сама машина навіть не важко дихала.

Нарешті я подумав пінг-коробку і побачив пінг-пара приблизно 100-125 мс. (Машина, на мій подив, є по всій країні). Отже, здається, що затримка в мережі переважає у моєму тестуванні. Запускаю ті ж тести з машини в тій самій мережі, що і сервер (пінг-раз <1 мс), і я бачу> 5000 запитів в секунду, що більше відповідає тому, що я очікував від машини.

Але це змусило мене задуматися: як я можу визначити та повідомити про "реалістичну" міру запитів за секунду для веб-сервера? Ви завжди бачите претензії щодо продуктивності, але чи не слід враховувати затримку в мережі? Звичайно, я можу обслуговувати 5000 запитів в секунду на машині поруч із сервером, але не на машині по всій країні. Якщо у мене багато повільних зв’язків, вони з часом вплинуть на продуктивність мого сервера, правда? Або я думаю про це все неправильно?

Пробачте, якщо це мережева інженерія 101 штука. Я розробник в галузі торгівлі.

Оновлення: Відредаговано для наочності.

— Дон
джерело

abмає паралельний варіант. На що ти це встановив? Крім того, якщо ви тестуєте з внутрішнього ADSL-з'єднання, швидше за все, в тесті буде домінувати ваша пропускна здатність і взагалі нічого не буде тестувати на сервері.

— Ladadadada

Я знайомий з варіантом паралельної конкуренції Ab і спробував широкий діапазон значень, щоб виявити межі поля. Як я писав вище, я розумію, що в моїх початкових тестах переважала мережа і не відображала можливості сервера. Але моє запитання все ще стоїть: Де більшість людей запускають свої тести, щоб отримати реалістичні показники? Тести проводяться з вікна в тій самій мережі, що і сервер (фактично випадаючи з рівняння будь-які мережеві затримки) повертають великі цифри, але вони не здаються "справедливими" числами, оскільки справжні користувачі будуть надходити за межі мережі.

— Дон

Тести, які проводяться з однієї мережі, насправді можуть бути більш «справедливими», оскільки вони по суті ігнорують мережу. Ваші користувачі, ймовірно, усі в різних мережах - тому сукупна пропускна здатність усіх цих мереж повинна легко перевищувати доступну пропускну здатність вашого сервера. Враховуючи всіх користувачів разом, вузьке вузол - це можливості сервера - тоді як, враховуючи окремого користувача, вузьким місцем може бути пропускна здатність одного користувача. (Ідеальний тест, можливо, буде проведений з декількох віддалених місць, щоб найкраще імітувати реальні обставини, хоча, у більшості випадків цього не потрібно).

— cyberx86

"Враховуючи всіх користувачів разом, тому вузьким місцем є можливості сервера" - це має сенс і здається правильним способом думати про це. Я припускаю, що сервер може сидіти за шаленим мережевим обладнанням, обмежуючи його швидкість реакції на зовнішній світ, але це насправді не проблема сервера, і його потрібно вирішувати окремо. Щось подібне до Pingdom, можливо, можна використовувати для проведення ідеального тесту.

— Дон

3

Якщо ви дбаєте про продуктивність вашого сервера, коли до нього звертаються звідкись із світу, попросіть друга десь у світі (має бути хороша пропускна здатність), щоб він встановив sproxy + облогу на його linux box. Просто завантажте, налаштуйте, зробіть. Ці інструменти невеликі, вони складаються протягом декількох секунд.

Спочатку почніть sproxyз вікна Linux. За замовчуванням він буде працювати на порту 9001 на localhost (127.0.0.1). Якщо ви хочете отримати доступ до нього ззовні, просто передайте йому вихідну ip адресу як параметр.
Тепер підключіться до sproxy, встановивши браузер використовувати цей ip та порт як проксі для HTTP. Все, що ви робите з цього моменту, записується за допомогою проксі і може бути відтворене пізніше. Тепер займайтеся серфінгом на вашому сайті, робіть те, що робили б ваші клієнти, і намагайтеся робити «дорогі» речі, які використовують ваш сервер.
Коли закінчите, закінчіть проксі, натиснувши CTRL ^ C. Він записував ваші дії до $HOME/urls.txt. Перемістіть файл туди, де знаходиться облога. Щоб розпочати стрес-тестування, запустіть siege -f urls.txt -d NUM -c NUM. dозначає затримку між запитами, при виконанні тестів на ефективність використовуйте 1 (секунду).cозначає кількість модельованих одночасно користувачів. Вибирайте за бажанням, але почніть з низького. Облога покаже вам кількість транзакцій в секунду, швидкість помилок, скільки тривалих середніх запитів тощо. Це потужний і простий у використанні інструмент.
Якщо вам потрібна додаткова інформація про параметри (їх багато), перегляньте посібник з облоги та посібник з проростанням

Щоб отримати більш реальні результати, дозвольте багатьом людям перевірити ваш сервер з різних країн одночасно, і дозвольте їм надсилати статистику.

— SebiF
джерело

2

Реалістичні запити / сек заходи повинні бути взяті з журналів доступу. IMO, затримка запиту не має нічого спільного з завантаженням сервера, оскільки сервер обробляє всі запити з однаковою швидкістю незалежно від їх походження.

— ejaenv
джерело

1

Подумайте про використання таких сервісів, як Soasta Cloudtest . З його допомогою ви можете отримати досить детальні звіти про свої тести, а також можете запустити тести на ефективність від різних громадських постачальників хмари / віртуалізації. Ви можете налаштувати, наскільки важко і як довго ви хочете забити сервери. Вони також мають безкоштовну версію " Lite ", щоб ви могли бачити, що вона може зробити, перш ніж вносити гроші.

— Mxx
джерело