Чому Nginx так швидкий?


31

Як веб-сайт на зразок рамблера так швидко обслуговує динамічний контент? Навіть швидше, ніж Yahoo (у якого є сервер у моїй країні - SE Asia; rambler ні).

Це суто здатність Nginx? Куди мені слід шукати, щоб дізнатися про такі можливості?

Тут я досить новачок, я вважаю, що сервер default.com, якщо його обслуговуватимуть від Nginx, буде набагато швидшим IIS 7 (якщо припустимо, що час доступу db буде однаковим в обох випадках). Це справедливе припущення?

Редагувати:

Повідомлення від Карла за допомогою Nginx перед IIS7


Зауважте, що serverfault.com вже використовує Nginx (згідно Wappalyzer ). : P
WillS

Відповіді:


26

Ви можете побачити цю презентацію для огляду внутрішніх файлів nginx. Основна відмінність - асинхронна обробка запитів замість використання потоків, як це робить Apache. Ви також можете ознайомитися з цією документацією .


2
Гарна відповідь щодо архітектури nginx та проблеми C10K. Однак я розумію, що питання щодо ОП стосується сприйнятої швидкості завантаження сторінки, що мало стосується nginx.
Jesper M

Що насправді означає "асинхронний"? Я завжди думав, що це означає виконане в окремій нитці.
Іван

Асинхронне середнє Nginx завжди виступає як проксі, навіть з Php: Nginx отримує HTTP-запит, відправляє на сервер Php, але НЕ заблокує / не чекає відправки HTTP-відповіді. Ось чому ви бачите різницю (швидкість, процесор / оперативна пам’ять) для веб-сайту з високим трафіком. Але для декількох запитів (які стосуються 95% інтернету ....) немає підвищення продуктивності, але Nginx крутий ;-)
Thomas Decaux

21

Як веб-сайт на зразок рамблера так швидко обслуговує динамічний контент? ... Це суто здатність Nginx? Куди мені слід шукати, щоб дізнатися про такі можливості?

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

Менш важливою частиною є швидкість на стороні сервера , тобто час, необхідний для створення HTML. Більш важливою частиною є продуктивність 'frontend' , під якою я маю на увазі HTML, CSS, Javascript та зображення, їх кількість, розмір та правильну доставку (стиснення HTTP, кешування).

Звичайно, швидкість на стороні сервера все ще важлива, я не кажу, що її слід ігнорувати або що це не має значення. Але зазвичай це найменша частина, яка сприймається швидкістю кінцевого користувача - робота на сервері часто виконується менш ніж за 500 мілісекунд, але сторінка не готова до того, як пройде 3000 - 5000 мілісекунд. Основна частина цього часу припадає на завантаження ресурсів інтерфейсу (CSS, Javascript, Images).

Стів Суудерс займався оригінальною роботою, перебуваючи в Yahoo, зараз він працює в Google. Його перша книга "Веб-сайти з високою ефективністю" є найкращою відправною точкою для того, щоб дізнатися більше про створення швидких веб-сайтів. Той самий матеріал, який є в його книзі, можна знайти в цій відео-розмові , і ці правила дизайну . Однак я вважаю, що книгу швидко читати та набагато простіше зрозуміти.

Ви можете запускати сайти за допомогою тестера WebPageTest.org - це дасть вам гарне відчуття передньої частини цих сайтів і чому вони швидші чи повільніші.

Я вважаю, що сервер default.com, якщо його обслуговуватимуть від Nginx, буде набагато швидшим IIS 7 (припускаючи, що час доступу db буде однаковим в обох випадках). Це справедливе припущення?

Ні, це непорозуміння. :-)


18

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

Наприклад, ви можете написати додаток, використовуючи одну з багатьох фреймворків python, і nginx може бути переднім для багатьох екземплярів цього (можливо, поширюється на декількох машинах). У цьому випадку сервери nginx мають дві цілі: він обробляє запити для статичного вмісту, як-от зображення та таблиці стилів, безпосередньо (і завдяки своєму дизайну це робить дуже швидко), і він передає динамічні запити додатку, розподіляючи навантаження між усіма відомими йому екземплярами. . Це дуже популярна конфігурація і в спільноті Ruby on Rails.

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

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


3

nginx можливо, але більш масштабована архітектура з розумним балансуванням навантаження перед серверами статичного контенту / генераторами динамічного контенту. якщо ви дійсно хочете отримати великий досвід кінцевого користувача, вам, ймовірно, слід перемістити вміст ближче до «очних яблук» - скористайтеся деякими CDN.

якщо вас цікавить тема - ознайомтесь із цим і тим і .. ну - google; -]


2

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



0

Мені важко бачити сервер за замовчуванням набагато швидше (так що, можливо, виникнуть проблеми із завантаженням через трафік?), Оскільки це вже моментальне завантаження сторінки тут, в ЄС, на моєму маршруті. Це набагато швидше і чуйніше, ніж більшість місцевих сайтів новин тощо.

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

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

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