Re: Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian
On Saturday 08 June 2013 23:18:57 Bzzz wrote:
> 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 :
Merci pour ce long et intéressant commentaire.
http://gwan.com/ :
G-WAN v1.0.4 – Discontinued.
› Windows
"Linux was found to be much faster. After years of development this gap is surely
larger now because Unix leaves more room for developers to innovate."
La version téléchargeable ne semble être que pour GNU/Linux 32 et 64 bits ...
G-Wan est-il proprio et payant ?
Je serai intéressé de le tester mais si je tombe sur ce commentaire,
je préfère le savoir avant : "you must pay before starting B-Wan ..."
> > "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) :
Combien d'entreprises utilisent "varnish" pour améliorer les performances
de leur serveur Web (=> haute disponibilité).
Ce n'est pas du tout le meilleir outil.
> > 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 ? :
Ici aussi, bien des entreprises, dont de gros hébergeurs ou data centers,
font confiance à ces modules d'Apache "prefork" ou "worker" pour améliorer
les connexions simultanées de leurs serveurs Web.
Elles ne suivent pas trop les évolutions.
> 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… :
Tu n'es pas le premier qui dit cela :
Apache, MySQL, PHP ... ne sont pas ou plus au top.
Et SkySQL ? : est-il du niveau de PostgreSQL ?
andré
Reply to: