Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

varnish

11 réponses
Avatar
andre_debian
Bonjour,

L'application "varnish" vaut-elle le coup ? :
plus de rapidit=E9 de r=E9action du serveur Web,
plus de connexions simultan=E9es ...

Y at-il des pi=E8ges =E0 =E9viter lors de son installation
et de sa configuration ?

Merci d'avance.

Andr=E9

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/201202101836.00010.andre_debian@numericable.fr

10 réponses

1 2
Avatar
Bzzz
On Fri, 10 Feb 2012 18:35:59 +0100
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 serv ies
(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 c onso 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-gwan/

Et il-y-a la bête de course (mais qui impose un langage et des concepts
peu évident quand on a l'habitude des langages bateaux,
pour le dynamique): http://www.sics.se/~joe/apachevsyaws.html

--
No passing zone.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard Schoenacker
Le Fri, 10 Feb 2012 18:35:59 +0100,
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é



bonjour,


pourquoi ne pas sélectionner un serveur web comme proxy ?

documentation détaillée :

http://korben.info/configurer-nginx-reverse-proxy.html
http://www.debian-administration.org/article/Speeding_up_dynamic_websites_via_an_nginx_proxy

http://www.youtube.com/watch?v=5ynxxNrf_9M

bonne consultation

slt
bernard

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
andre_debian
Le Friday 10 February 2012 19:07:45 Bzzz, vous avez écrit :
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


-----------------

Merci pour ces réponses et liens.

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).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bzzz
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 svrs http (sans compter sa propension
à bouffer la RAM).

--
If you live in New York, even if you're Catholic, you're Jewish.
-- Lenny Bruce

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Gilles Mocellin
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.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
andre_debian
Le Friday 10 February 2012 22:05:29 Bzzz, vous avez écrit :
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 :



Pourtant, je lis sur le site d'Apache :
"Worker" :
By using threads to serve requests, it is able to serve a large number of
requests with less system resources than a process-based server
"Prefork" :
It is also the best MPM for isolating each request, so that a problem with a
single request will not affect any other.

au cas où ça t'aurait échappé, :


Beenh, ça m'a échappé ...

apache est *vraiment* très loin d'être le plus performant des s vrs 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).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Gilles Mocellin
Le 10/02/2012 22:26, Gilles Mocellin a écrit :
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.



J'oubliais :
Autre effet bénéfique de limiter le nombre de process apache : limiter
les accès à la base de donnée derrière (je parle toujours de Drupal :-/).
C'est vraiment le point faible, et il faut vraiment avoir une stratégie
de mise en cache à multiples niveaux. Varnish étant le dernier avant le
cache du navigateur (ou des proxies sur le chemin).

PS:
Celà dit, il faudra que j'essaye nginx un jour...
Mais je pense que du coup, il vaut mieux pousser le traitement
asynchrone jusqu'au bout et coder une onne partie de l'appli avec node.js.
OK, on sort du sujet.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yves Rutschle
On Fri, Feb 10, 2012 at 10:25:35PM +0100, wrote:
> 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 ?



Bzzz en a cité dans sa réponse d'origine: nginx en yaws.

Apache est le plus connu et utilisé (avec Windows II-S).



Et Windows est l'environement de bureau le plus utilisé; ça
prouve quoi?

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.

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bzzz
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é 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.



Perso, j'ai basculé vers nginx pour des raisons de hardware vieux
et d'utilisation de la machine en svr non-dédié.

--
At the end of your life there'll be a good rest, and no further
activities are scheduled.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
andre_debian
Le Saturday 11 February 2012 13:31:27 Bzzz, vous avez écrit :
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é.


------------

Merci, j'en apprends des choses ! :

"nginx" et "yaws" sont donc des serveurs Web et même plus ...

apache est loin d'être le meilleur pour une même conso RAM et C PU... :


J'avais toujours pensé qu'il était le meilleur.

Je connais plusieurs sites à 60.000 visites/jour,
qui tournent sous Apache (sans configuration spéciale),
certes, sous 2 serveurs Web en "load-balancing",
sans noter de ralentissement notable.
Mais je ne connais pas le rapport pages
"statiques" et "dynamiques" de ces sites
et le nombre d'accès MySQL.

André


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
1 2