Voila j'ai une question d'ordre géneral par rapport au simple ou bi-
processeur. (ou quadruple, etc...)
La question est la suivante :
A partir du moment ou une distribution de Linux est installé avec un noyau
*-smp* (donc prenant en compte le mutli proc), est ce que les services (ou
serveurs) squid, samba, apache, ou autres fonctionneront plus vite ?
Plus de processeurs signifie t il que l'on pourra augmenter le nombre de
clients sans ralentissement de la machine ?
Ou est ce que les temps de réponses seront meilleurs ?
Ou faut il que les services (serveurs) soit prévu pour fonctionner avec
plusieurs procs, et ainsi en tirer le meilleurs parti ?
Sans être spécialiste de la question, j'ai vu une fois un serveur transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair et net, l'ensemble Apache-Mysql a mis le turbo.
A fréquence Cpu égale ?
Sans être spécialiste de la question, j'ai vu une fois un serveur
transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ;
clair et net, l'ensemble Apache-Mysql a mis le turbo.
Sans être spécialiste de la question, j'ai vu une fois un serveur transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair et net, l'ensemble Apache-Mysql a mis le turbo.
A fréquence Cpu égale ?
sansflotusspam
Sans être spécialiste de la question, j'ai vu une fois un serveur transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair et net, l'ensemble Apache-Mysql a mis le turbo.
A fréquence Cpu égale ?
non, bien sûr, mais dans ce cas précis, les 2 xeon tournaient moins vite que le pentium mono en fréquence proc et plus vite en fréquence mémoire avec de l'ecc. la différence de "réactivité" a été très très supérieure au simple rapport de fréquence mémoire ; il me semble donc que les explications "multi threads + forks" données dans le fil sont pertinentes.
en revanche, j'avais essayé il y a quelques années de monter un bi-proc amd smp, sans succès, la bête plantait systématiquement. mais ça venait de la carte mère qui était plutôt foireuse bien que vendue pour bi-proc. elle est restée en mono jusqu'à son flash final 18 mois plus tard.
A+
Sans être spécialiste de la question, j'ai vu une fois un serveur
transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ;
clair et net, l'ensemble Apache-Mysql a mis le turbo.
A fréquence Cpu égale ?
non, bien sûr, mais dans ce cas précis, les 2 xeon tournaient moins vite que
le pentium mono en fréquence proc et plus vite en fréquence mémoire avec de
l'ecc.
la différence de "réactivité" a été très très supérieure au simple rapport
de fréquence mémoire ; il me semble donc que les explications "multi
threads + forks" données dans le fil sont pertinentes.
en revanche, j'avais essayé il y a quelques années de monter un bi-proc amd
smp, sans succès, la bête plantait systématiquement. mais ça venait de la
carte mère qui était plutôt foireuse bien que vendue pour bi-proc. elle est
restée en mono jusqu'à son flash final 18 mois plus tard.
Sans être spécialiste de la question, j'ai vu une fois un serveur transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair et net, l'ensemble Apache-Mysql a mis le turbo.
A fréquence Cpu égale ?
non, bien sûr, mais dans ce cas précis, les 2 xeon tournaient moins vite que le pentium mono en fréquence proc et plus vite en fréquence mémoire avec de l'ecc. la différence de "réactivité" a été très très supérieure au simple rapport de fréquence mémoire ; il me semble donc que les explications "multi threads + forks" données dans le fil sont pertinentes.
en revanche, j'avais essayé il y a quelques années de monter un bi-proc amd smp, sans succès, la bête plantait systématiquement. mais ça venait de la carte mère qui était plutôt foireuse bien que vendue pour bi-proc. elle est restée en mono jusqu'à son flash final 18 mois plus tard.
A+
sansflotusspam
sansflotusspam writes:
Sans être spécialiste de la question, j'ai vu une fois un serveur transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair et net, l'ensemble Apache-Mysql a mis le turbo. Sur les postes clients et surtout les caisses, les temps moyens de réponse du serveur sont passés de 1 ou 4/5 secondes à une quasi instantanéité. Vrai aussi pour les applis "maison" faites en java. Les spécialistes nous expliqueront le détail du pourquoi et du comment.
Pour un serveur très chargé, doubler la rapidité du serveur peut faire bien mieux que diviser par deux le temps de réponse.
Que se passe-t-il si un serveur recoit toutes les secondes une requête qu'il met une seconde et demie à traiter par exemple ? ...
justement, c'était le cas. pour les détails, voir mon autre post.
Sans être spécialiste de la question, j'ai vu une fois un serveur
transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair
et net, l'ensemble Apache-Mysql a mis le turbo. Sur les postes clients et
surtout les caisses, les temps moyens de réponse du serveur sont passés
de 1 ou 4/5 secondes à une quasi instantanéité. Vrai aussi pour les
applis "maison" faites en java.
Les spécialistes nous expliqueront le détail du pourquoi et du comment.
Pour un serveur très chargé, doubler la rapidité du serveur peut faire
bien mieux que diviser par deux le temps de réponse.
Que se passe-t-il si un serveur recoit toutes les secondes une requête
qu'il met une seconde et demie à traiter par exemple ? ...
justement, c'était le cas. pour les détails, voir mon autre post.
Sans être spécialiste de la question, j'ai vu une fois un serveur transféré d'une machine mono-proc sur une machine bi-proc (Xeon) ; clair et net, l'ensemble Apache-Mysql a mis le turbo. Sur les postes clients et surtout les caisses, les temps moyens de réponse du serveur sont passés de 1 ou 4/5 secondes à une quasi instantanéité. Vrai aussi pour les applis "maison" faites en java. Les spécialistes nous expliqueront le détail du pourquoi et du comment.
Pour un serveur très chargé, doubler la rapidité du serveur peut faire bien mieux que diviser par deux le temps de réponse.
Que se passe-t-il si un serveur recoit toutes les secondes une requête qu'il met une seconde et demie à traiter par exemple ? ...
justement, c'était le cas. pour les détails, voir mon autre post.
