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 ?
Cela signifie il que Linux est capable d'assigner une tache a un processeur ? Par exemple requete Apache sur un proc et traitement de l'accès squid sur les ressources libres (donc sur le deuxème proc) ?
Pour bien comprendre ma question, prenons un exemple : Accès html sur apache : 100% proc-1 et 0% proc-2, donc il reste 100% du proc-2 pour autre chose.
ou bien 50% proc-1 et 50% proc-2 donc il reste 50% de chaque proc pour autre chose.
Peut être cela est il un peu schématique et simpliste comme image, mais ca m'aiderai bien à comprendre.
Cela signifie il que Linux est capable d'assigner une tache a un processeur
? Par exemple requete Apache sur un proc et traitement de l'accès squid sur
les ressources libres (donc sur le deuxème proc) ?
Pour bien comprendre ma question, prenons un exemple :
Accès html sur apache : 100% proc-1 et 0% proc-2, donc il reste 100% du
proc-2 pour autre chose.
ou bien 50% proc-1 et 50% proc-2 donc il reste 50% de chaque proc pour
autre chose.
Peut être cela est il un peu schématique et simpliste comme image, mais ca
m'aiderai bien à comprendre.
Cela signifie il que Linux est capable d'assigner une tache a un processeur ? Par exemple requete Apache sur un proc et traitement de l'accès squid sur les ressources libres (donc sur le deuxème proc) ?
Pour bien comprendre ma question, prenons un exemple : Accès html sur apache : 100% proc-1 et 0% proc-2, donc il reste 100% du proc-2 pour autre chose.
ou bien 50% proc-1 et 50% proc-2 donc il reste 50% de chaque proc pour autre chose.
Peut être cela est il un peu schématique et simpliste comme image, mais ca m'aiderai bien à comprendre.
C'est pour ma faire un petit serveur de test à la maison, et je regardai sur ebay ce qu'il y avait de dispo.
Soit à choisir un serveur avec un seul proc un peu puissant ou 2 proc moins puissant.
Calimero
Debellez wrote:
Cela signifie il que Linux est capable d'assigner une tache a un processeur ? Par exemple requete Apache sur un proc et traitement de l'accès squid sur les ressources libres (donc sur le deuxème proc) ?
Pour bien comprendre ma question, prenons un exemple : Accès html sur apache : 100% proc-1 et 0% proc-2, donc il reste 100% du proc-2 pour autre chose.
ou bien 50% proc-1 et 50% proc-2 donc il reste 50% de chaque proc pour autre chose.
Peut être cela est il un peu schématique et simpliste comme image, mais ca m'aiderai bien à comprendre.
Les processus sont répartis sur les différents processeurs.
Pour simplifier (beaucoup), on peut par exemple dire que Apache va forker dès qu'une requête arrive. Quand tu forkes, tu crées une copie de ton process. Tu as donc deux process. Le nouveau process va donc pouvoir gérer la connexion qui arrive puis va mourir. Donc si tu as 10 requêtes simultanées, ton Apache va forker 10 process. Ces 10 process seront répartis sur les deux CPU de ta machine: 5 sur l'un, 5 sur l'autre.
Admettons que Squid fonctionne sur le meme principe (un fork par requête), tu auras là aussi une répartition des process sur les deux CPU de ta machine. Dans un tel cas, tu pourrais te retrouver avec ca:
Process sur CPU0: - 6 x Apache (le process "maitre" + 5 requetes) - 6 x Squid (idem)
Process sur CPU1: - 5 x Apache (5 requetes) - 5 x Squid (idem)
Evidemment, c'est une simplification extreme (qui ne sert qu'à cacher mes lacunes sur le sujet ! ;-) ). Les algorithmes de répartition de charge doivent être un poil plus subtile... D'autre part Apache (et sans doute Squid que je n'ai jamais étudié) a différents modes de fonctionnement.
C'est pour ma faire un petit serveur de test à la maison, et je regardai sur ebay ce qu'il y avait de dispo.
Soit à choisir un serveur avec un seul proc un peu puissant ou 2 proc moins puissant.
En terme de performance pour un usage perso, ca n'a pas forcément grand intéret. Disons que si t'as des tests spécifiques au SMP, ca peut etre utile. Autrement...
-- @+ Calimero
Debellez wrote:
Cela signifie il que Linux est capable d'assigner une tache a un processeur
? Par exemple requete Apache sur un proc et traitement de l'accès squid sur
les ressources libres (donc sur le deuxème proc) ?
Pour bien comprendre ma question, prenons un exemple :
Accès html sur apache : 100% proc-1 et 0% proc-2, donc il reste 100% du
proc-2 pour autre chose.
ou bien 50% proc-1 et 50% proc-2 donc il reste 50% de chaque proc pour
autre chose.
Peut être cela est il un peu schématique et simpliste comme image, mais ca
m'aiderai bien à comprendre.
Les processus sont répartis sur les différents processeurs.
Pour simplifier (beaucoup), on peut par exemple dire que Apache va
forker dès qu'une requête arrive. Quand tu forkes, tu crées une copie
de ton process. Tu as donc deux process. Le nouveau process va donc
pouvoir gérer la connexion qui arrive puis va mourir.
Donc si tu as 10 requêtes simultanées, ton Apache va forker 10
process. Ces 10 process seront répartis sur les deux CPU de ta
machine: 5 sur l'un, 5 sur l'autre.
Admettons que Squid fonctionne sur le meme principe (un fork par
requête), tu auras là aussi une répartition des process sur les deux
CPU de ta machine.
Dans un tel cas, tu pourrais te retrouver avec ca:
Process sur CPU0:
- 6 x Apache (le process "maitre" + 5 requetes)
- 6 x Squid (idem)
Process sur CPU1:
- 5 x Apache (5 requetes)
- 5 x Squid (idem)
Evidemment, c'est une simplification extreme (qui ne sert qu'à cacher
mes lacunes sur le sujet ! ;-) ).
Les algorithmes de répartition de charge doivent être un poil plus
subtile...
D'autre part Apache (et sans doute Squid que je n'ai jamais étudié) a
différents modes de fonctionnement.
C'est pour ma faire un petit serveur de test à la maison, et je regardai
sur ebay ce qu'il y avait de dispo.
Soit à choisir un serveur avec un seul proc un peu puissant ou 2 proc moins
puissant.
En terme de performance pour un usage perso, ca n'a pas forcément
grand intéret. Disons que si t'as des tests spécifiques au SMP, ca
peut etre utile. Autrement...
Cela signifie il que Linux est capable d'assigner une tache a un processeur ? Par exemple requete Apache sur un proc et traitement de l'accès squid sur les ressources libres (donc sur le deuxème proc) ?
Pour bien comprendre ma question, prenons un exemple : Accès html sur apache : 100% proc-1 et 0% proc-2, donc il reste 100% du proc-2 pour autre chose.
ou bien 50% proc-1 et 50% proc-2 donc il reste 50% de chaque proc pour autre chose.
Peut être cela est il un peu schématique et simpliste comme image, mais ca m'aiderai bien à comprendre.
Les processus sont répartis sur les différents processeurs.
Pour simplifier (beaucoup), on peut par exemple dire que Apache va forker dès qu'une requête arrive. Quand tu forkes, tu crées une copie de ton process. Tu as donc deux process. Le nouveau process va donc pouvoir gérer la connexion qui arrive puis va mourir. Donc si tu as 10 requêtes simultanées, ton Apache va forker 10 process. Ces 10 process seront répartis sur les deux CPU de ta machine: 5 sur l'un, 5 sur l'autre.
Admettons que Squid fonctionne sur le meme principe (un fork par requête), tu auras là aussi une répartition des process sur les deux CPU de ta machine. Dans un tel cas, tu pourrais te retrouver avec ca:
Process sur CPU0: - 6 x Apache (le process "maitre" + 5 requetes) - 6 x Squid (idem)
Process sur CPU1: - 5 x Apache (5 requetes) - 5 x Squid (idem)
Evidemment, c'est une simplification extreme (qui ne sert qu'à cacher mes lacunes sur le sujet ! ;-) ). Les algorithmes de répartition de charge doivent être un poil plus subtile... D'autre part Apache (et sans doute Squid que je n'ai jamais étudié) a différents modes de fonctionnement.
C'est pour ma faire un petit serveur de test à la maison, et je regardai sur ebay ce qu'il y avait de dispo.
Soit à choisir un serveur avec un seul proc un peu puissant ou 2 proc moins puissant.
En terme de performance pour un usage perso, ca n'a pas forcément grand intéret. Disons que si t'as des tests spécifiques au SMP, ca peut etre utile. Autrement...
-- @+ Calimero
Debellez
Process sur CPU0: - 6 x Apache (le process "maitre" + 5 requetes) - 6 x Squid (idem)
Process sur CPU1: - 5 x Apache (5 requetes) - 5 x Squid (idem)
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Puisque le seul proc 1GHz traitera les forkes les unes à la suite des autres tandis que nos deux procs se les répartiront...
En terme de performance pour un usage perso, ca n'a pas forcément grand intéret. Disons que si t'as des tests spécifiques au SMP, ca peut etre utile. Autrement...
Bien compris.
Process sur CPU0:
- 6 x Apache (le process "maitre" + 5 requetes)
- 6 x Squid (idem)
Process sur CPU1:
- 5 x Apache (5 requetes)
- 5 x Squid (idem)
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII
500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Puisque le seul proc 1GHz traitera les forkes les unes à la suite des
autres tandis que nos deux procs se les répartiront...
En terme de performance pour un usage perso, ca n'a pas forcément
grand intéret. Disons que si t'as des tests spécifiques au SMP, ca
peut etre utile. Autrement...
Process sur CPU0: - 6 x Apache (le process "maitre" + 5 requetes) - 6 x Squid (idem)
Process sur CPU1: - 5 x Apache (5 requetes) - 5 x Squid (idem)
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Puisque le seul proc 1GHz traitera les forkes les unes à la suite des autres tandis que nos deux procs se les répartiront...
En terme de performance pour un usage perso, ca n'a pas forcément grand intéret. Disons que si t'as des tests spécifiques au SMP, ca peut etre utile. Autrement...
Bien compris.
Matthieu Moy
Debellez writes:
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Pas tout a fait.
Si ton 500Mhz met 1 seconde a traiter la requete, que deux requetes arrivent en meme temps, sur un mono-proc 1Ghz, une requete sera probablement terminee avant l'autre (si il n'y a pas _du tout_ de parallelisme, la premiere requete sera terminee au bout d'une demie seconde), et la seconde sera terminee au bout d'une secondes. Sur un bi-pro, les deux termineront en meme temps.
-- Matthieu
Debellez <debellez@free.fr.nospam> writes:
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII
500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Pas tout a fait.
Si ton 500Mhz met 1 seconde a traiter la requete, que deux requetes
arrivent en meme temps, sur un mono-proc 1Ghz, une requete sera
probablement terminee avant l'autre (si il n'y a pas _du tout_ de
parallelisme, la premiere requete sera terminee au bout d'une demie
seconde), et la seconde sera terminee au bout d'une secondes. Sur un
bi-pro, les deux termineront en meme temps.
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Pas tout a fait.
Si ton 500Mhz met 1 seconde a traiter la requete, que deux requetes arrivent en meme temps, sur un mono-proc 1Ghz, une requete sera probablement terminee avant l'autre (si il n'y a pas _du tout_ de parallelisme, la premiere requete sera terminee au bout d'une demie seconde), et la seconde sera terminee au bout d'une secondes. Sur un bi-pro, les deux termineront en meme temps.
-- Matthieu
Calimero
Debellez wrote:
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Puisque le seul proc 1GHz traitera les forkes les unes à la suite des autres tandis que nos deux procs se les répartiront...
Les unes à la suite des autres... disons qu'on est qd meme dans des OS multitaches où en gros, on émule la simultanéité (un peu de travail du process0, un peu du process1, un peu du process0, etc...).
Maintenant, dans un environnement avec peu de travail en //, je serais tenté de dire qu'un bi-500 sera moins rapide qu'un mono-1Ghz.
Difficile de donner une réponse définitive dans un tel cas. Ca dépend beaucoup de l'utilisation qui sera faite.
-- @+ Calimero
Debellez wrote:
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII
500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Puisque le seul proc 1GHz traitera les forkes les unes à la suite des
autres tandis que nos deux procs se les répartiront...
Les unes à la suite des autres... disons qu'on est qd meme dans des OS
multitaches où en gros, on émule la simultanéité (un peu de travail du
process0, un peu du process1, un peu du process0, etc...).
Maintenant, dans un environnement avec peu de travail en //, je serais
tenté de dire qu'un bi-500 sera moins rapide qu'un mono-1Ghz.
Difficile de donner une réponse définitive dans un tel cas. Ca dépend
beaucoup de l'utilisation qui sera faite.
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Puisque le seul proc 1GHz traitera les forkes les unes à la suite des autres tandis que nos deux procs se les répartiront...
Les unes à la suite des autres... disons qu'on est qd meme dans des OS multitaches où en gros, on émule la simultanéité (un peu de travail du process0, un peu du process1, un peu du process0, etc...).
Maintenant, dans un environnement avec peu de travail en //, je serais tenté de dire qu'un bi-500 sera moins rapide qu'un mono-1Ghz.
Difficile de donner une réponse définitive dans un tel cas. Ca dépend beaucoup de l'utilisation qui sera faite.
-- @+ Calimero
sansflotusspam
Bonjour (re)
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 ? Merci d'acance.
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. A+
Bonjour (re)
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 ?
Merci d'acance.
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.
A+
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 ? Merci d'acance.
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. A+
Matthieu Moy
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 ? ...
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 ? ...
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 ? ...
-- Matthieu
Debellez
Matthieu Moy wrote in news::
Debellez writes:
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Pas tout a fait.
Si ton 500Mhz met 1 seconde a traiter la requete, que deux requetes arrivent en meme temps, sur un mono-proc 1Ghz, une requete sera probablement terminee avant l'autre (si il n'y a pas _du tout_ de parallelisme, la premiere requete sera terminee au bout d'une demie seconde), et la seconde sera terminee au bout d'une secondes. Sur un bi-pro, les deux termineront en meme temps.
Oui, donc dans ton explication, les deux terminent en 1 seconde... :o)
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote in
news:vpqoe2asu2x.fsf@ecrins.imag.fr:
Debellez <debellez@free.fr.nospam> writes:
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un
BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un
mono 1GHz.
Pas tout a fait.
Si ton 500Mhz met 1 seconde a traiter la requete, que deux requetes
arrivent en meme temps, sur un mono-proc 1Ghz, une requete sera
probablement terminee avant l'autre (si il n'y a pas _du tout_ de
parallelisme, la premiere requete sera terminee au bout d'une demie
seconde), et la seconde sera terminee au bout d'une secondes. Sur un
bi-pro, les deux termineront en meme temps.
Oui, donc dans ton explication, les deux terminent en 1 seconde... :o)
Dans ce cas, et par ce raisonnement, est ce que cela signie, que un BI PIII 500 MHz traitera ces fameuses forkes aussi rapidement qu'un mono 1GHz.
Pas tout a fait.
Si ton 500Mhz met 1 seconde a traiter la requete, que deux requetes arrivent en meme temps, sur un mono-proc 1Ghz, une requete sera probablement terminee avant l'autre (si il n'y a pas _du tout_ de parallelisme, la premiere requete sera terminee au bout d'une demie seconde), et la seconde sera terminee au bout d'une secondes. Sur un bi-pro, les deux termineront en meme temps.
Oui, donc dans ton explication, les deux terminent en 1 seconde... :o)
