У меня есть сервер с несколькими запущенными доменами и приложениями через Apache. На данный момент все хорошо, но у меня есть планы разработать какое-нибудь очень требовательное к производительности веб-приложение (используя C ++ с CPPCMS), начиная с моего сервера для тестирования, возможно, получить отдельный сервер только для этого приложения, когда оно будет готово.
В любом случае, я много слышал о NGinx, который кажется более производительным, чем Apache, поэтому я спрашивал себя, стоит ли работать с ним для этого нового проекта. Мне это непонятно, потому что я не знаю, какие именно проблемы с производительностью NGinx исправляет.
Я не опытный пользователь Apache, я плохой администратор Linux и не занимаюсь разработкой веб-приложений (но у меня есть представления). Я в основном занимаюсь написанием программного обеспечения, поэтому часть веб-сервера иногда для меня очень непонятна. Каждый раз, когда мне приходится настраивать веб-сайт через apach, мне нужно много времени просматривать документацию, чтобы убедиться, что я не все сломаю.
При этом я думаю, что с этой стороны мне становится намного лучше, но мне все еще нужен совет. Я видел несколько файлов конфигурации nginx, и это кажется намного более понятным, чем файлы Apache, но, может быть, я ошибаюсь?
Судя по собранной мной информации, NGinx будет лучшим выбором, если вам нужна балансировка нагрузки, так что если ваше приложение распространяется на несколько машин, верно? Поскольку я думаю о своем приложении для масштабирования (и производительности), похоже, что это то, что мне нужно, но, возможно, мне нужно знать больше о том, когда интересно перейти с Apache на NGinx. Стоит ли переходить на NGinx для всех моих текущих приложений? Сколько это стоит? (Я имею в виду, дорого ли вовремя переключаться с одного на другой?) Могу ли я без проблем использовать Apache и NGinx на одной машине?
Примечание : Пожалуйста, не убеждайте меня использовать интерпретируемые языки вместо C ++, это не имеет отношения к вопросу. Увидеть Страница с обоснованием CPPCSM чтобы увидеть, какое приложение может получить от этого пользу. Я прекрасно понимаю недостатки (по сравнению с приложениями на Ruby и Python, которые я уже использую для менее энергоемких веб-приложений), и меня это устраивает.
Несколько моментов:
Основное различие между Apache и Nginx или Lighttpd (что мне лично очень нравится) - это архитектура:
В следствии:
Nginx и Lighttpd намного лучше масштабируются при большом количестве одновременных подключений, скажем, с 1000 подключениями Apache почти умрет, поскольку для этого потребуется 1000 процессов в mod-prefork или 1000 потоков в mod-worker.
Если вы планируете использовать технологии Comet, где каждое соединение требует длительного HTTP-соединения с опросом, то Apache будет неприемлемым, поскольку он плохо масштабируется.
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 mod-XYZ или имеет собственный коннектор FastCGI.
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 может справиться с этим, наверняка он справится с вашим веб-приложением?
Никто не может ответить на вопрос «когда я должен переключаться» - это будет зависеть от вашей нагрузки, производительности вашего собственного кода приложения и т. Д.
NGinx, который кажется более производительным, чем Apache
nginx использует один процесс (или очень небольшое количество рабочих процессов) для обработки всех клиентских подключений с использованием четного ввода-вывода. Apache имеет несколько «Модули мультиобработки» доступны, но все они больше склоняются к многим многим процессам / многим потокам. В результате Apache обычно потребляет больше ОЗУ и ЦП, чем nginx для базовой обработки HTTP-соединения. Вы можете получить обзор различных подходов к обработке соединения на Страница Кегеля C10K.
очень требовательное к производительности веб-приложение (с использованием C ++ с CPPCMS)
я буду сильно Предлагаем рассмотреть возможность создания базового веб-приложения на языке более высокого уровня (Python или, может быть, Ruby, Scala) и использовать очередь сообщений для отправки рабочих билетов на рабочие машины, которые асинхронно обрабатывают «ресурсоемкие» задачи.
NGinx будет лучшим выбором, если вам нужна балансировка нагрузки,
nginx - хороший балансировщик нагрузки; но есть много вариантов в этом пространстве.
Могу ли я без проблем использовать Apache и NGinx на одном компьютере?
Да. Просто запустите их на разных номерах IP-портов и / или IP-адресах.