Коли я повинен перейти на NGinx?


11

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

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

Я не користувач енергії Apache, я поганий адміністратор Linux і не дуже розвиваю веб-додатки (але я маю поняття). Я здебільшого присвячений написанню програмного забезпечення, тому частина веб-сервера для мене іноді дуже незрозуміла. Кожен раз, коли мені доводиться налаштовувати веб-сайт через apach, мені потрібно багато часу переглядати документ, щоб переконатися, що я не зламаю все.

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

З інформації, яку я зібрав, NGinx був би найкращим вибором, коли ви хочете збалансувати навантаження, тож якщо у вас додаток поширюється на декілька машин, правда? Оскільки я думаю, що моя заявка на масштабування (та продуктивність), схоже, це те, що мені потрібно, але, можливо, мені потрібно знати більше речей про те, коли цікаво перейти з Apache до NGinx. Чи варто перейти на NGinx і для всіх моїх поточних додатків? Скільки це коштує? (Я маю на увазі, чи дорого вчасно переходити з одного на інший?) Чи можу я використовувати Apache та NGinx на одній машині без проблем?

Побічна примітка : Будь ласка, не закликайте мене використовувати інтерпретовані мови замість C ++, це не пов'язано з питанням. Перегляньте сторінку обґрунтування CPPCSM, щоб побачити, який саме додаток може отримати користь. Я прекрасно розумію недоліки (порівняно з додатками в Ruby та Python, які я вже використовую для менш енергозберігаючих веб-сайтів), і я в цьому добре.

Відповіді:


10

Кілька пунктів:

Основна відмінність Apache від Nginx або Lighttpd (що мені особисто дуже подобається) - це архітектура:

  1. Apache обробляє одне з'єднання за процес або за потік (залежно від mod-XYZ)
  2. Nginx і Lighttpd - це однопоточна обробка декількох з'єднань в одному циклі подій.

Як результат:

  1. Шкала Nginx та Lighttpd набагато краща за великої кількості одночасних з'єднань, скажімо, при 1000 з'єднаннях Apache майже загине, оскільки знадобиться 1000 процесів в mod-prefork або 1000 потоків у мод-робітнику.

    Якщо ви плануєте використовувати технології Comet, де кожне з'єднання вимагає тривалого опитування HTTP-з'єднання, то Apache буде неприйнятним, оскільки він не масштабує добре.

  2. Nginx і Lighttpd споживають менше пам'яті, оскільки для кожного з'єднання потрібно + - два сокети (HTTP і FastCGI), проміжний буфер пам'яті і деякий стан, тоді як Apache знадобиться ціла нитка, включаючи стек та інші речі.

З мого особистого досвіду в бенчмарках, я зробив Lighttpd (і я вважаю, що також Nginx) трохи швидше, коли у програмі FastCGI немає, ніж Apache, але це для низької кількості з'єднань.

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

У традиційній архітектурі є

                               |
                              HTTP
                               |
         Balancer (Nginx/Lighttpd/Cherooke/something-else)
            /      |           |            |      \
         HTTP    HTTP         HTTP        HTTP     HTTP
         /         |           |            |         \
 Apache+PHP   Apache+PHP   Apache+PHP   Apache+PHP   Apache+PHP   
  Server 2    Server 3     Server 4      Server 5     Server 6

Оскільки Apache обробляє пули процесів, кожен з них працює з mod-PHP (або іншими режимами)

Якщо ви використовуєте CppCMS, який самостійно обробляє пули, ви можете зробити щось інше:

                               |
                              HTTP
                               |
         Balancer (Nginx/Lighttpd/Cherooke/something-else)    
                           Server 1
            /      |           |            |      \
         FCGI    FCGI         FCGI        FCGI     FCGI
         /         |           |            |         \
    CppCMS App  CppCMS App  CppCMS App    CppCMS App  CppCMS App
     Server 2    Server 3     Server 4      Server 5     Server 6

Тому в основному вам не потрібен інший рівень непрямості, оскільки CppCMS обробляє процес, нитку та пул з'єднання для вас. У той час як PHP / Ruby / Perl потрібен деякий модуль Apache-XYZ або обробка власного роз'єму FastCGI.


+1 Приємне повне пояснення автора CppCMS;) Добре, зараз я бачу краще загальну проблему. Отже, якщо у вас є лише один сервер (для початку) це HTTP-> Balancer-> FCGI-> CPPCMS, якщо я правильно розумію? Що ви думаєте про поради з коментаря Jesper Mortensen, кажучи, що FastCGI не швидкий?
Клайм

@Klaim: Подивіться на чудові малюнки вище - у цій архітектурі FastCGI використовується як з'єднання між декількома серверами, кожен з яких працює з багатопотоковим екземпляром CppCMS. Відносна швидкість FastCGI має значення набагато менше; Вашими альтернативами будуть протокол HTTP, AJP та інші мережеві протоколи, які також не є швидкими. Цю відповідь, ймовірно, слід позначити як прийняту, а ваше питання відредаговано, оскільки це насправді не те, коли nginx того вартий.
Jesper M

