L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
wrote:
> L'application "varnish" vaut-elle le coup ? :
> plus de rapidité de réaction du serveur Web,
> plus de connexions simultanées ...
Tout dépend de ce que tu as comme:
* svr http
* type de site (le PHP n'est PAS une solution si du statique peut le
remplacer...)
* tuyaux
* traffic
* poids des pages
* puissance de svr http
* Qté de RAM
La première analyse portant sur la façon dont les pages sont se rvies
(statique? dynamique? un mélange des 2?)
puis sur les fréquences de Mà J des pages cachable.
Ensuite, il-y-a le svr http: même si apache clame une majorité sur
le web, c'est (très) loin d'être le meilleur pour une même conso RAM
et CPU...
Un exemple de la différence qu'on peut mesurer entre svrs:
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwa n/
Et il-y-a la bête de course (mais qui impose un langage et des conce pts
peu évident quand on a l'habitude des langages bateaux,
pour le dynamique): http://www.sics.se/~joe/apachevsyaws.html
pourquoi ne pas sélectionner un serveur web comme proxy ?
documentation détaillée :
http://korben.info/configurer-nginx-reverse-proxy.html
/www.debian-administration.org/article/Speeding_up_dynamic_websites_via_an _nginx_proxy
www.youtube.com/watch?v=5ynxxNrf_9M
www.sics.se/~joe/apachevsyaws.html :
andre_debian@numericable.fr wrote:
> L'application "varnish" vaut-elle le coup ? :
> plus de rapidité de réaction du serveur Web,
> plus de connexions simultanées ...
Tout dépend de ce que tu as comme:
* svr http
* type de site (le PHP n'est PAS une solution si du statique peut le
remplacer...)
* tuyaux
* traffic
* poids des pages
* puissance de svr http
* Qté de RAM
La première analyse portant sur la façon dont les pages sont se rvies
(statique? dynamique? un mélange des 2?)
puis sur les fréquences de Mà J des pages cachable.
Ensuite, il-y-a le svr http: même si apache clame une majorité sur
le web, c'est (très) loin d'être le meilleur pour une même conso RAM
et CPU...
Un exemple de la différence qu'on peut mesurer entre svrs:
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwa n/
Et il-y-a la bête de course (mais qui impose un langage et des conce pts
peu évident quand on a l'habitude des langages bateaux,
pour le dynamique): http://www.sics.se/~joe/apachevsyaws.html
pourquoi ne pas sélectionner un serveur web comme proxy ?
documentation détaillée :
http://korben.info/configurer-nginx-reverse-proxy.html
/www.debian-administration.org/article/Speeding_up_dynamic_websites_via_an _nginx_proxy
www.youtube.com/watch?v=5ynxxNrf_9M
www.sics.se/~joe/apachevsyaws.html :
wrote:
> L'application "varnish" vaut-elle le coup ? :
> plus de rapidité de réaction du serveur Web,
> plus de connexions simultanées ...
Tout dépend de ce que tu as comme:
* svr http
* type de site (le PHP n'est PAS une solution si du statique peut le
remplacer...)
* tuyaux
* traffic
* poids des pages
* puissance de svr http
* Qté de RAM
La première analyse portant sur la façon dont les pages sont se rvies
(statique? dynamique? un mélange des 2?)
puis sur les fréquences de Mà J des pages cachable.
Ensuite, il-y-a le svr http: même si apache clame une majorité sur
le web, c'est (très) loin d'être le meilleur pour une même conso RAM
et CPU...
Un exemple de la différence qu'on peut mesurer entre svrs:
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwa n/
Et il-y-a la bête de course (mais qui impose un langage et des conce pts
peu évident quand on a l'habitude des langages bateaux,
pour le dynamique): http://www.sics.se/~joe/apachevsyaws.html
pourquoi ne pas sélectionner un serveur web comme proxy ?
documentation détaillée :
http://korben.info/configurer-nginx-reverse-proxy.html
/www.debian-administration.org/article/Speeding_up_dynamic_websites_via_an _nginx_proxy
www.youtube.com/watch?v=5ynxxNrf_9M
www.sics.se/~joe/apachevsyaws.html :
s'agit-il de ces 2 modes de fonctionnement d'Apache ?
# prefork MPM
# worker MPM
L'un privilégie la vitesse,
l'autre la sécurité (plus lent).
s'agit-il de ces 2 modes de fonctionnement d'Apache ?
# prefork MPM
# worker MPM
L'un privilégie la vitesse,
l'autre la sécurité (plus lent).
s'agit-il de ces 2 modes de fonctionnement d'Apache ?
# prefork MPM
# worker MPM
L'un privilégie la vitesse,
l'autre la sécurité (plus lent).
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
On Fri, 10 Feb 2012 21:52:11 +0100
wrote:
> s'agit-il de ces 2 modes de fonctionnement d'Apache ?
> # prefork MPM
> # worker MPM
vi
> L'un privilégie la vitesse,
> l'autre la sécurité (plus lent).
Non, c'est juste une question d'architecture interne entièrement
différente :
au cas où ça t'aurait échappé, :
apache est *vraiment* très loin d'être le plus performant des s vrs http
On Fri, 10 Feb 2012 21:52:11 +0100
andre_debian@numericable.fr wrote:
> s'agit-il de ces 2 modes de fonctionnement d'Apache ?
> # prefork MPM
> # worker MPM
vi
> L'un privilégie la vitesse,
> l'autre la sécurité (plus lent).
Non, c'est juste une question d'architecture interne entièrement
différente :
au cas où ça t'aurait échappé, :
apache est *vraiment* très loin d'être le plus performant des s vrs http
On Fri, 10 Feb 2012 21:52:11 +0100
wrote:
> s'agit-il de ces 2 modes de fonctionnement d'Apache ?
> # prefork MPM
> # worker MPM
vi
> L'un privilégie la vitesse,
> l'autre la sécurité (plus lent).
Non, c'est juste une question d'architecture interne entièrement
différente :
au cas où ça t'aurait échappé, :
apache est *vraiment* très loin d'être le plus performant des s vrs http
Le 10/02/2012 18:35, a écrit :Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Réponse rapide :
- oui, varnish vaut le coup, et contrairement à un autre serveur Web en
frontal (comm nginx), il est spécialisé dans la mise en cache.
- Oui, il faut le configurer, on a pas par défaut une configuration très
efficace. Ca dépend de l'application derrière, mais il faut déjouer les
pièges qui empêche la mise en cache :
- les cookies, inutils sur les éléments statiques
- les headers HTTP concernant la durée de vie, pas toujours positionné
judicieusement pas l'appli
Sur des sites basés sur Drupal, à traffic assez important, on obtient la
répartition suivante en termes de nombre de requêtes par secondes :
- 1600 req/s sur les deux frontaux varnish (derrière un load balancer
"matériel" en round robin)
- 120 req/s sur 3 serveurs Web (apache+php+memcached)
On gagne environ un facteur 10 quoi.
Du coup, ça permet de limiter le nombre de process httpd et donc la
conso mémoire.
Le 10/02/2012 18:35, andre_debian@numericable.fr a écrit :
Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Réponse rapide :
- oui, varnish vaut le coup, et contrairement à un autre serveur Web en
frontal (comm nginx), il est spécialisé dans la mise en cache.
- Oui, il faut le configurer, on a pas par défaut une configuration très
efficace. Ca dépend de l'application derrière, mais il faut déjouer les
pièges qui empêche la mise en cache :
- les cookies, inutils sur les éléments statiques
- les headers HTTP concernant la durée de vie, pas toujours positionné
judicieusement pas l'appli
Sur des sites basés sur Drupal, à traffic assez important, on obtient la
répartition suivante en termes de nombre de requêtes par secondes :
- 1600 req/s sur les deux frontaux varnish (derrière un load balancer
"matériel" en round robin)
- 120 req/s sur 3 serveurs Web (apache+php+memcached)
On gagne environ un facteur 10 quoi.
Du coup, ça permet de limiter le nombre de process httpd et donc la
conso mémoire.
Le 10/02/2012 18:35, a écrit :Bonjour,
L'application "varnish" vaut-elle le coup ? :
plus de rapidité de réaction du serveur Web,
plus de connexions simultanées ...
Y at-il des pièges à éviter lors de son installation
et de sa configuration ?
Merci d'avance.
André
Réponse rapide :
- oui, varnish vaut le coup, et contrairement à un autre serveur Web en
frontal (comm nginx), il est spécialisé dans la mise en cache.
- Oui, il faut le configurer, on a pas par défaut une configuration très
efficace. Ca dépend de l'application derrière, mais il faut déjouer les
pièges qui empêche la mise en cache :
- les cookies, inutils sur les éléments statiques
- les headers HTTP concernant la durée de vie, pas toujours positionné
judicieusement pas l'appli
Sur des sites basés sur Drupal, à traffic assez important, on obtient la
répartition suivante en termes de nombre de requêtes par secondes :
- 1600 req/s sur les deux frontaux varnish (derrière un load balancer
"matériel" en round robin)
- 120 req/s sur 3 serveurs Web (apache+php+memcached)
On gagne environ un facteur 10 quoi.
Du coup, ça permet de limiter le nombre de process httpd et donc la
conso mémoire.
> apache est *vraiment* très loin d'être le plus performant des svrs http
(sans compter sa propension à bouffer la RAM).
... et quels seraient les autres serveurs Web plus performants que Apache ?
Apache est le plus connu et utilisé (avec Windows II-S).
> apache est *vraiment* très loin d'être le plus performant des svrs http
(sans compter sa propension à bouffer la RAM).
... et quels seraient les autres serveurs Web plus performants que Apache ?
Apache est le plus connu et utilisé (avec Windows II-S).
> apache est *vraiment* très loin d'être le plus performant des svrs http
(sans compter sa propension à bouffer la RAM).
... et quels seraient les autres serveurs Web plus performants que Apache ?
Apache est le plus connu et utilisé (avec Windows II-S).
Bzzz en a cité dans sa réponse d'origine: nginx en yaws.
Personellement, j'utilise Apache pour cette même raison, ce
qui implique que les vulnérabilités sont globalement trouvà ©s
et bouchées rapidement, que le serveur est bien intégré da ns
les distributions, et qu'il y a pléthore de documentation
sur le Web; mais je n'ai aucun besoin de performances dans
mon application.
Bzzz en a cité dans sa réponse d'origine: nginx en yaws.
Personellement, j'utilise Apache pour cette même raison, ce
qui implique que les vulnérabilités sont globalement trouvà ©s
et bouchées rapidement, que le serveur est bien intégré da ns
les distributions, et qu'il y a pléthore de documentation
sur le Web; mais je n'ai aucun besoin de performances dans
mon application.
Bzzz en a cité dans sa réponse d'origine: nginx en yaws.
Personellement, j'utilise Apache pour cette même raison, ce
qui implique que les vulnérabilités sont globalement trouvà ©s
et bouchées rapidement, que le serveur est bien intégré da ns
les distributions, et qu'il y a pléthore de documentation
sur le Web; mais je n'ai aucun besoin de performances dans
mon application.
On Sat, 11 Feb 2012 12:49:21 +0100
Yves Rutschle wrote:
> Bzzz en a cité dans sa réponse d'origine: nginx en yaws.
En fait, si tu scrutes bien le 1er lien tu vois qu'avant gwan (qui
est hors competition, puisque non-GPL, mais diablement efficace),
c'est Cherokee qui tient la dragée haute aux autres.
Ca m'avait surpris, parce qu'il-y-a 2-3 ans mes propres tests
indiquaient nginx devant Cherokee - maintenant comme il prévient,
c'est extra dur de tester des svrs http en situation artificielle.
> Personellement, j'utilise Apache pour cette même raison, ce
> qui implique que les vulnérabilités sont globalement trouvà ©s
> et bouchées rapidement, que le serveur est bien intégré dans
> les distributions, et qu'il y a pléthore de documentation
> sur le Web; mais je n'ai aucun besoin de performances dans
> mon application.
Perso, j'ai basculé vers nginx pour des raisons de hardware vieux
et d'utilisation de la machine en svr non-dédié.
apache est loin d'être le meilleur pour une même conso RAM et C PU... :
On Sat, 11 Feb 2012 12:49:21 +0100
Yves Rutschle <debian.anti-spam@rutschle.net> wrote:
> Bzzz en a cité dans sa réponse d'origine: nginx en yaws.
En fait, si tu scrutes bien le 1er lien tu vois qu'avant gwan (qui
est hors competition, puisque non-GPL, mais diablement efficace),
c'est Cherokee qui tient la dragée haute aux autres.
Ca m'avait surpris, parce qu'il-y-a 2-3 ans mes propres tests
indiquaient nginx devant Cherokee - maintenant comme il prévient,
c'est extra dur de tester des svrs http en situation artificielle.
> Personellement, j'utilise Apache pour cette même raison, ce
> qui implique que les vulnérabilités sont globalement trouvà ©s
> et bouchées rapidement, que le serveur est bien intégré dans
> les distributions, et qu'il y a pléthore de documentation
> sur le Web; mais je n'ai aucun besoin de performances dans
> mon application.
Perso, j'ai basculé vers nginx pour des raisons de hardware vieux
et d'utilisation de la machine en svr non-dédié.
apache est loin d'être le meilleur pour une même conso RAM et C PU... :
On Sat, 11 Feb 2012 12:49:21 +0100
Yves Rutschle wrote:
> Bzzz en a cité dans sa réponse d'origine: nginx en yaws.
En fait, si tu scrutes bien le 1er lien tu vois qu'avant gwan (qui
est hors competition, puisque non-GPL, mais diablement efficace),
c'est Cherokee qui tient la dragée haute aux autres.
Ca m'avait surpris, parce qu'il-y-a 2-3 ans mes propres tests
indiquaient nginx devant Cherokee - maintenant comme il prévient,
c'est extra dur de tester des svrs http en situation artificielle.
> Personellement, j'utilise Apache pour cette même raison, ce
> qui implique que les vulnérabilités sont globalement trouvà ©s
> et bouchées rapidement, que le serveur est bien intégré dans
> les distributions, et qu'il y a pléthore de documentation
> sur le Web; mais je n'ai aucun besoin de performances dans
> mon application.
Perso, j'ai basculé vers nginx pour des raisons de hardware vieux
et d'utilisation de la machine en svr non-dédié.
apache est loin d'être le meilleur pour une même conso RAM et C PU... :