Questions sur les proxy-cache pour accélérer l'installation de serveurs Debian

Le
Olivier
--047d7b5d8e7920d8b304de8d56eb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai des scripts d'installation de serveurs Debia qui télé-chargent tr=
ès
souvent les mêmes fichiers.
J'ai envie de raccourcir la durée d'exécution de ces scripts en install=
ant
un cache ou un proxy (je ne sais pas quel est le meilleur terme pour
décrire ce que je recherche).
Je suis novice en la matière et je cherche dans l'immédiat à bien exp=
rimer
mes besoins.

Les fichiers télé-chargés sont:
- soit des paquets .deb téléchargés via apt (et uniquement par ce can=
al),
- soit des archives .tar.gz téléchargés par wget.

Comme je travaille sur plusieurs versions de Debian (lenny, squeeze, ),
le cache ou proxy ne doit pas mélanger les paquets .deb eponymes provenan=
t
de versions différentes de Debian.


Les scripts s'exécutent sur des machines installées dans un environneme=
nt
de développement. Une fois que ces machines ont correctement testées, e=
lles
sont ensuite déplacées dans un environnement de production, avec le min=
imum
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 elle=
s
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ére=
ront
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 ?) ?

Slts

--047d7b5d8e7920d8b304de8d56eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div>Bonjour,<br><br></div>J&#39;ai des scripts d&#39;installation de ser=
veurs Debia qui télé-chargent très souvent les mêmes fichiers.<br><=
/div>J&#39;ai envie de raccourcir la durée d&#39;exécution de ces scrip=
ts en installant un cache ou un proxy (je ne sais pas quel est le meilleur =
terme pour décrire ce que je recherche).<br>
</div>Je suis novice en la matière et je cherche dans l&#39;immédiat =
à bien exprimer mes besoins.<br><br></div><div>Les fichiers télé-char=
gés sont:<br></div><div>- soit des paquets .deb téléchargés via apt=
(et uniquement par ce canal),<br>
</div><div>- soit des archives .tar.gz téléchargés par wget.<br><br>=
</div><div>Comme je travaille sur plusieurs versions de Debian (lenny, sque=
eze, ), le cache ou proxy ne doit pas mélanger les paquets .deb epony=
mes provenant de versions différentes de Debian.<br>
<br></div><div><br>Les scripts s&#39;exécutent sur des machines install=
ées dans un environnement de développement. Une fois que ces machines o=
nt correctement testées, elles sont ensuite déplacées dans un environ=
nement de production, avec le minimum de modifications dans leur configurat=
ion.<br>
<br></div></div></div></div>Je m&#39;interroge s&#39;il est possible/préf=
érable :<br></div>1. soit de modifier l&#39;environnement de développem=
ent (proxy transparent ?) de telle sorte que les machines cibles ne soient =
pas modifiées quand elles passent dans l&#39;environnement de production,=
<br>
</div>2. soit d&#39;accepter de modifier la configuration d&#39;une machine=
quand elle passe en production avec le bénéfice de simplifier la confi=
guration de l&#39;environnement de développement car les machines qu&#39;=
il servira coopéreront avec lui pour atteindre l&#39;objectif fixé.<br>
<br></div>Mes questions sont:<br></div>A. Vaut-il mieux choisir l&#39;optio=
n 1 ou l&#39;option 2 (je penche plutôt pour la 2) ?<br></div>B. Quels ou=
tils utiliser (j&#39;imagine 2 outils spécialisés : un pour wget (Squid=
?) et un pour apt (lequel ?) ?<br>
<br></div>Slts<br></div>

--047d7b5d8e7920d8b304de8d56eb--

