Будет ли Nginx в качестве обратного прокси для справки Apache только для динамического контента

Я планирую переместить весь мой статический контент в CDN, поэтому на моем сервере у меня остался только динамический контент. Теперь у меня Nginx настроен как обратный прокси-сервер для Apache. Статический запрос, который пришел туда, где прямо доставляется Nginx без необходимости перехода на Apache.

В этом случае Nginx обрабатывал большую часть запроса, и я ясно вижу необходимость Nginx.

Теперь, когда я переместил весь статический контент в другой домен, все еще нужно иметь nginx перед Apache. Потому что теперь все запросы по умолчанию являются динамическими запросами, и все идут в Apache.

Существуют ли другие преимущества использования Nginx и Apache для работы только с динамическим контентом.

Моим динамическим контентом является PHP / MySQL

Редактировать:

Чтобы быть ясным: теперь у меня Nginx как обратный прокси. Он обеспечивает статический и динамический контент. Но я перемещаю свои статические файлы в CDN. У меня тогда все еще нужен Nginx в моем домене.

Нет, вам больше не нужен nginx.

Да, вам абсолютно нужно nginx перед Apache. Apache использует 1 поток или процесс для каждого соединения. Каждый из этих потоков занимает память. Если у вас несколько сотен человек, посещающих ваш сайт, и у вас включен keepalive, каждый из этих браузеров будет поддерживать процесс apache или поток, занятый занимающей память на вашем сервере.

Вы можете обойти это, отключив keepalive на сервере apache, но это замедляет производительность вашего веб-сайта, поскольку браузеры не могут повторно использовать соединения.

Поэтому вместо nginx вы используете обратный прокси-сервер с включенным keepalive. Он может поддерживать тысячи соединений с небольшим объемом памяти (около 8 мегабайт). Поскольку nginx является локальным для вашего сервера apache, каждый запрос занимает только дочерний элемент или поток apache в течение нескольких микросекунд. Это означает, что вы можете обслуживать тысячи людей, имеющих лишь крошечную часть процессов apache.

Кроме того, конфигурация nginx намного более гибкая, чем apache, и благодаря наличию на передней панели она дает вам большую гибкость.

Что я сделал для одного веб-сайта:

  • настроить nginx как обратный прокси-сервер перед Apache
  • настройте его так:
    • Запросы на страницы PHP (то есть динамический контент) отправляются в Apache
    • Запросы на статические файлы (CSS, JS, …) напрямую обслуживаются nginx.

Это без необходимости настройки двух доменов: все находится в одном домене.

В принципе, я сделал:

  • обслуживать изображения из nginx, без сжатия gzip, с кешированием
  • служить js / css (т.е. текстовые файлы) из nginx, с сжатием gzip, с кешированием
  • обслуживать некоторые другие расширения (pdf, exeutables, …) формы nginx без сжатия, без кеширования
  • передать другие запросы Apache

Вот как выглядит файл конфигурации nginx:

server { listen 80; server_name MY_DOMAIN_NAME; access_log /var/log/nginx/MY_DOMAIN_NAME.access.log; gzip on; gzip_comp_level 2; gzip_proxied any; gzip_types text/plain text/html text/css text/xml application/xml application/xml+rss application/xml+atom text/javascript application/x-javascript application/javascript; location ~* ^.+\.(jpg|jpeg|gif|png|ico)$ { root /home/www/MY_DOMAIN_NAME; #access_log off; gzip off; expires 1d; } location ~* ^.+\.(css|js)$ { root /home/www/MY_DOMAIN_NAME; #access_log off; expires 1d; } location ~* ^.+\.(pdf|gz|bz2|exe|rar|zip|7z)$ { root /home/www/MY_DOMAIN_NAME; gzip off; } location / { proxy_pass http://MY_DOMAIN_NAME:8080; proxy_redirect off; proxy_set_header Host \$host; proxy_set_header X-Real-IP \$remote_addr; proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for; proxy_max_temp_file_size 0; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } } 

Итак, зачем это делать?

Ну, nginx должен:

  • Требуется меньше памяти
  • Быстрее
  • Уметь обрабатывать больше соединений

Поэтому, я полагаю, это могло бы помочь на веб-сайте с небольшим количеством трафика, чтобы снизить нагрузку, наложенную на Apache.

Вы также можете использовать nginx для выгрузки обработки SSL из экземпляров apache.

Например, у нас есть один стек, настроенный с пулом nginx-> haproxy-> серверов Apache. nginx и haproxy живут вместе в кластере пульса и подают запросы в пул апачей на бэкэнде. Мы устанавливаем все сертификаты SSL на интерфейсе nginx.

nginx впереди – лучшее решение, если вы используете Apache 1.3:

nginx может легко обслуживать тысячи коннектов, но Apache не может