Bonjour,
Les scripts s'exécutent sur des machines installées dans un environnement
de développement. Une fois que ces machines ont correctement testées, elles
sont ensuite déplacées dans un environnement de production, avec le minimum
de modifications dans leur configuration.
Je m'interroge s'il est possible/préférable :
1. soit de modifier l'environnement de développement (proxy transparent ?)
de telle sorte que les machines cibles ne soient pas modifiées quand elles
passent dans l'environnement de production,
2. soit d'accepter de modifier la configuration d'une machine quand elle
passe en production avec le bénéfice de simplifier la configuration de
l'environnement de développement car les machines qu'il servira coopéreront
avec lui pour atteindre l'objectif fixé.
Mes questions sont:
A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt pour la
2) ?
B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
(Squid ?) et un pour apt (lequel ?) ?
Bonjour,
Les scripts s'exécutent sur des machines installées dans un environnement
de développement. Une fois que ces machines ont correctement testées, elles
sont ensuite déplacées dans un environnement de production, avec le minimum
de modifications dans leur configuration.
Je m'interroge s'il est possible/préférable :
1. soit de modifier l'environnement de développement (proxy transparent ?)
de telle sorte que les machines cibles ne soient pas modifiées quand elles
passent dans l'environnement de production,
2. soit d'accepter de modifier la configuration d'une machine quand elle
passe en production avec le bénéfice de simplifier la configuration de
l'environnement de développement car les machines qu'il servira coopéreront
avec lui pour atteindre l'objectif fixé.
Mes questions sont:
A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt pour la
2) ?
B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
(Squid ?) et un pour apt (lequel ?) ?
Bonjour,
Les scripts s'exécutent sur des machines installées dans un environnement
de développement. Une fois que ces machines ont correctement testées, elles
sont ensuite déplacées dans un environnement de production, avec le minimum
de modifications dans leur configuration.
Je m'interroge s'il est possible/préférable :
1. soit de modifier l'environnement de développement (proxy transparent ?)
de telle sorte que les machines cibles ne soient pas modifiées quand elles
passent dans l'environnement de production,
2. soit d'accepter de modifier la configuration d'une machine quand elle
passe en production avec le bénéfice de simplifier la configuration de
l'environnement de développement car les machines qu'il servira coopéreront
avec lui pour atteindre l'objectif fixé.
Mes questions sont:
A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt pour la
2) ?
B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
(Squid ?) et un pour apt (lequel ?) ?
Le vendredi 07 juin 2013 à 11:48, Olivier a écrit :
> Bonjour,
Bonjour,
> Les scripts s'exécutent sur des machines installées dans un environ nement
> de développement. Une fois que ces machines ont correctement testée s,
elles
> sont ensuite déplacées dans un environnement de production, avec le
minimum
> de modifications dans leur configuration.
>
> Je m'interroge s'il est possible/préférable :
> 1. soit de modifier l'environnement de développement (proxy transpare nt
?)
> de telle sorte que les machines cibles ne soient pas modifiées quand
elles
> passent dans l'environnement de production,
> 2. soit d'accepter de modifier la configuration d'une machine quand ell e
> passe en production avec le bénéfice de simplifier la configuration de
> l'environnement de développement car les machines qu'il servira
coopéreront
> avec lui pour atteindre l'objectif fixé.
>
> Mes questions sont:
> A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt p our
la
> 2) ?
Pourquoi cette préférence pour la 2 ? Pour éviter le passage par un proxy
sur
une machine de prod ? Si c'est ça, personnellement ça ne me dérange rait
pas,
d'autant plus qu'une fois en prod, la machine ne devrait plus (ou du moin s
beaucoup moins qu'avant) solliciter le proxy
> B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
> (Squid ?) et un pour apt (lequel ?) ?
Pour wget, en effet, un proxy généraliste devrait faire l'affaire. Po ur
APT, il
y en a plusieurs, je n'en ai jamais utilisé aucun :
approx - serveur mandataire et cache pour les fichiers d'archive Debi an
apt-cacher - proxy cache pour les paquets Debian et les fichiers sour ce
apt-cacher-ng - serveur mandataire de cache pour les dépôts logic iel
Seb
--
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/
Le vendredi 07 juin 2013 à 11:48, Olivier a écrit :
> Bonjour,
Bonjour,
> Les scripts s'exécutent sur des machines installées dans un environ nement
> de développement. Une fois que ces machines ont correctement testée s,
elles
> sont ensuite déplacées dans un environnement de production, avec le
minimum
> de modifications dans leur configuration.
>
> Je m'interroge s'il est possible/préférable :
> 1. soit de modifier l'environnement de développement (proxy transpare nt
?)
> de telle sorte que les machines cibles ne soient pas modifiées quand
elles
> passent dans l'environnement de production,
> 2. soit d'accepter de modifier la configuration d'une machine quand ell e
> passe en production avec le bénéfice de simplifier la configuration de
> l'environnement de développement car les machines qu'il servira
coopéreront
> avec lui pour atteindre l'objectif fixé.
>
> Mes questions sont:
> A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt p our
la
> 2) ?
Pourquoi cette préférence pour la 2 ? Pour éviter le passage par un proxy
sur
une machine de prod ? Si c'est ça, personnellement ça ne me dérange rait
pas,
d'autant plus qu'une fois en prod, la machine ne devrait plus (ou du moin s
beaucoup moins qu'avant) solliciter le proxy
> B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
> (Squid ?) et un pour apt (lequel ?) ?
Pour wget, en effet, un proxy généraliste devrait faire l'affaire. Po ur
APT, il
y en a plusieurs, je n'en ai jamais utilisé aucun :
approx - serveur mandataire et cache pour les fichiers d'archive Debi an
apt-cacher - proxy cache pour les paquets Debian et les fichiers sour ce
apt-cacher-ng - serveur mandataire de cache pour les dépôts logic iel
Seb
--
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/20130607102431.GJ13580@sebian.nob900.homeip.net
Le vendredi 07 juin 2013 à 11:48, Olivier a écrit :
> Bonjour,
Bonjour,
> Les scripts s'exécutent sur des machines installées dans un environ nement
> de développement. Une fois que ces machines ont correctement testée s,
elles
> sont ensuite déplacées dans un environnement de production, avec le
minimum
> de modifications dans leur configuration.
>
> Je m'interroge s'il est possible/préférable :
> 1. soit de modifier l'environnement de développement (proxy transpare nt
?)
> de telle sorte que les machines cibles ne soient pas modifiées quand
elles
> passent dans l'environnement de production,
> 2. soit d'accepter de modifier la configuration d'une machine quand ell e
> passe en production avec le bénéfice de simplifier la configuration de
> l'environnement de développement car les machines qu'il servira
coopéreront
> avec lui pour atteindre l'objectif fixé.
>
> Mes questions sont:
> A. Vaut-il mieux choisir l'option 1 ou l'option 2 (je penche plutôt p our
la
> 2) ?
Pourquoi cette préférence pour la 2 ? Pour éviter le passage par un proxy
sur
une machine de prod ? Si c'est ça, personnellement ça ne me dérange rait
pas,
d'autant plus qu'une fois en prod, la machine ne devrait plus (ou du moin s
beaucoup moins qu'avant) solliciter le proxy
> B. Quels outils utiliser (j'imagine 2 outils spécialisés : un pour wget
> (Squid ?) et un pour apt (lequel ?) ?
Pour wget, en effet, un proxy généraliste devrait faire l'affaire. Po ur
APT, il
y en a plusieurs, je n'en ai jamais utilisé aucun :
approx - serveur mandataire et cache pour les fichiers d'archive Debi an
apt-cacher - proxy cache pour les paquets Debian et les fichiers sour ce
apt-cacher-ng - serveur mandataire de cache pour les dépôts logic iel
Seb
--
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/
Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .
Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) . @+ Christophe.
Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .
Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) . @+ Christophe.
Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .
Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) . @+ Christophe.
On Friday 07 June 2013 21:13:57 Christophe wrote:Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .
Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) . @+ Christophe.
Bonjour,
"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web (hébergé)
avec d'autres services (MySQL, Postfix, Mailman etc ...)
en termes d'accélération, de gain ...
Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
reverse-proxy HTTP "accélérateur" libre (licence BSD) permettant de soulager les serveurs web.
Lien :
www.unixgarden.com/index.php/gnu-linux-magazine/varnish-un-proxy-qui-vous-veut-du-bien
Quelle est la différence entre "apt-cacher-ng" et "varnish" ?
Merci.
André
On Friday 07 June 2013 21:13:57 Christophe wrote:
Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .
Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) . @+ Christophe.
Bonjour,
"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web (hébergé)
avec d'autres services (MySQL, Postfix, Mailman etc ...)
en termes d'accélération, de gain ...
Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
reverse-proxy HTTP "accélérateur" libre (licence BSD) permettant de soulager les serveurs web.
Lien :
www.unixgarden.com/index.php/gnu-linux-magazine/varnish-un-proxy-qui-vous-veut-du-bien
Quelle est la différence entre "apt-cacher-ng" et "varnish" ?
Merci.
André
On Friday 07 June 2013 21:13:57 Christophe wrote:Je confirme, qu'apt-cacher-ng est bigrement efficace.
Un gain énorme de bande passante, et surtout de temps ! surtout dans mon
cas : je suis un peu ravitaillé par les moineaux niveau Internet ...
Une simple config de base , et préciser l'adresse du proxy dans les
machines clientes, ça fait des miracles .
Ensuite tu peux définir des chemins sur le proxy pour attaquer des
dépots externes en fonction des besoins , toujours en conservant la
fonction de cache , et donc installer et mettre à jour les machines à la
vitesse du réseau local ;) . @+ Christophe.
Bonjour,
"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web (hébergé)
avec d'autres services (MySQL, Postfix, Mailman etc ...)
en termes d'accélération, de gain ...
Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
reverse-proxy HTTP "accélérateur" libre (licence BSD) permettant de soulager les serveurs web.
Lien :
www.unixgarden.com/index.php/gnu-linux-magazine/varnish-un-proxy-qui-vous-veut-du-bien
Quelle est la différence entre "apt-cacher-ng" et "varnish" ?
Merci.
André
"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
(hébergé) avec d'autres services (MySQL, Postfix, Mailman etc . ..)
en termes d'accélération, de gain ...
Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
Quelle est la différence entre "apt-cacher-ng" et "varnish" ?
"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
(hébergé) avec d'autres services (MySQL, Postfix, Mailman etc . ..)
en termes d'accélération, de gain ...
Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
Quelle est la différence entre "apt-cacher-ng" et "varnish" ?
"apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
(hébergé) avec d'autres services (MySQL, Postfix, Mailman etc . ..)
en termes d'accélération, de gain ...
Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
Quelle est la différence entre "apt-cacher-ng" et "varnish" ?
wrote:
> "apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
> (hébergé) avec d'autres services (MySQL, Postfix, Mailman etc ...)
> en termes d'accélération, de gain ...
Au vu de l'intro de la doc d'apt-cacher-ng, nan.
> Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
Pas que pour Apache, pour la plupart des svrs http.
Il existe aussi php-apc, qui marche uniquement en RAM, et qui
n'est pômal du tout pour un site petit à moyen.
Ce comparatif n'est pas trop mal fait (on n'ergote pas sur la
méthodologie SVP, puisque chacun considère que la sienne est
la meilleure!):
http://francois.aichelbaum.com/comparatif-caching-nginxvarnishsquidapache/
et si varnish cohabite mal avec nginx, nginx tout seul se débrouille
pratiquement aussi bien que les confs "accélérées" avec mo ins
de besoins en RAM et de soucis de confâ¦
> Quelle est la différence entre "apt-cacher-ng" et "varnish" ? :
L'un est un proxy spécifiquement orienté vers les _packages_ De bian,
l'autre est un proxy exclusivement HTTP (et d'ailleurs, plus un cache
qu'un proxy, si mes souvenirs de ses docs sont bons).
Ceci est également intéressant (NB: le test ne porte QUE sur du statique):
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwa n/
comme quoi les proxies et les caches ne sont pas forcément la meille ure solution pour les grosses
charges.
Malheureusement, G-Wan est un Freeware non open-source.
Celui-ci explique pourquoi il ne s'emm... même pas avec varnish:
http://rtcamp.com/tutorials/why-we-never-use-varnish-with-nginx/
normal, en dehors de G-Wan, et vu que Cherokee semble mortibus,
nginx est le plus performant; de plus il est aussi excellent en
temps que reverse-proxy & load balancer.
andre_debian@numericable.fr wrote:
> "apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
> (hébergé) avec d'autres services (MySQL, Postfix, Mailman etc ...)
> en termes d'accélération, de gain ...
Au vu de l'intro de la doc d'apt-cacher-ng, nan.
> Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
Pas que pour Apache, pour la plupart des svrs http.
Il existe aussi php-apc, qui marche uniquement en RAM, et qui
n'est pômal du tout pour un site petit à moyen.
Ce comparatif n'est pas trop mal fait (on n'ergote pas sur la
méthodologie SVP, puisque chacun considère que la sienne est
la meilleure!):
http://francois.aichelbaum.com/comparatif-caching-nginxvarnishsquidapache/
et si varnish cohabite mal avec nginx, nginx tout seul se débrouille
pratiquement aussi bien que les confs "accélérées" avec mo ins
de besoins en RAM et de soucis de confâ¦
> Quelle est la différence entre "apt-cacher-ng" et "varnish" ? :
L'un est un proxy spécifiquement orienté vers les _packages_ De bian,
l'autre est un proxy exclusivement HTTP (et d'ailleurs, plus un cache
qu'un proxy, si mes souvenirs de ses docs sont bons).
Ceci est également intéressant (NB: le test ne porte QUE sur du statique):
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwa n/
comme quoi les proxies et les caches ne sont pas forcément la meille ure solution pour les grosses
charges.
Malheureusement, G-Wan est un Freeware non open-source.
Celui-ci explique pourquoi il ne s'emm... même pas avec varnish:
http://rtcamp.com/tutorials/why-we-never-use-varnish-with-nginx/
normal, en dehors de G-Wan, et vu que Cherokee semble mortibus,
nginx est le plus performant; de plus il est aussi excellent en
temps que reverse-proxy & load balancer.
wrote:
> "apt-cacher-ng" peut-il avoir un intérêt pour un serveur Web
> (hébergé) avec d'autres services (MySQL, Postfix, Mailman etc ...)
> en termes d'accélération, de gain ...
Au vu de l'intro de la doc d'apt-cacher-ng, nan.
> Pour les serveurs Web sous Apache, il y a l'outil "varnish" :
Pas que pour Apache, pour la plupart des svrs http.
Il existe aussi php-apc, qui marche uniquement en RAM, et qui
n'est pômal du tout pour un site petit à moyen.
Ce comparatif n'est pas trop mal fait (on n'ergote pas sur la
méthodologie SVP, puisque chacun considère que la sienne est
la meilleure!):
http://francois.aichelbaum.com/comparatif-caching-nginxvarnishsquidapache/
et si varnish cohabite mal avec nginx, nginx tout seul se débrouille
pratiquement aussi bien que les confs "accélérées" avec mo ins
de besoins en RAM et de soucis de confâ¦
> Quelle est la différence entre "apt-cacher-ng" et "varnish" ? :
L'un est un proxy spécifiquement orienté vers les _packages_ De bian,
l'autre est un proxy exclusivement HTTP (et d'ailleurs, plus un cache
qu'un proxy, si mes souvenirs de ses docs sont bons).
Ceci est également intéressant (NB: le test ne porte QUE sur du statique):
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwa n/
comme quoi les proxies et les caches ne sont pas forcément la meille ure solution pour les grosses
charges.
Malheureusement, G-Wan est un Freeware non open-source.
Celui-ci explique pourquoi il ne s'emm... même pas avec varnish:
http://rtcamp.com/tutorials/why-we-never-use-varnish-with-nginx/
normal, en dehors de G-Wan, et vu que Cherokee semble mortibus,
nginx est le plus performant; de plus il est aussi excellent en
temps que reverse-proxy & load balancer.
C'est bien "G-Wan" qui arrive largement en tête, mais proprio ...
"Nginx" est quand même bien placé et Libre.
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 ?
Côté Apache, il y a plusieurs Modules multi-processus "MPM" :
"Prefork" , "Worker" et "Event".
Lequel choisir pour avoir un serveur à forte disponibilité ?
C'est bien "G-Wan" qui arrive largement en tête, mais proprio ...
"Nginx" est quand même bien placé et Libre.
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 ?
Côté Apache, il y a plusieurs Modules multi-processus "MPM" :
"Prefork" , "Worker" et "Event".
Lequel choisir pour avoir un serveur à forte disponibilité ?
C'est bien "G-Wan" qui arrive largement en tête, mais proprio ...
"Nginx" est quand même bien placé et Libre.
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 ?
Côté Apache, il y a plusieurs Modules multi-processus "MPM" :
"Prefork" , "Worker" et "Event".
Lequel choisir pour avoir un serveur à forte disponibilité ?
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) :
> 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 croiss ance
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⦠:
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) :
> 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 croiss ance
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⦠:
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) :
> 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 croiss ance
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⦠:
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 comment aire,
je préfère le savoir avant : "you must pay before starting B-Wa n ..."
Elles ne suivent pas trop les évolutions.
Et SkySQL ? : est-il du niveau de PostgreSQL ?
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 comment aire,
je préfère le savoir avant : "you must pay before starting B-Wa n ..."
Elles ne suivent pas trop les évolutions.
Et SkySQL ? : est-il du niveau de PostgreSQL ?
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 comment aire,
je préfère le savoir avant : "you must pay before starting B-Wa n ..."
Elles ne suivent pas trop les évolutions.
Et SkySQL ? : est-il du niveau de PostgreSQL ?