Я неправильно припустив, що моє внутрішнє тестування АБ означає, що мій сервер може обробляти 1 к одночасність @ 3 к хітів за секунду.

Моя теорія на даний момент полягає в тому, що мережа є вузьким місцем. Сервер не може надсилати достатньо швидко даних.

Зовнішнє тестування від blitz.io при одночасності 1 к. Показує, що кількість моїх показів / скорочень скорочується на 180, тому що сторінки відповідають більше часу і довше, тому що сервер може повертати лише 180 за секунду.

Я подав порожній файл з nginx і порівняв його: він масштабує 1: 1 з одночасністю.

Тепер, щоб виключити IO / memcached вузькі місця (nginx зазвичай витягується з memcached), я обслуговую статичну версію кешованої сторінки з файлової системи.

Результати дуже схожі на мій оригінальний тест; Я обмежений приблизно в 180 об / хв.

Розділення HTML-сторінки навпіл дає мені подвоїти RPS, тому воно, безумовно, обмежене розміром сторінки.

Якщо я внутрішньо ApacheBench з локального сервера, я отримую стійкі результати в районі 4k RPS як на повній сторінці, так і на половинній сторінці, з високою швидкістю передачі. Швидкість передачі: 62586,14 [Кбайт / сек] отримано

Якщо я AB із зовнішнього сервера, я отримую близько 180RPS - те саме, що результати blitz.io.

Звідки я знаю, що це не навмисне придушення?

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

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

Я правий? Чи є інші способи інтерпретації цих даних? Чи є рішення / оптимізація встановити кілька серверів + балансування навантаження, яке може обслуговувати 180 хітів в секунду?

Я зовсім новачок в оптимізації сервера, тому я вдячний за будь-яке підтвердження інтерпретації цих даних.

Виїзний трафік

Ось додаткові відомості про вихідну пропускну здатність: мережевий графік показує максимальний вихід 16 Мбіт / с: 16 мегабіт в секунду. Це зовсім не схоже на багато.

Через пропозицію щодо дроселювання я переглянув це і виявив, що в ліноді є ковпачок на 50 Мбіт / с (мабуть, я навіть не близький до удару). У мене це було підвищено до 100 Мбіт / с.

Оскільки лінод обмежує мій трафік, і я навіть не потрапляю на нього, чи означає це, що мій сервер дійсно повинен бути здатний виводити до 100 Мбіт / с, але обмежений деяким іншим внутрішнім вузьким місцем? Я просто не розумію, як працюють такі масштабні мережі; чи можуть вони буквально надсилати дані так швидко, як вони можуть читати з жорсткого диска? Чи є мережа труб , що великий?

На закінчення

1: Виходячи з вищесказаного, я думаю, що я, безумовно, можу підвищити 180RPS, додавши балансир навантаження nginx поверх налаштування декількох серверів з декількома nginx рівно 180RPS на сервері позаду LB.

2: Якщо лінод має обмеження 50/100 Мбіт, яке я взагалі не вражаю, я повинен зробити щось, щоб досягти цієї межі при моєму встановленні одного сервера. Якщо я можу читати / передавати дані досить швидко локально, а лінод навіть турбує, щоб мати кришку 50 Мбіт / 100 Мбіт, має бути внутрішній вузький вузол, який не дозволяє мені вдаритись по тих кришках, які я не знаю, як виявити. Правильно?

Я усвідомлюю, що питання зараз величезне і розпливчасте, але я не впевнений, як його конденсувати. Будь-який внесок вдячний за будь-який зроблений нами висновок.

Проблема була в тому, що я припускав, що піки графіків linode.com були справжніми піками. Виявляється, графік використовує 5 хвилин середніх точок даних, таким чином, мій пік виявився 24 Мбіт, коли насправді я потрапив на 50 Мбіт.

Тепер, коли вони підняли його до 100 Мбіт, мої показники одразу піднялися до нового обмеження вихідного трафіку.

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

Тепер я досягаю піку 370 запитів в секунду, що становить менше 100 Мбіт / с, і в цей момент я починаю отримувати "відставання" запитів, і час відповідей починає збільшуватися.

Тепер я можу збільшити максимальну сумісність, скорочуючи сторінку; при включенні gzip я отримую 600 об / хв.

У мене все ще виникають проблеми, коли я раптом пік і відставання відкладених запитів (обмежених пропускною здатністю) починає накопичуватися, але це звучить як інше питання.

Це був чудовий урок оптимізації / читання цих даних / звуження можливих проблем. Дуже дякую за ваш внесок!

Трохи пізно, коли ви це зрозуміли ... але, можливо, вам варто час від часу почитати блог ServerFault.

Я думаю, зокрема, про цю посаду , де вони обговорюють, чому наявність періодичності одного другого опитування не скорочує її час від часу, пов'язану з дуже подібною проблемою до тієї, яку ви мали ..

Ми виявили, що ми часто відкидаємо пакети в інтерфейсах 1 Гбіт / с зі швидкістю лише 10-30 Мбіт / с, що шкодить нашій продуктивності. Це відбувається тому, що швидкість 10-30 Мбіт / с - це дійсно кількість бітів, переданих за 5 хвилин, перетворених на швидкість однієї секунди. Коли ми зблизилися з Wireshark і застосували графік IO в мілісекунд, ми побачили, що ми часто розриваємо швидкість 1 Мбіт на мілісекунду так званих інтерфейсів 1 Гбіт / с.

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

Хто знає, я можу навіть деякі з них пустити в таємниці. :)

Це може бути обмежено мережею, але це не обов'язково просто питання пропускної здатності. Затримка вашого віддаленого тестового блоку впливатиме на кількість підключень, які очікують на розгляд в будь-який момент часу (очікування 50мм підтвердження значно відрізняється, ніж на 5мс локально), а також на узгодження та стабілізацію розмірів вікон у міру просування зв’язку. Ви також, ймовірно, зазнаєте деякої кількості втрат пакету - або як функція перевантаженості, або як механізм обмеження пропускної здатності з боку вашого оператора (або тих, хто знаходиться вище за течією).

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

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