Поради щодо максимізації запитів на Nginx / сек?

Я будую пакет аналітики, і вимоги проекту вказують, що мені потрібно підтримувати 1 мільярд звернень на день. Так, "мільярд". Іншими словами, не менше 12 000 ударів за секунду витримано, і бажано, щоб щось лопнуло. Я знаю, що мені знадобиться кілька серверів для цього, але я намагаюся отримати максимальну продуктивність з кожного вузла, перш ніж "кидати на нього більше обладнання".

Зараз я завершив і оптимізовану частину відстеження звернень. Я майже просто зберігаю запити прямо в Redis (для подальшої обробки з Hadoop). Додаток - Python / Django з рушницею для шлюзу.

Мій сервер Rackspace 2,0 Гб Ubuntu 10,04 (не виробнича машина) може обслуговувати близько 1200 статичних файлів в секунду (орієнтований за допомогою Apache AB проти одного статичного активу). Для порівняння, якщо я поміняю статичне посилання на файл зі своїм відстеженням, я все одно отримую близько 600 запитів в секунду - я думаю, це означає, що мій трекер добре оптимізований, тому що це лише на 2 рази повільніше, ніж обслуговувати той же статичний актив неодноразово.

Однак, коли я орієнтуюся на мільйони звернень, я помічаю кілька речей -

1. Ніякого використання диска - цього очікується, оскільки я вимкнув усі журнали Nginx, а мій спеціальний код не робить нічого, крім збереження деталей запиту в Redis.
2. Постійне використання пам’яті - Імовірно, завдяки управлінню пам’яттю Редіса моє використання пам’яті поступово підніметься вгору, а потім відкинеться назад, але це ніколи не було моїм вузьким місцем.
3. Навантаження системи коливається в межах 2-4, система все ще реагує навіть на моїх найважчих орієнтирах, і я все ще можу вручну переглядати http://mysite.com/tracking/pixel з невеликою видимою затримкою, поки мій (інший) сервер виконує 600 запитів на кожен другий.
4. Якщо я проведу короткий тест, скажімо, 50 000 звернень (займає близько 2 м), я отримую стійкі надійні 600 запитів в секунду. Якщо я запускаю більш тривалий тест (пробував до 3,5 м), то мій р / с знижується до приблизно 250.

Мої запитання -

а. Схоже, я ще максимізував цей сервер? Чи є статичні файли nginx зі швидкістю 1200 / с порівнянні з результатами інших?

б. Чи є загальні налаштування nginx для таких додатків з великим обсягом? У мене на робочих нитках встановлено 64, а в робочих потоках - 8, але налаштування цих значень не дуже допомагає та не шкодить мені.

c. Чи є параметри рівня linux, які можуть обмежувати мої вхідні з'єднання?

г. Що може спричинити зниження моєї продуктивності до 250r / s при тривалих тестах? Знову ж, пам’ять не збільшується під час цих тестів, а використання жорсткого диска дорівнює нулю.

Дякую заздалегідь, всі :)

EDIT Ось моя конфігурація nginx - http://pastie.org/1450749 - це в основному ваніль, з очевидним жиром обробленим.

Ти зловживаєш робочими нитками Nginx. Немає необхідності керувати багатьма працівниками. Ви повинні запустити стільки працівників, скільки у вас є процесори, і називати це щодня. Якщо ви використовуєте gunicorn на одному сервері, ви, мабуть, повинні обмежити nginx працівників до двох. В іншому випадку, ви просто збираєтеся обробляти процесори з усіма контекстними комутаціями, необхідними для управління всіма цими процесами.

Я використовував nginx для обслуговування 5K запиту на секунду для статичного вмісту. Ви можете збільшити кількість робочих з’єднань, які наразі встановлені на 1024.

Розрахунок max_client був би наступним.

Work_connections і Working_proceses з головного розділу дозволяє обчислити значення maxclients:

max_clients = робочий_процес * робочий_з'єднання

У зворотній ситуації проксі, max_clients стає

max_clients = робітник_процеси * робочі_з'єднання / 4

http://wiki.nginx.org/EventsModule#worker_connections

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

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

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

2. Припущення, що пропускна здатність є вузьким місцем, візьміть середній розмір об'єкта, який обслуговує nginx, і розділіть свою пропускну здатність з цим, і ви отримаєте максимально підтримуваний qps.

3. У другому припущенні процесор є вузьким місцем. У цьому випадку виміряйте час запиту та розділіть його на 1 і кратно числу ядер у вашій системі. Це дасть кількість запитів на секунду, з якими може працювати nginx.