On Sat, 8 Jun 2013 22:33:38 +0200 [email protected] 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... -- 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 [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: http://lists.debian.org/[email protected]