--
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/CAPeT9jjFydLpwV_cOhkL7HwrH6BuaxdQcSMrwdzOgbvXqkV_Hw@mail.gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
S
Le #25465032
Le vendredi 07 juin 2013 à 11:48, Olivier a écrit :
Bonjour,



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



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érangerait pas,
d'autant plus qu'une fois en prod, la machine ne devrait plus (ou du moins
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. Pour APT, il
y en a plusieurs, je n'en ai jamais utilisé aucun :
approx - serveur mandataire et cache pour les fichiers d'archive Debian
apt-cacher - proxy cache pour les paquets Debian et les fichiers source
apt-cacher-ng - serveur mandataire de cache pour les dépôts logiciel

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/
Olivier
Le #25465172
--001a11c35c08f757ff04de8e76ff
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Le 7 juin 2013 12:24, Sébastien NOBILI
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…




J'ai l'impression que s'imposer de ne pas modifier la configuration sur la
machine cible lors de son déplacement en prod (option 1) est très diffi cile.
À la réflexion, ça me parait assez naturel de modifier les paramètr es des
proxy sur une machine qui change d'environnement.



> 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




Ce dernier a l'air intéressant ...



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/





--001a11c35c08f757ff04de8e76ff
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

&gt; Bonjour,<br>
<br>
Bonjour,<br>
<div class="im"><br>
&gt; Les scripts s&#39;exécutent sur des machines installées dans un en vironnement<br>
&gt; de développement. Une fois que ces machines ont correctement testé es, elles<br>
&gt; sont ensuite déplacées dans un environnement de production, avec l e minimum<br>
&gt; de modifications dans leur configuration.<br>
&gt;<br>
&gt; Je m&#39;interroge s&#39;il est possible/préférable :<br>
&gt; 1. soit de modifier l&#39;environnement de développement (proxy tran sparent ?)<br>
&gt; de telle sorte que les machines cibles ne soient pas modifiées quand elles<br>
&gt; passent dans l&#39;environnement de production,<br>
&gt; 2. soit d&#39;accepter de modifier la configuration d&#39;une machine quand elle<br>
&gt; passe en production avec le bénéfice de simplifier la configuratio n de<br>
&gt; l&#39;environnement de développement car les machines qu&#39;il serv ira coopéreront<br>
&gt; avec lui pour atteindre l&#39;objectif fixé.<br>
&gt;<br>
&gt; Mes questions sont:<br>
&gt; A. Vaut-il mieux choisir l&#39;option 1 ou l&#39;option 2 (je penche p lutôt pour la<br>
&gt; 2) ?<br>
<br>
</div>Pourquoi cette préférence pour la 2 ? Pour éviter le passage pa r un proxy sur<br>
une machine de prod ? Si c&#39;est ça, personnellement ça ne me déran gerait pas,<br>
d&#39;autant plus qu&#39;une fois en prod, la machine ne devrait plus (ou d u moins<br>
beaucoup moins qu&#39;avant) solliciter le proxy…
<div class="im"><br>
&gt; B. Quels outils utiliser (j&#39;imagine 2 outils spécialisés : un pour wget<br>
&gt; (Squid ?) et un pour apt (lequel ?) ?<br>
<br>
y en a plusieurs, je n&#39;en ai jamais utilisé aucun :<br>
    approx - serveur mandataire et cache pour les fichiers d&#39;archiv e Debian<br>
    apt-cacher - proxy cache pour les paquets Debian et les fichiers so urce<br>
    apt-cacher-ng - serveur mandataire de cache pour les dépôts log iciel
<br>
Seb<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS Archive: <br>
</font></span></blockquote></div><br></div></div>

--001a11c35c08f757ff04de8e76ff--

--
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/CAPeT9jjBv»_AGYfgqVMhHbF=
andre_debian
Le #25466892
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 sou lager les serveurs web.
Lien :
www.unixgarden.com/index.php/gnu-linux-magazine/varnish-un-proxy-qui-vous-v eut-du-bien

Quelle est la différence entre "apt-cacher-ng" et "varnish" ?

Merci.

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/
Erwan David
Le #25466982
Le 08/06/2013 17:35, a écrit :
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é




Ça n'a strictement rien à voir.

varnish est un reverse proxy qui (en gros) va réorienter des requêtes
web sur différents serveurs, il est du côté des serveurs web

apt-cacher-ng ets un proxy côté client spécialisé pour apt. Deux tâches
qui n'ont rien à voir

--
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/
Bzzz
Le #25466972
On Sat, 8 Jun 2013 17:35:22 +0200
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 moins
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_ Debi an,
l'autre est un proxy exclusivement HTTP (et d'ailleurs, plus un cache
qu'un proxy, si mes souvenirs de ses docs sont bons).

--
<Yanhou> J'ai le bras dans le plâtre ...
<Toto> Comment t'as fait ? Tu sors jamais de ta chambre ?
<Yanhou> ...
<Yanhou> Je suis tombé de ma chaise ...

--
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/
Bzzz
Le #25467002
On Sat, 8 Jun 2013 17:35:22 +0200
wrote:

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-gwan/
comme quoi les proxies et les caches ne sont pas
forcément la meilleure 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.

--
Pangwai : alors sur yahoo, c'est de très mauvais goût, l'affichage
aléatoire des niouz
Pangwai : "un père soupçonné d'avoir tué son fils de tr ois ans en
le mettant au lave linge"
Pangwai : suivi de
Pangwai : "que mettre au micro-ondes ?"

--
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/
andre_debian
Le #25467412
On Saturday 08 June 2013 17:54:51 Bzzz wrote:
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.



Merci pour les explications et liens instructifs :
très bonne synthèse des "accélérateurs" de serveurs Web.
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é ?

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/
Bzzz
Le #25467502
On Sat, 8 Jun 2013 22:33:38 +0200
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 co mme 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 croissan ce
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 quo i ?
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
andre_debian
Le #25468262
On Saturday 08 June 2013 23:18:57 Bzzz wrote:

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 commentai re,
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 performan ces
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 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 ? :



Ici aussi, bien des entreprises, dont de gros hébergeurs ou data cente rs,
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é

--
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/
Bzzz
Le #25468322
On Sun, 9 Jun 2013 15:10:27 +0200
wrote:

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



Normal, vu le commentaire…

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



Si tu *veux vraiment* apprendre des choses, il va falloir
te retirer les doigts et chercher par toi-même; à commencer
par la définition de 'freeware'.

Elles ne suivent pas trop les évolutions.



Suivre ou pas l'évolution est conditionné à différents points:

1- évoluer pour évoluer est un tropisme introduit par m$; à partir
du moment où l'évolution en question n'amène pas de patch (es)
de sécurité ni de fonctionnalité(s) supplémentaire(s ) absolument
nécessaires à l'exploitation, pourquoi évoluer? (et risqu er de
se retrouver avec une conf à refaire intégralement parce que l es
primitives et la syntaxe de la conf a changée).

