Sur un dédié virtuel, quelles sont les ressources en commun au niveau
logiciel ?
S'il y en a aucune, le seul intérêt est-il de payer moins cher pour un
mini-dédié ?
La virtualisation n'est PLUS le future du hosting, elle EST le hosting. Les clients en dédié (sauf ceux qui consomme vraiment beaucoup de ressources) et en mutu, pour ma part, se font de plus en plus rare, alors que c'est plutot l'inverse pour les clients Xen, au fur et a mesure que les clients comprennent a quoi ça sert et pourquoi c'est bien...
C'est peut être que vous êtes plus forts sur le virtuel que sur le mutu. Moi je n'ai jamais eu UN SEUL client qui m'a demandé un virtualisé. Le client à qui on ne peut pas répondre avec un mutu, c'est qu'il lui faut un dédié, et encore un costaud, car un dédié low-cost ne tiendrait pas le coup.
GPLHost (thomas) wrote:
La virtualisation n'est PLUS le future du hosting, elle EST le hosting.
Les clients en dédié (sauf ceux qui consomme vraiment beaucoup de
ressources) et en mutu, pour ma part, se font de plus en plus rare,
alors que c'est plutot l'inverse pour les clients Xen, au fur et a
mesure que les clients comprennent a quoi ça sert et pourquoi c'est
bien...
C'est peut être que vous êtes plus forts sur le virtuel que sur le mutu. Moi
je n'ai jamais eu UN SEUL client qui m'a demandé un virtualisé. Le client à
qui on ne peut pas répondre avec un mutu, c'est qu'il lui faut un dédié, et
encore un costaud, car un dédié low-cost ne tiendrait pas le coup.
La virtualisation n'est PLUS le future du hosting, elle EST le hosting. Les clients en dédié (sauf ceux qui consomme vraiment beaucoup de ressources) et en mutu, pour ma part, se font de plus en plus rare, alors que c'est plutot l'inverse pour les clients Xen, au fur et a mesure que les clients comprennent a quoi ça sert et pourquoi c'est bien...
C'est peut être que vous êtes plus forts sur le virtuel que sur le mutu. Moi je n'ai jamais eu UN SEUL client qui m'a demandé un virtualisé. Le client à qui on ne peut pas répondre avec un mutu, c'est qu'il lui faut un dédié, et encore un costaud, car un dédié low-cost ne tiendrait pas le coup.
filh
GPLHost (thomas) wrote:
Marc Plunian wrote:
Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
C'est possible si tu utilise PHP en cgi-bin, et que tu utilise sbox par exemple en cgi-wrapper pour faier un chroot des cgi-bin. Ca marche très bien.
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont donné des temps de réponse x5 par rapport à du php en module...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple
pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
C'est possible si tu utilise PHP en cgi-bin, et que tu utilise sbox par
exemple en cgi-wrapper pour faier un chroot des cgi-bin. Ca marche très
bien.
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont
donné des temps de réponse x5 par rapport à du php en module...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
C'est possible si tu utilise PHP en cgi-bin, et que tu utilise sbox par exemple en cgi-wrapper pour faier un chroot des cgi-bin. Ca marche très bien.
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont donné des temps de réponse x5 par rapport à du php en module...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Christophe Baegert
FiLH wrote:
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques pourcents plus rapide que le PHP en module. Quant à la sécurité du PHP en module... c'est utilisable uniquement en dédié à mon avis tellement c'est une passoire.
FiLH wrote:
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont
donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques
pourcents plus rapide que le PHP en module. Quant à la sécurité du PHP en
module... c'est utilisable uniquement en dédié à mon avis tellement c'est
une passoire.
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques pourcents plus rapide que le PHP en module. Quant à la sécurité du PHP en module... c'est utilisable uniquement en dédié à mon avis tellement c'est une passoire.
filh
Christophe Baegert wrote:
FiLH wrote:
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques pourcents plus rapide que le PHP en module.
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai perdu le nom du module qui fait ça): à chaque invocation on rechargeait le binaire php... et comme on a beaucoup de modules...
Quant à la sécurité du PHP en module... c'est utilisable uniquement en dédié à mon avis tellement c'est une passoire.
Il faut la travailler beaucoup effectivement... :)
Et chez nous c'est encore pire que du mutualisé...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont
donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques
pourcents plus rapide que le PHP en module.
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai
perdu le nom du module qui fait ça): à chaque invocation on rechargeait
le binaire php... et comme on a beaucoup de modules...
Quant à la sécurité du PHP en
module... c'est utilisable uniquement en dédié à mon avis tellement c'est
une passoire.
Il faut la travailler beaucoup effectivement... :)
Et chez nous c'est encore pire que du mutualisé...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques pourcents plus rapide que le PHP en module.
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai perdu le nom du module qui fait ça): à chaque invocation on rechargeait le binaire php... et comme on a beaucoup de modules...
Quant à la sécurité du PHP en module... c'est utilisable uniquement en dédié à mon avis tellement c'est une passoire.
Il faut la travailler beaucoup effectivement... :)
Et chez nous c'est encore pire que du mutualisé...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Christophe Baegert
FiLH wrote:
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai perdu le nom du module qui fait ça): à chaque invocation on rechargeait le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà une partie de l'explication pour ceux qui ne comprennent pas pourquoi on est 4 fois plus cher que les discounts)
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois plus lent que le module au lancement, mais à l'exécution, alors que le FastCGI qui est sensé réduire le temps de lancement permet en réalité d'exploser les perfs en exécution... Cherchez l'erreur !
FiLH wrote:
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai
perdu le nom du module qui fait ça): à chaque invocation on rechargeait
le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup
c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en
plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà
une partie de l'explication pour ceux qui ne comprennent pas pourquoi on
est 4 fois plus cher que les discounts)
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois
plus lent que le module au lancement, mais à l'exécution, alors que le
FastCGI qui est sensé réduire le temps de lancement permet en réalité
d'exploser les perfs en exécution... Cherchez l'erreur !
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai perdu le nom du module qui fait ça): à chaque invocation on rechargeait le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà une partie de l'explication pour ceux qui ne comprennent pas pourquoi on est 4 fois plus cher que les discounts)
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois plus lent que le module au lancement, mais à l'exécution, alors que le FastCGI qui est sensé réduire le temps de lancement permet en réalité d'exploser les perfs en exécution... Cherchez l'erreur !
filh
Christophe Baegert wrote:
FiLH wrote:
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai perdu le nom du module qui fait ça): à chaque invocation on rechargeait le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà une partie de l'explication pour ceux qui ne comprennent pas pourquoi on est 4 fois plus cher que les discounts)
J'ai retrouvé c'est suphp... hum... le fastCGI c'est le binaire qui reste chargé et on lui envoit les données si je me souviens bien ? Le pb est qu'on a 1300 utilisateurs potentiels de la chose, et il me semblait dans ce cas là qu'il fallait un php par uid. Ce qui n'est pas raisonnable (bon si on pouvait gérer un truc genre lancer le binaire pour un utilisateur et le laisser... un certain temps).
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois plus lent que le module au lancement, mais à l'exécution, alors que le FastCGI qui est sensé réduire le temps de lancement permet en réalité d'exploser les perfs en exécution... Cherchez l'erreur !
Exploser = amméliorer ? Hum... votre config m'intéresse :) :)... bon nous on est sous Solaris hein, mais on doit pouvoir jouer...
Ceci dit j'ai noté une énnorme différence de pref suivant qu'on prend un php avec trois modules ou si on ajoute un peu tout (notamment tous les modules attaquant divers types de bdd).
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai
perdu le nom du module qui fait ça): à chaque invocation on rechargeait
le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup
c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en
plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà
une partie de l'explication pour ceux qui ne comprennent pas pourquoi on
est 4 fois plus cher que les discounts)
J'ai retrouvé c'est suphp... hum... le fastCGI c'est le binaire qui
reste chargé et on lui envoit les données si je me souviens bien ?
Le pb est qu'on a 1300 utilisateurs potentiels de la chose, et il me
semblait dans ce cas là qu'il fallait un php par uid. Ce qui n'est pas
raisonnable (bon si on pouvait gérer un truc genre lancer le binaire
pour un utilisateur et le laisser... un certain temps).
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois
plus lent que le module au lancement, mais à l'exécution, alors que le
FastCGI qui est sensé réduire le temps de lancement permet en réalité
d'exploser les perfs en exécution... Cherchez l'erreur !
Exploser = amméliorer ?
Hum... votre config m'intéresse :) :)... bon nous on est sous Solaris
hein, mais on doit pouvoir jouer...
Ceci dit j'ai noté une énnorme différence de pref suivant qu'on prend un
php avec trois modules ou si on ajoute un peu tout (notamment tous les
modules attaquant divers types de bdd).
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai perdu le nom du module qui fait ça): à chaque invocation on rechargeait le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà une partie de l'explication pour ceux qui ne comprennent pas pourquoi on est 4 fois plus cher que les discounts)
J'ai retrouvé c'est suphp... hum... le fastCGI c'est le binaire qui reste chargé et on lui envoit les données si je me souviens bien ? Le pb est qu'on a 1300 utilisateurs potentiels de la chose, et il me semblait dans ce cas là qu'il fallait un php par uid. Ce qui n'est pas raisonnable (bon si on pouvait gérer un truc genre lancer le binaire pour un utilisateur et le laisser... un certain temps).
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois plus lent que le module au lancement, mais à l'exécution, alors que le FastCGI qui est sensé réduire le temps de lancement permet en réalité d'exploser les perfs en exécution... Cherchez l'erreur !
Exploser = amméliorer ? Hum... votre config m'intéresse :) :)... bon nous on est sous Solaris hein, mais on doit pouvoir jouer...
Ceci dit j'ai noté une énnorme différence de pref suivant qu'on prend un php avec trois modules ou si on ajoute un peu tout (notamment tous les modules attaquant divers types de bdd).
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
oles
"GPLHost (thomas)" a écrit:
De plus, j'aimerais qu'on me prouve qu'un SAN IBM en RAID5 relié en Gigabit donne des performances plus attractive qu'un simple accès en SATA2. A mon avis, on gagne par grand chose, spécialement si beaucoup de machine accède au meme disque dans le SAN.
Bonjour, Bonne Année ;)
Ce n'est pas difficile à prouver. L'avantage d'un SAN par rapport à un simple disque est le nombre d'IO par seconde. Tu peux faire énormement d'opérations sur les fichiers et le SAN bats un disque plusieurs fois. C'est notament très interessant lorsque tu as beaucoup de fichiers, genre les serveurs d'emails, beaucoup d'écriture, beaucoup de lectures, des rename, des moves etc. L'avantage de SAN diminue lorsque tu as beaucoup d'acceder aux peu et gros fichiers. Genre un serveur de VOD. Et on n'a parlé que des performances. Pour les preuves il suffit de parler avec ceux qui testent nos RPS et les comparents aux serveurs dédiés standard. En vitesse de pointe le disque bat un iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers iSCSI bat un disque.
Amicalement Octave
"GPLHost (thomas)" <thomas@goirand.nospam.fr> a écrit:
De plus, j'aimerais qu'on me prouve qu'un SAN IBM en RAID5 relié en
Gigabit donne des performances plus attractive qu'un simple accès en
SATA2. A mon avis, on gagne par grand chose, spécialement si beaucoup de
machine accède au meme disque dans le SAN.
Bonjour,
Bonne Année ;)
Ce n'est pas difficile à prouver. L'avantage d'un SAN par rapport
à un simple disque est le nombre d'IO par seconde. Tu peux faire
énormement d'opérations sur les fichiers et le SAN bats un disque
plusieurs fois. C'est notament très interessant lorsque tu as beaucoup
de fichiers, genre les serveurs d'emails, beaucoup d'écriture, beaucoup
de lectures, des rename, des moves etc. L'avantage de SAN diminue
lorsque tu as beaucoup d'acceder aux peu et gros fichiers. Genre un
serveur de VOD. Et on n'a parlé que des performances. Pour les preuves
il suffit de parler avec ceux qui testent nos RPS et les comparents
aux serveurs dédiés standard. En vitesse de pointe le disque bat un
iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers
iSCSI bat un disque.
De plus, j'aimerais qu'on me prouve qu'un SAN IBM en RAID5 relié en Gigabit donne des performances plus attractive qu'un simple accès en SATA2. A mon avis, on gagne par grand chose, spécialement si beaucoup de machine accède au meme disque dans le SAN.
Bonjour, Bonne Année ;)
Ce n'est pas difficile à prouver. L'avantage d'un SAN par rapport à un simple disque est le nombre d'IO par seconde. Tu peux faire énormement d'opérations sur les fichiers et le SAN bats un disque plusieurs fois. C'est notament très interessant lorsque tu as beaucoup de fichiers, genre les serveurs d'emails, beaucoup d'écriture, beaucoup de lectures, des rename, des moves etc. L'avantage de SAN diminue lorsque tu as beaucoup d'acceder aux peu et gros fichiers. Genre un serveur de VOD. Et on n'a parlé que des performances. Pour les preuves il suffit de parler avec ceux qui testent nos RPS et les comparents aux serveurs dédiés standard. En vitesse de pointe le disque bat un iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers iSCSI bat un disque.
Amicalement Octave
oles
Martin Lafaix a écrit:
On 2008-01-02, wrote:
En vitesse de pointe le disque bat un iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers iSCSI bat un disque.
Même lorsqu'il y a 10/100/1000/.... autres utilisateurs qui font la même chose, chacun sur « leur » disque ?
la question posée était: prouvez moi que le SAN est plus rapide que le disque dur. comme j'avais dit ça depend de besoins et de l'utilisation. il y a du pour et du contre. si la question est maintenant: comment se fait la mutualisation d'un SAN et comment se fait la garantie de performance sur un SAN, c'est une autre problematique à laquelle je n'ai pas toutes les reponses (une bonne partie je l'ai déjà mais pas toutes les reponses). C'est pourquoi on a lancé une beta. en gros, il faut qu'on teste avec des vrais clients les differents manieres de mutualisation de resources d'un SAN. En suite, je pourrai eventuellement repondre à cette question de maniere precise (enfin je prefere que nos clients repondent à notre place, c'est plus precis comme le feedback).
Martin Lafaix <lafaix@online.fr> a écrit:
On 2008-01-02, oles@ovh.net <oles@ovh.net> wrote:
En vitesse de pointe le disque bat un
iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers
iSCSI bat un disque.
Même lorsqu'il y a 10/100/1000/.... autres utilisateurs qui font la même
chose, chacun sur « leur » disque ?
la question posée était: prouvez moi que le SAN est plus rapide que
le disque dur. comme j'avais dit ça depend de besoins et de l'utilisation.
il y a du pour et du contre. si la question est maintenant: comment se
fait la mutualisation d'un SAN et comment se fait la garantie de
performance sur un SAN, c'est une autre problematique à laquelle je
n'ai pas toutes les reponses (une bonne partie je l'ai déjà mais pas
toutes les reponses). C'est pourquoi on a lancé une beta. en gros,
il faut qu'on teste avec des vrais clients les differents manieres
de mutualisation de resources d'un SAN. En suite, je pourrai eventuellement
repondre à cette question de maniere precise (enfin je prefere que
nos clients repondent à notre place, c'est plus precis comme le feedback).
En vitesse de pointe le disque bat un iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers iSCSI bat un disque.
Même lorsqu'il y a 10/100/1000/.... autres utilisateurs qui font la même chose, chacun sur « leur » disque ?
la question posée était: prouvez moi que le SAN est plus rapide que le disque dur. comme j'avais dit ça depend de besoins et de l'utilisation. il y a du pour et du contre. si la question est maintenant: comment se fait la mutualisation d'un SAN et comment se fait la garantie de performance sur un SAN, c'est une autre problematique à laquelle je n'ai pas toutes les reponses (une bonne partie je l'ai déjà mais pas toutes les reponses). C'est pourquoi on a lancé une beta. en gros, il faut qu'on teste avec des vrais clients les differents manieres de mutualisation de resources d'un SAN. En suite, je pourrai eventuellement repondre à cette question de maniere precise (enfin je prefere que nos clients repondent à notre place, c'est plus precis comme le feedback).
