Est-ce qu’un Nginx comme proxy inverse pour Apache aidera uniquement le contenu dynamic?

Non, vous n’avez plus besoin de nginx.

Oui, vous avez absolument besoin de nginx devant Apache. Apache utilise 1 thread ou processus par connexion. Chacun de ces threads occupe la mémoire. Si quelques centaines de personnes visitent votre site Web et que keepalive est activé, chacun de ces navigateurs gardera un processus apache ou occupera la mémoire occupante de votre serveur.

Vous pouvez contourner ce problème en désactivant keepalive sur votre serveur Apache, mais cela ralentit les performances de votre site Web car les navigateurs ne peuvent pas réutiliser les connexions.

Donc, à la place, vous utilisez nginx comme proxy inverse avec keepalive activé. Il peut maintenir des milliers de connexions avec une empreinte mémoire minime (environ 8 Mo). Comme nginx est local sur votre serveur Apache, chaque requête n’occupe qu’un fils ou un thread apache pendant quelques microsecondes. Cela signifie que vous pouvez servir des milliers de personnes avec seulement une poignée de processus Apache.

De plus, la configuration de nginx est beaucoup plus flexible que celle d’Apache et en l’ayant à l’avant, cela vous donne beaucoup de flexibilité.

Ce que j’ai fait pour un site Web est:

• mettre en place nginx comme proxy inverse devant Apache
• configurez-le pour:
  • Les demandes de pages PHP (c’est-à-dire de contenu dynamic) sont envoyées à Apache
  • Les demandes de fichiers statiques (CSS, JS, …) sont directement servies par nginx.

Ceci sans avoir à configurer deux domaines: tout est sur le même domaine.

En gros, ce que j’ai fait est:

• servir des images de nginx, sans compression gzip, avec mise en cache
• servir js / css (c.-à-d. fichiers texte) à partir de nginx, avec compression gzip, avec mise en cache
• servir d’autres extensions (pdf, exeutables, …) sous forme nginx, sans compression, sans mise en cache
• passer les autres demandes à Apache

Voici à quoi ressemble le fichier de configuration de mon 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; } } 

Maintenant, pourquoi faire une telle chose?

Eh bien, Nginx est censé:

• Besoin de moins de mémoire
• Être plus rapide
• Être capable de gérer plus de connexions

Donc, je suppose que cela pourrait aider sur un site Web avec un peu de trafic, pour réduire la charge qui est mise sur Apache.

Vous pouvez également utiliser nginx pour décharger le traitement SSL des instances apache.

Par exemple, nous avons une stack configurée avec nginx-> haproxy-> pool de serveurs Apache. nginx et haproxy vivent ensemble sur un cluster de pulsation et transmettent les requêtes dans un pool de boîtes Apache sur le serveur principal. Nous installons tous les certificates SSL sur le frontend nginx.

nginx devant est la meilleure solution si vous utilisez Apache 1.3:

nginx peut facilement servir des milliers de conections, mais Apache ne peut pas