Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian
On Sat, 8 Jun 2013 22:33:38 +0200
andre_debian@numericable.fr wrote:
> C'est bien "G-Wan" qui arrive largement en tête, mais proprio ...
Vi, MAIS quand on a un très gros site avec une énorme
fréquentation, la différence avec l'open-source est
tellement gigantesque (coeff. 4 quand même) qu'entre
rajouter des serveurs et utiliser G-Wan le choix
est vite vu.
> "Nginx" est quand même bien placé et Libre.
Il est non seulement très bien placé, mais en plus il
ne bouffe pas la RAM et ses plugins permettent toutes
sortes de fantaisies; par ailleurs, il intègre nativement
la notion de cache à plusieurs étages, d'où l'inutilité
d'un couplage avec varnish (pour gagner 5 à 10% de traffic,
ça ne vaut pas le coup de surcharger les confs).
> J'ose à peine poser la question vu le dernier (long) fil sur Nginx :
> est-il un serveur Web à part entière ou un complément à Apache ?
Il _peut_ être (et est) utilisé comme reverse-proxy, ce
qu'il fait très bien, mais c'est d'abord un serveur http
à part entière. Et il n'a pas connu plus de failles qu'apache
(je dirais même moins).
La différence de perfs vient de la façon de traiter les
requêtes; d° G-Wan, sauf qu'avec lui on ne sait pas comment
il fait exactement.
D'après le laïus sur la non dispo du source, il semble que
le C avec lequel il a été écrit ait été plus vu comme de
l'assembleur que du pur C; donc le type qui le développe
a du passer un monceau de temps à 'gader quel code C
produisait des routines en assembleur les plus efficaces
possibles + une façon de traiter les requêtes différente.
> Côté Apache, il y a plusieurs Modules multi-processus "MPM" :
> "Prefork" , "Worker" et "Event".
> Lequel choisir pour avoir un serveur à forte disponibilité ?
Aucun, l'architecture et les perfs d'apache sont maintenant
dépassées, ce qui explique sans doute la très forte croissance
de nginx qui est de plus en plus utilisé pour le remplacer
complètement.
Là où apache va ramer et surtout bouffer de la RAM, la
consommation de nginx va être ridicule en comparaison
pour des perfs supérieures.
Après, tout dépend de ce qu'on entend par "forte disponibilité",
est-on dans le HA (High Availibility) ou dans des centaines ou
des milliers de connexions simultanées?
Le svr utilise-t-il une DB, et laquelle? (prévoir un pool de
connexion si c'est le cas; faire faire une révision de la
structure de la DB et de ses éventuelles procédures stockées
par un pro qui connaît le moteur de DB par cœur, etc, etc).
Tout en sachant que mysql est un tas de merde qui ne tient
pas la route quand veut une DB ACID et surtout conforme aux
standards SQL (un exemple parmi tant d'autres: ne pas tronquer
en silence une string trop longue au lieu d'émettre une erreur
fatale).
Il existe un site allemand très bien fait (en anglais) sur les
erreurs de conception/fonctionnement de mysql (pas bookmarqué).
Postgresql, qui lorsqu'on lui indique des parms de procédures
sous la forme "$1,$2,$3,…" sécurise automatiquement les
variables contre l'injection SQL et est maintenant comparé
à oracle (et fourni ce qu'il faut pour transformer directement
du code oracle en code plPG/sql).
Et on peut continuer longtemps, notamment avec les sites tellement
mal écrits qu'ils laissent le controle de la DB à PHP, alors
qu'il ne devrait se contenter que d'appeler des procs stockées…
Le matériel, le nosql (qui ne devrait servir qu'à des cas bien
particuliers)…
Le langage PHP, quand LUA est des tas de fois plus rapide et Erlang
directement distribuable sur de nouveaux nœuds (scalability) en
quelques secondes…
--
Naptat : Si je devais ne plus exister dans les 5 secondes, tu me dirais quoi ?
Letz : 5
Letz : 4
Letz : 3
Letz : ...
Naptat : Connard...
Reply to: