Auteur Sujet: Pb URL Rewriting NGINX  (Lu 8295 fois)

0 Membres et 1 Invité sur ce sujet

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« le: 19 juillet 2016 à 13:26:20 »
Bonjour à tous,

Je rencontre un petit problème avec mon Blog Wordpress.
Je viens de faire sa migration depuis Google Cloud vers un VPS Firstheberg (-50% c'était alléchant).

La migration s'est bien passée, j'ai remis le même fichier de configuration qu'avant, mais la réécriture d'URL ne fonctionne plus.
J'ai du activer les articles sous la forme /blog/?p=291 alors qu'avant c'était /blog/observium-pour-un-monitoring-complet/ par exemple.

J'ai une erreur 404 quand j'essai d'accéder à ces URL, une fois qu'elles sont définies dans l'administration Wordpress.

Voici mon fichier de configuration:
server {
 listen 80;
 server_name damien-cueff.fr;
 return 301 https://$server_name$request_uri;
 }

server {
    # .well-known doit rest   accessible
    location ~ /\.well-known/acme-challenge {
        allow all;
    }
    # On interdit habituellement l'acc  s au dotfiles
    location ~ /\. { deny all; access_log off; log_not_found off; }
}

server {
 listen 443 ssl;
 ssl    on;
 ssl_certificate   /etc/letsencrypt/live/damien-cueff.fr/fullchain.pem;
 ssl_certificate_key    /etc/letsencrypt/live/damien-cueff.fr/privkey.pem;
 server_name damien-cueff.fr
;
 root /srv/nginx/hosts/damien-cueff.fr;
 index index.php index.html;

 location /blog {
try_files $uri $uri/ /index.php?q=$request_uri;
        }

 location ~ \.php$ {
 try_files $uri =404;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include fastcgi_params;
 }
 }

Quelqu'un a-t-il une idée? Merci d'avance!

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
Pb URL Rewriting NGINX
« Réponse #1 le: 19 juillet 2016 à 13:32:32 »
Sous Apache2, c'est sudo a2enmod rewrite pour activer le mode qui permet la réécriture d'URL.

Je ne maîtrise pas du tout Nginx

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« Réponse #2 le: 19 juillet 2016 à 13:35:05 »
Sous Apache2, c'est sudo a2enmod rewrite pour activer le mode qui permet la réécriture d'URL.

Je ne maîtrise pas du tout Nginx
Oui effectivement, j'ai testé sous Apache2 sa fonctionne très bien. Mais sa consommation en RAM ne me plait pas. Ici mon Nginx ne consomme qu'en moyenne 50 Mo... Alors qu'Apache2 va faire la même chose pour du 200 Mo.
Mais si je ne trouve pas d'où vient le problème, je vais devoir repasser sous Apache2...

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
Pb URL Rewriting NGINX
« Réponse #3 le: 19 juillet 2016 à 13:40:52 »
Au risque de passer pour un anti Nginx, Apache 2.4 a un mode qui est similaire à Nginx et qui à des performances et une consommation mémoire semblable à usage équivalent : le MPM event.

Le moteur (MPM) event est le serveur web haute performance d'Apache, concurrent de Nginx. Il implèmente un serveur hybride multi-processus et multi-threads. Contrairement aux autres serveurs web d'Apache qui imposent de réserver un couple processus enfant/thread pour attendre les données en provenance du client, Apache2 Event ne nécessite plus de thread de travail dédié pour les "Connexions asynchrones". Concrètement seule les connexions a qui le serveur envoi réellement des données utilisent couple processus enfant/thread.
Les connexions qui sont en pause (tampon d'écriture TCP plein ou connexion internet du client trop lente), celles qui Keep-alive (en attendant une autre demande sur la même connexion TCP) ou celles qui court de fermeture progressive, n'utilisent plus de thread de travail dédié.

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« Réponse #4 le: 19 juillet 2016 à 13:56:11 »
Au risque de passer pour un anti Nginx, Apache 2.4 a un mode qui est similaire à Nginx et qui à des performances et une consommation mémoire semblable à usage équivalent : le MPM event.

Le moteur (MPM) event est le serveur web haute performance d'Apache, concurrent de Nginx. Il implèmente un serveur hybride multi-processus et multi-threads. Contrairement aux autres serveurs web d'Apache qui imposent de réserver un couple processus enfant/thread pour attendre les données en provenance du client, Apache2 Event ne nécessite plus de thread de travail dédié pour les "Connexions asynchrones". Concrètement seule les connexions a qui le serveur envoi réellement des données utilisent couple processus enfant/thread.
Les connexions qui sont en pause (tampon d'écriture TCP plein ou connexion internet du client trop lente), celles qui Keep-alive (en attendant une autre demande sur la même connexion TCP) ou celles qui court de fermeture progressive, n'utilisent plus de thread de travail dédié.
Intéressant comme retour. Pour ma part, je ne suis ni pour l'un, ni pour l'autre... Je cherche juste l'idéal pour mon utilisation.
Y-a-t-il sur Apache2, la possibilité de faire du load balacing entre différents serveurs de manière native? Sans avoir à utiliser HAProxy ou autre?
C'est surtout ce point là qui m’intéresse. NGINX est capable d'équilibrer la charge sur différentes VMs tout en conservant les tokens actifs.

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
Pb URL Rewriting NGINX
« Réponse #5 le: 19 juillet 2016 à 14:03:57 »
Je ne sais pas répondre à la question, mais pourrais tu nous détailler l'architecture retenue pour avoir un contenu synchronisé entre tes deux serveurs web ?

En cas de forte charge, la première solution est généralement de mettre la base de donnée sur une autre machine voir de séparer en plus le contenu statique (images/ vidéos), via un sous-domaine sur une autre machine.

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« Réponse #6 le: 19 juillet 2016 à 16:44:03 »
Mon infra est la suivante (en très simplifié):

VM-NGINX-FRONT1: Port 80 et 443 ouverts, deux interfaces, une WAN (pour communiquer avec l'Internet) et une LAN sur un vSwitch LAN (172.16.255.254/16)
VM-NFS-STORE1: Partage NFS SSD sur le vSwitch LAN (172.16.254.1/16)
VM-NGINX-BACK1: Nginx avec une seule carte réseau sur le vSwitch LAN (172.16.255.1/16)
VM-NGINX-BACK2: Nginx avec une seule carte réseau sur le vSwitch LAN (172.16.255.2/16)
VM-NGINX-BACK3: Nginx avec une seule carte réseau sur le vSwitch LAN (172.16.255.3/16)
etc...

Toutes ces VMs (sauf la FRONT1) sont configurées pour que NGINX prennent ses fichiers sur le NFS, ainsi toutes mes VMs BACK ont les mêmes fichiers en direct.
La FRONT1 redirige les requêtes vers toutes mes BACK (j'en ai plus de 20) que j'allume au fur et a mesure de la charge (définition par plage horaire et sur des moyennes de visites).

Cela me permet d'avoir sur une même machine physique plus de 20 serveurs Web et donc de démultiplier le nombres de requêtes secondes possible sur la matériel. Ainsi, il est exploiter à 100%.
Un test avec l'outil SIEGE par exemple me donne de super résultat.

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
Pb URL Rewriting NGINX
« Réponse #7 le: 19 juillet 2016 à 19:08:49 »
Là ton architecture me parait cohérente pour un site web sans base de donnée.

Tu parles de wordpress, donc où sont exécutées les requêtes SQL et où est stockée la base de donnée ?

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« Réponse #8 le: 19 juillet 2016 à 19:16:44 »
Là ton architecture me parait cohérente pour un site web sans base de donnée.

Tu parles de wordpress, donc où sont exécutées les requêtes SQL et où est stockée la base de donnée ?
Mon Wordpress n'a pas besoin de tout ça, eheh.
J'utilise ce type d'infra pour mes clients qui sont en hébergement mutualisé.
Les bases de données sont elles aussi redondés, cette fois-ci par HAProxy. Je suis un peu moins bien équipé de ce côté, simplement deux serveurs physiques en SSD/RAM ECC en solution maître-maître.
Les requêtes sont redirigées sur mes deux serveurs (1 requête sur 2 par sur le serveur 1 etc...).
La majorité de mes clients n'ont pas de BDD (site vitrine essentiellement) mais j'ai aussi du Prestashop, du Wordpress et compagnie. Il suffit de spécifier dans les fichiers de configurations PHP l'adresse de l'HAProxy en tant que serveur SQL. Pour le moment, ça roule tout seul.
En même temps, je n'ai pas énormèment de trafic non plus.

vivien

  • Administrateur
  • *
  • Messages: 47 083
    • Twitter LaFibre.info
Pb URL Rewriting NGINX
« Réponse #9 le: 19 juillet 2016 à 19:24:10 »
Avec le MPM event, sur du contenu statique, je gère plus de 3000 requêtes par secondes, pour un débit de 5 Gb/s utilisé. C'est un unique SSD de 1To grand public qui est utilisé (pas de RAID) et un Xeon entrée de gamme 4 cœurs.

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« Réponse #10 le: 19 juillet 2016 à 19:47:07 »
Avec le MPM event, sur du contenu statique, je gère plus de 3000 requêtes par secondes, pour un débit de 5 Gb/s utilisé. C'est un unique SSD de 1To grand public qui est utilisé (pas de RAID) et un Xeon entrée de gamme 4 cœurs.
Avec mon infra, je peux assumer plus de 40 000 requêtes secondes avec l'ensemble de mes VMs. Après je n'ai clairement pas besoin de cette capacité.
Surtout qu'a 40 000 r/s ça commence à piquer, le temps de traitement devient de plus en plus long, allant jusqu'à 3 secondes...

Mais j'ai aussi du cache sur mes webs, ça permet de soulager le tout.
Mais avec une installation typique de nginx sur du 4 vCore (basé sur du Xeon E3) on tient largement les 3000+ r/s.
C'est pour ça que je n'aime pas trop Apache2, pour avoir tourner longtemps sur les deux, mon choix est fait.

DamienC

  • Abonné Sosh fibre
  • *
  • Messages: 2 217
  • FTTH ↓ 300Mbps ↑ 300 Mbps sur Brest (29)
Pb URL Rewriting NGINX
« Réponse #11 le: 19 juillet 2016 à 19:49:18 »
Mais si tu le souhaites Vivien, on peut faire des comparaisons sur machine équivalente, on lance un AB d'apache pour le test, en premier sur du Apache2, l'autre sur du NGINX, tu serais surpris...