2- changer une pièce maîtresse d'un dispositif qui donne satisfac tion
est l'anti-thèse de 'système stable'. Règle première de
l'informatique professionnelle: 'quand satisafaisante est ta
configuration, n'y toucher plus tu ne feras'

3- les sites en question doivent la plupart du temps assurer un
service à cinq 9; une migration complète peut avoir (et selon
Murphy, aura) des retentissements sur le service proposé
(ralentissements dans le meilleur des cas, plantage total dans
le moins bon) - Serais-tu prêt à prendre une telle responsabil ité
vis-à-vis des utilisateurs comme de ta direction?

4- comme les constructeurs de voiture japonais l'ont compris depuis
longtemps (pas les français, et en tout état de cause absolume nt
pas renault), la meilleur façon de faire une nouvelle voiture
c'est de réutiliser un maximum de pièces qui ont fait leurs pr euves;
dans le but évident de minorer le plus possible les points de panne.
Dans l'informatique, c'est pareil: quand on connaît un pgm ou une
application sur le bout des doigts, on ne change pas pour quelque
chose d'autre qu'on ne maîtrise pas à 100%.
Pour pouvoir changer, il y a un temps non négligeable d'apprentissa ge
et de tests qui est incompressible (enfin, quand on est sérieux).

5- un changement, même pour obtenir des perfs extraordinaires, doit
aussi s'appuyer sur un support certain; hors; même si la communaut é
de nginx augmente régulièrement et sensiblement, elle est
actuellement très loin de celle d'apache (à relativiser: bcp
d'"experts" apache sont souvent des burnes une fois sortis d'un
contexte particulier).

6- Obi Wan Kenobee.

Et SkySQL ? : est-il du niveau de PostgreSQL ?



C'est quoi ça, ça existe?

La page de garde indique de l'hébergement spécialisé et de la
compétence mysql, une autre page indique une fusion des devs
avec le team de mariadb, qui n'est autre qu'un fork de mysql.
Peut-être dans qq années finiront-ils par sortir qq chose qui
tienne la route…

--
@guillaume: Hier j'ai appelé mon réseau wifi "Hack me if you can".
Aujourd'hui il s'appelle "Challenge accepted"

--
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/
Publicité
Poster une réponse
Anonyme