@Jesper Mortensen> Я згоден, але яку модифікацію у питанні ви пропонуєте саме?
Клайм

6

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

З цього приводу, майже напевно є області, коли Apache буде стабільно перевершувати Nginx, тоді як є й інші, де Nginx так само стабільно перевершує Apache.

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

Однак, якщо ви хочете перейти на Nginx (що я заохочую!), Тоді перейдіть до цього. Ви побачите якусь користь? 9 разів з 10: Ні, ви не будете. Але ви згадали, що вам більше подобається мова конфігураційного файлу Nginx, тому якщо вам буде зручніше налаштувати Nginx, ніж Apache, ну, це для вас вигода! (Особисто мені здається, що конфігурації Apache легше читати загалом, але це могло бути тому, що я багато, багато років читав їх, і лише кілька коротких місяців було витрачено на Nginx!)

Зі сторони: Ви згадали про своє бажання створити веб-додаток на C ++. Заради вашого розуму я настійно закликаю вас замість цього використовувати мову вищого рівня, як PHP, Python або навіть Java. Потім профіліруйте свій код і розглянути можливість створення модулів на основі C ++ для вирішення конкретних вузьких місць (і Python, і PHP дозволяють це досить легко; не знаю про Java). Якщо ви турбуєтесь про загальну ефективність роботи, врахуйте це: EVE Online, єдиний найбільший незакритий MMORPG у світі, побудований на варіанті Python (Stackless Python), в якому лише ключові компоненти (наприклад, графічні бібліотеки) написані на C ++. Якщо Python може впоратися з цим, напевно він може обробляти ваш веб-додаток?


+1 Дякую Про C ++, дивіться мій коментар до відповіді Jesper Mortensen. Крім того, навіть якщо Python використовується на сервері Eve Online (я про це знаю багато) AFAIK, він управляє лише ігровим кодом (який великий), а деякі інші частини фактично знаходяться в C ++. Графічний код знаходиться на стороні клієнта, тому C ++ є обов'язковим для таких типів графічної продуктивності. Як я вже говорив, дивіться сторінку обгрунтування CPPCMS про те, чому я його обрав. Якщо я буду дотримуватися вашої поради, мені доведеться написати заяву двічі, хоча я вже знаю, що це дуже сильно. Крім того, я розумію недоліки і з цим я прекрасно.
Клайм

3

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

NGinx, здається, є більш ефективним, ніж Apache

nginx використовує єдиний процес (або дуже малу кількість робочих процесів) для обробки всіх підключень клієнтів, використовуючи парні введення / виведення. У Apache є декілька "Мультиобробних модулів" , але всі вони більше схиляються до багатьох процесів / багатьох потоків. Як результат, Apache зазвичай споживає більше оперативної пам’яті та процесора, ніж nginx, для основної обробки HTTP-з'єднання. Ознайомитися з різними підходами до обробки з'єднань можна на сторінці C10K Kegel .

веб-додаток з високою продуктивністю (використання C ++ із CPPCMS)

Я настійно пропоную розглянути можливість виконання базового веб-сайту на мові вищого рівня (Python, а може, і Ruby, Scala), і скористатись чергою messsage для надсилання робочих квитків на робочі машини, які асинхронно виконують завдання "з високими показниками продуктивності".

NGinx був би найкращим вибором, коли ви хочете збалансувати навантаження,

nginx - хороший балансир навантаження; але в цьому просторі є багато варіантів .

Чи можу я використовувати без проблем Apache та NGinx на одній машині?

Так. Просто запустіть їх за різними номерами IP-портів та / або IP-адресами.


"Я настійно пропоную розглянути можливість створення базового веб-сайту на мові вищого рівня"> Я не сказав, що це основний веб-сервер - це навіть не банально. Якщо ви бачите обґрунтування використання CPPCMS, автор декілька пунктів, коли це може бути корисним, і я в цих випадках. Я розглядав інші альтернативи, але вважав їх дорожчими, ніж спілкування з C ++, принаймні у тому вигляді, про який я пишу. Тож це не частина питання. Але я розумію ваші поради та дає те саме людям, які запитують мене, чи варто використовувати C ++ для веб-додатків. Я також планую використовувати Python для іншого більш простого додатка.
Клаїм

У будь-якому випадку +1 для деталей.
Клаїм

@Klaim: Якщо ви хочете реалізувати покращення продуктивності "на порядок" за рахунок чітко налаштованої реалізації C # / Java, то подивіться, чи можна запускати CppCMS та код програми під час роботи з вашим веб-сервером - тобто як плагін для nginx / Apache. Сторінки CppCMS, схоже, показують FastCGI як зв'язок між веб-сервером та CppCMS; а насправді FastCGI не ... швидкий.
Jesper M

> Цікава ідея. Більшість порад навколо полягає в тому, що ви повинні використовувати fastcgi, оскільки це швидше, ніж альтернативи. Я перевірю, чи можу я це зробити, можливо, побачу з автором CPPCMS, чому він вважає, що це найшвидше.
Клаїм
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.