Vive les informaticiens.

webm

Best Member
Définition d'un informaticien: C'est une personne qui ne parvient pas à résoudre un problème qu'on avait pas avant de le rencontrer.

Lu sur un forum.

Nginx permet de faire reverse proxy et supporte une interface FastCGI. L'idée est de le mettre devant un Apache qui fait du mod_perl (par exemple) auquel cas il fera du reverse proxy vers Apache pour tout ce qui est en .pl et servira directement le contenu statique ; mine de rien, en moyenne, ça diminue d'un facteur 10 le nombre d'instance d'Apache (entre les images, les CSS et les javascript).
De plus il permet d'interroger un serveur memcached avant l'upstream ce qui peut être une source considérable d'optimisation (sans parler de SSI qui avec ce mécanisme permet de faire des sous-requêtes HTTP et d'optimiser l'usage de memcached).
Donc dans ton cas, pas de problème, une redirection vers l'upstream qui gère les scripts perl/CGI, le reste vers Nginx, et tu devrais voir baisser de façon drastique l'utilisation des ressource systèmes.
 

Cybervince

Best Member
Ben je vois pas où c'est compliqué à comprendre.

Tu installes sur ton serveur un reverse-proxy qui :
- renvoie directement à l'utilisateur les contenus statiques comme les pages HTML, les images, fichiers archive
- redirige les requêtes (en tant que reverse-proxy) à destination d'un Apache qui ne sera chargé que de renvoyer les pages dynamiques (du Perl, du PHP, ...)
Ainsi, la partie Apache est soulagée (vu qu'en standard, un process est créé à chaque requête HTTP). Mais à mon sens, c'est surtout utile lorsqu'on souhaite séparer la partie statique et la partie dynamique sur plusieurs machines.
 

darry

New Member
pour toi cybervince c'est facile et mais moi c'est du chinois

Cybervince link=topic=93504.msg1067974#msg1067974 date=1230661239 a dit:
Ben je vois pas où c'est compliqué à comprendre.

Tu installes sur ton serveur un reverse-proxy qui :
- renvoie directement à l'utilisateur les contenus statiques comme les pages HTML, les images, fichiers archive
- redirige les requêtes (en tant que reverse-proxy) à destination d'un Apache qui ne sera chargé que de renvoyer les pages dynamiques (du Perl, du PHP, ...)
Ainsi, la partie Apache est soulagée (vu qu'en standard, un process est créé à chaque requête HTTP). Mais à mon sens, c'est surtout utile lorsqu'on souhaite séparer la partie statique et la partie dynamique sur plusieurs machines.

maintenant j'ai compris merci pour la reformulation
-c'est clair
-bien expliquer avec un language compréhensible :chessy:
 

Ca peut vous intéresser