Là aussi, c'est de la mauvaise fois. Comme si, par magie, tous les VPS décidait de bosser en même temps, rien que pour faire chier. Dans la vrai vie, tous les serveurs web qui tournent ne recoivent pas une requête à la même milliseconde, et au finale, un VPS sur un core2 quad à plus de peiche qu'un petit dédié sur un mauvais Celeron, en effet!!!
Sauf que l'expérience des hébergements mutualisés montre quand même des pics de fréquentation à certaines heures, par essence celles de grande affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de visiteurs, ben, la probabilité de retrouver le même comportement est grande. -- Martin Lafaix Team OS/2 http://lafaix.online.fr
On 2008-08-23, GPLHost (thomas) <thomas@goirand.nospam.fr> wrote:
Là aussi, c'est de la mauvaise fois. Comme si, par magie, tous les VPS
décidait de bosser en même temps, rien que pour faire chier. Dans la
vrai vie, tous les serveurs web qui tournent ne recoivent pas une
requête à la même milliseconde, et au finale, un VPS sur un core2 quad à
plus de peiche qu'un petit dédié sur un mauvais Celeron, en effet!!!
Sauf que l'expérience des hébergements mutualisés montre quand même des
pics de fréquentation à certaines heures, par essence celles de grande
affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de
visiteurs, ben, la probabilité de retrouver le même comportement est
grande.
--
Martin Lafaix <lafaix@online.fr>
Team OS/2
http://lafaix.online.fr
Là aussi, c'est de la mauvaise fois. Comme si, par magie, tous les VPS décidait de bosser en même temps, rien que pour faire chier. Dans la vrai vie, tous les serveurs web qui tournent ne recoivent pas une requête à la même milliseconde, et au finale, un VPS sur un core2 quad à plus de peiche qu'un petit dédié sur un mauvais Celeron, en effet!!!
Sauf que l'expérience des hébergements mutualisés montre quand même des pics de fréquentation à certaines heures, par essence celles de grande affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de visiteurs, ben, la probabilité de retrouver le même comportement est grande. -- Martin Lafaix Team OS/2 http://lafaix.online.fr
GPLHost (thomas)
Martin Lafaix wrote:
On 2008-08-23, GPLHost (thomas) wrote:
Là aussi, c'est de la mauvaise fois. Comme si, par magie, tous les VPS décidait de bosser en même temps, rien que pour faire chier. Dans la vrai vie, tous les serveurs web qui tournent ne recoivent pas une requête à la même milliseconde, et au finale, un VPS sur un core2 quad à plus de peiche qu'un petit dédié sur un mauvais Celeron, en effet!!!
Sauf que l'expérience des hébergements mutualisés montre quand même des pics de fréquentation à certaines heures, par essence celles de grande affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de visiteurs, ben, la probabilité de retrouver le même comportement est grande.
Comme dit dans d'autres posts, un mauvais hébergeur aura toujours des problèmes au moment des pics de fréquentation, et un bon fera en sorte qu'il y ai assez de ressources pour tous les clients. Ca tient d'ailleurs aussi pour de l'hébergement dédié ou la bande passante peut faire défaut (par exemple: il est très difficile de faire du ssh depuis la Chine aux heures de pointes sur une dedibox... (ou alors il faut aimer attendre 20 secondes entre chaques frappes sur le clavier)).
Thomas
Martin Lafaix wrote:
On 2008-08-23, GPLHost (thomas) <thomas@goirand.nospam.fr> wrote:
Là aussi, c'est de la mauvaise fois. Comme si, par magie, tous les VPS
décidait de bosser en même temps, rien que pour faire chier. Dans la
vrai vie, tous les serveurs web qui tournent ne recoivent pas une
requête à la même milliseconde, et au finale, un VPS sur un core2 quad à
plus de peiche qu'un petit dédié sur un mauvais Celeron, en effet!!!
Sauf que l'expérience des hébergements mutualisés montre quand même des
pics de fréquentation à certaines heures, par essence celles de grande
affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de
visiteurs, ben, la probabilité de retrouver le même comportement est
grande.
Comme dit dans d'autres posts, un mauvais hébergeur aura toujours des
problèmes au moment des pics de fréquentation, et un bon fera en sorte
qu'il y ai assez de ressources pour tous les clients. Ca tient
d'ailleurs aussi pour de l'hébergement dédié ou la bande passante peut
faire défaut (par exemple: il est très difficile de faire du ssh depuis
la Chine aux heures de pointes sur une dedibox... (ou alors il faut
aimer attendre 20 secondes entre chaques frappes sur le clavier)).
Là aussi, c'est de la mauvaise fois. Comme si, par magie, tous les VPS décidait de bosser en même temps, rien que pour faire chier. Dans la vrai vie, tous les serveurs web qui tournent ne recoivent pas une requête à la même milliseconde, et au finale, un VPS sur un core2 quad à plus de peiche qu'un petit dédié sur un mauvais Celeron, en effet!!!
Sauf que l'expérience des hébergements mutualisés montre quand même des pics de fréquentation à certaines heures, par essence celles de grande affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de visiteurs, ben, la probabilité de retrouver le même comportement est grande.
Comme dit dans d'autres posts, un mauvais hébergeur aura toujours des problèmes au moment des pics de fréquentation, et un bon fera en sorte qu'il y ai assez de ressources pour tous les clients. Ca tient d'ailleurs aussi pour de l'hébergement dédié ou la bande passante peut faire défaut (par exemple: il est très difficile de faire du ssh depuis la Chine aux heures de pointes sur une dedibox... (ou alors il faut aimer attendre 20 secondes entre chaques frappes sur le clavier)).
Thomas
Martin Lafaix
On 2008-08-26, GPLHost (thomas) wrote:
Sauf que l'expérience des hébergements mutualisés montre quand même des pics de fréquentation à certaines heures, par essence celles de grande affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de visiteurs, ben, la probabilité de retrouver le même comportement est grande.
Comme dit dans d'autres posts, un mauvais hébergeur aura toujours des problèmes au moment des pics de fréquentation, et un bon fera en sorte qu'il y ai assez de ressources pour tous les clients.
Il ne me semble pas avoir parlé de problèmes au moment des pics de fréquentation.
C'est juste qu'aux moments de ces pics, les machines sont plus chargées, et donc forcément plus lentes.
En d'autres termes, sur un hébergement mutualisé (et de fait donc sur un serveur virtuel) classique, les performances des applications / machines virtuelles dépendent de l'usage des autres applications / machines virtuelles hébergées sur la même plate-forme(*).
En théorie l'effet est acceptable (i.e., même lors d'un pic d'utilisation les performances restent correctes), mais c'est plus une promesse qu'autre chose. Parfois voire souvent tenue, mais pas toujours, quoi qu'en disent les zolies plaquettes des promotteurs de ces solutions.
Après, c'est à vous de voir si c'est acceptable pour vos besoins ou pas.
(*) certaines solutions permettent un partage « statique », i.e., en allouant des ressources fixes à chaque partie, auquel cas les performances restent les mêmes, mais ça veut aussi dire qu'en période creuse il n'y a *pas* de gain de performance, et que cela contredit quelque peu les arguments de la mutualisation telle que décrite dans les zolies plaquettes. -- Martin Lafaix Team OS/2 http://lafaix.online.fr
On 2008-08-26, GPLHost (thomas) <thomas@goirand.nospam.fr> wrote:
Sauf que l'expérience des hébergements mutualisés montre quand même des
pics de fréquentation à certaines heures, par essence celles de grande
affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de
visiteurs, ben, la probabilité de retrouver le même comportement est
grande.
Comme dit dans d'autres posts, un mauvais hébergeur aura toujours des
problèmes au moment des pics de fréquentation, et un bon fera en sorte
qu'il y ai assez de ressources pour tous les clients.
Il ne me semble pas avoir parlé de problèmes au moment des pics de
fréquentation.
C'est juste qu'aux moments de ces pics, les machines sont plus chargées,
et donc forcément plus lentes.
En d'autres termes, sur un hébergement mutualisé (et de fait donc sur un
serveur virtuel) classique, les performances des applications / machines
virtuelles dépendent de l'usage des autres applications / machines
virtuelles hébergées sur la même plate-forme(*).
En théorie l'effet est acceptable (i.e., même lors d'un pic
d'utilisation les performances restent correctes), mais c'est plus une
promesse qu'autre chose. Parfois voire souvent tenue, mais pas
toujours, quoi qu'en disent les zolies plaquettes des promotteurs de ces
solutions.
Après, c'est à vous de voir si c'est acceptable pour vos besoins ou pas.
(*) certaines solutions permettent un partage « statique », i.e., en
allouant des ressources fixes à chaque partie, auquel cas les
performances restent les mêmes, mais ça veut aussi dire qu'en période
creuse il n'y a *pas* de gain de performance, et que cela contredit
quelque peu les arguments de la mutualisation telle que décrite dans les
zolies plaquettes.
--
Martin Lafaix <lafaix@online.fr>
Team OS/2
http://lafaix.online.fr
Sauf que l'expérience des hébergements mutualisés montre quand même des pics de fréquentation à certaines heures, par essence celles de grande affluence des visiteurs.
Donc si ces serveurs virtualisés servent des sites à destination de visiteurs, ben, la probabilité de retrouver le même comportement est grande.
Comme dit dans d'autres posts, un mauvais hébergeur aura toujours des problèmes au moment des pics de fréquentation, et un bon fera en sorte qu'il y ai assez de ressources pour tous les clients.
Il ne me semble pas avoir parlé de problèmes au moment des pics de fréquentation.
C'est juste qu'aux moments de ces pics, les machines sont plus chargées, et donc forcément plus lentes.
En d'autres termes, sur un hébergement mutualisé (et de fait donc sur un serveur virtuel) classique, les performances des applications / machines virtuelles dépendent de l'usage des autres applications / machines virtuelles hébergées sur la même plate-forme(*).
En théorie l'effet est acceptable (i.e., même lors d'un pic d'utilisation les performances restent correctes), mais c'est plus une promesse qu'autre chose. Parfois voire souvent tenue, mais pas toujours, quoi qu'en disent les zolies plaquettes des promotteurs de ces solutions.
Après, c'est à vous de voir si c'est acceptable pour vos besoins ou pas.
(*) certaines solutions permettent un partage « statique », i.e., en allouant des ressources fixes à chaque partie, auquel cas les performances restent les mêmes, mais ça veut aussi dire qu'en période creuse il n'y a *pas* de gain de performance, et que cela contredit quelque peu les arguments de la mutualisation telle que décrite dans les zolies plaquettes. -- Martin Lafaix Team OS/2 http://lafaix.online.fr
Mikaël
Guénol wrote:
Le 17-08-2008, arnaud nous racontait :
On arrive aussi à des optimisations en terme d'espace, de consomation et de dégagement calorifique qui relègue assez loin derrière les solutions actuelle de serveurs dédiés (un petit serveur VDS, un petit pas pour la planête...).
espérons qu'Arnaud (de Dedibox) t'entende
Mouai, argument que j'entends parler depuis facile 7 ans, complètement dépassé de nos jours. Je n'y vois *aucun* intérêt, technique, financier ou facilité d'hébergement.
Ah si ! Passer d'un serveurs de faible puissance qui ne fait rien à un serveurs 8 fois plus performant en 1 click, lors d'une campagne de publicité ou du lancement d'un nouveau produit, ça c'est une facilité concrète pour le client final. Pouvoir ensuite rebasculer à une failbe poigné de part en mode de fonctionnement routinier, dimminuant le coup et sans devoir réinstaller, ça aussi ce sont des avantages financiers et une facilité d'hébergement concret.
La consommation électrique ? Es-ce que 10 serveurs qui consomment 35W vallent mieux qu'un gros serveur qui consomme 350W ?
Mais si l'on prend une autre comparaison, lorsque l'on a besoin d'un serveur à faible capacité juste pour héberger une page web et quelques mails, si l'on prend une part chez Gandi, on consommera moins qu'un serveur bas de gamme chez qui que ce soit.
La virtualisation n'est pour moi qu'un moyen facile (sans investissement, sans frais exorbitant de r&d et sans risques) de faire du "faux" serveur dédié pas cher, sans s'en donner les moyens.
Alors la dessus je serais plutôt d'un avis contraire :-) Certes, lorsque l'on prend en considération l'espace immense nécessaire pour 10.000 clients (donc 10.000 serveurs), l'investissement est de taille bien plus considérable que pour l'équivalent de 10.000 serveurs VPS.
Mais concernant le r&d, toute la partie logiciel de gestion derrière, création, basculement, augmentation des parts, etc est quand même loin d'être négligeable.
En réalité, si l'on se contente de faire de l'hébergement dédié de base, le r&d est quasi inexistant, mis à part un serveur d'installation que tout le monde fait partout et un panel de gestion, je crois que ça s'arrête à peu prêt là.
Pour le reste, ce n'est pas du faux serveur, c'est juste une offre différente pour un public différent.
Là ou une dedibox est adapté pour de l'hébergement massif de donnée et du téléchargement de ceux-ci (allez, je pense avant tout album photo ou autre), un hébergement VPS chez Gandi le sera pour quelqu'un ayant des besoins amené à grossir, ou désirant avoir une flotte de serveur retaillable à volonté etc.
-- Mikaël
Guénol wrote:
Le 17-08-2008, arnaud nous racontait :
On arrive aussi à des optimisations en terme d'espace, de consomation
et de dégagement calorifique qui relègue assez loin derrière les
solutions actuelle de serveurs dédiés (un petit serveur VDS, un petit
pas pour la planête...).
espérons qu'Arnaud (de Dedibox) t'entende
Mouai, argument que j'entends parler depuis facile 7 ans, complètement
dépassé de nos jours. Je n'y vois *aucun* intérêt, technique, financier
ou facilité d'hébergement.
Ah si !
Passer d'un serveurs de faible puissance qui ne fait rien à un serveurs 8
fois plus performant en 1 click, lors d'une campagne de publicité ou du
lancement d'un nouveau produit, ça c'est une facilité concrète pour le
client final. Pouvoir ensuite rebasculer à une failbe poigné de part en
mode de fonctionnement routinier, dimminuant le coup et sans devoir
réinstaller, ça aussi ce sont des avantages financiers et une facilité
d'hébergement concret.
La consommation électrique ? Es-ce que 10 serveurs qui consomment 35W
vallent mieux qu'un gros serveur qui consomme 350W ?
Mais si l'on prend une autre comparaison, lorsque l'on a besoin d'un serveur
à faible capacité juste pour héberger une page web et quelques mails, si
l'on prend une part chez Gandi, on consommera moins qu'un serveur bas de
gamme chez qui que ce soit.
La virtualisation n'est pour moi qu'un moyen facile (sans investissement,
sans frais exorbitant de r&d et sans risques) de faire du "faux" serveur
dédié pas cher, sans s'en donner les moyens.
Alors la dessus je serais plutôt d'un avis contraire :-)
Certes, lorsque l'on prend en considération l'espace immense nécessaire pour
10.000 clients (donc 10.000 serveurs), l'investissement est de taille bien
plus considérable que pour l'équivalent de 10.000 serveurs VPS.
Mais concernant le r&d, toute la partie logiciel de gestion derrière,
création, basculement, augmentation des parts, etc est quand même loin
d'être négligeable.
En réalité, si l'on se contente de faire de l'hébergement dédié de base, le
r&d est quasi inexistant, mis à part un serveur d'installation que tout le
monde fait partout et un panel de gestion, je crois que ça s'arrête à peu
prêt là.
Pour le reste, ce n'est pas du faux serveur, c'est juste une offre
différente pour un public différent.
Là ou une dedibox est adapté pour de l'hébergement massif de donnée et du
téléchargement de ceux-ci (allez, je pense avant tout album photo ou
autre), un hébergement VPS chez Gandi le sera pour quelqu'un ayant des
besoins amené à grossir, ou désirant avoir une flotte de serveur
retaillable à volonté etc.
On arrive aussi à des optimisations en terme d'espace, de consomation et de dégagement calorifique qui relègue assez loin derrière les solutions actuelle de serveurs dédiés (un petit serveur VDS, un petit pas pour la planête...).
espérons qu'Arnaud (de Dedibox) t'entende
Mouai, argument que j'entends parler depuis facile 7 ans, complètement dépassé de nos jours. Je n'y vois *aucun* intérêt, technique, financier ou facilité d'hébergement.
Ah si ! Passer d'un serveurs de faible puissance qui ne fait rien à un serveurs 8 fois plus performant en 1 click, lors d'une campagne de publicité ou du lancement d'un nouveau produit, ça c'est une facilité concrète pour le client final. Pouvoir ensuite rebasculer à une failbe poigné de part en mode de fonctionnement routinier, dimminuant le coup et sans devoir réinstaller, ça aussi ce sont des avantages financiers et une facilité d'hébergement concret.
La consommation électrique ? Es-ce que 10 serveurs qui consomment 35W vallent mieux qu'un gros serveur qui consomme 350W ?
Mais si l'on prend une autre comparaison, lorsque l'on a besoin d'un serveur à faible capacité juste pour héberger une page web et quelques mails, si l'on prend une part chez Gandi, on consommera moins qu'un serveur bas de gamme chez qui que ce soit.
La virtualisation n'est pour moi qu'un moyen facile (sans investissement, sans frais exorbitant de r&d et sans risques) de faire du "faux" serveur dédié pas cher, sans s'en donner les moyens.
Alors la dessus je serais plutôt d'un avis contraire :-) Certes, lorsque l'on prend en considération l'espace immense nécessaire pour 10.000 clients (donc 10.000 serveurs), l'investissement est de taille bien plus considérable que pour l'équivalent de 10.000 serveurs VPS.
Mais concernant le r&d, toute la partie logiciel de gestion derrière, création, basculement, augmentation des parts, etc est quand même loin d'être négligeable.
En réalité, si l'on se contente de faire de l'hébergement dédié de base, le r&d est quasi inexistant, mis à part un serveur d'installation que tout le monde fait partout et un panel de gestion, je crois que ça s'arrête à peu prêt là.
Pour le reste, ce n'est pas du faux serveur, c'est juste une offre différente pour un public différent.
Là ou une dedibox est adapté pour de l'hébergement massif de donnée et du téléchargement de ceux-ci (allez, je pense avant tout album photo ou autre), un hébergement VPS chez Gandi le sera pour quelqu'un ayant des besoins amené à grossir, ou désirant avoir une flotte de serveur retaillable à volonté etc.
-- Mikaël
oles
> Alors la dessus je serais plutôt d'un avis contraire :-) Certes, lorsque l'on prend en considération l'espace immense nécessaire pour 10.000 clients (donc 10.000 serveurs), l'investissement est de taille bien plus considérable que pour l'équivalent de 10.000 serveurs VPS.
la difference de puissance entre le CPU physique le moins puissant et le CPU (bi ou quand) le plus puissant ne permet pas une mutualisation de resources interessant pour proposer le VPS de qualité. en gros, c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai) le moins puissant que decouper un bi-quad car le bi-quad n'est pas si puissant que ça par rapport au CPU le moins puissant. puis le grain le plus faible est le process sur un serveur. Au final tu ne peux pas fournir moins de puissance qu'un core d'un serveur. Tu peux fournir plus, mais pas moins. Mutualiser un serveur pour X VPS est donc un jeu d'équilibre avec une limite atteinable facilement. Maintenant on peut imaginer composer plusieurs serveurs bi-quad pour faire un pseudo serveur sur lequel on va pouvoir lancer les VPS. le probleme de grain CPU reste le même. Et les pertes liés à la virtualisation de la pseudo machine sont énormes, sans parler de bugs. Puis moi je dis, plus c'est simple, mieux ça marche. Et quand on veut des solutions fiables il faut simplifier les choses au lieu de les complexifier. La virtualisation de quelques VPS c'est parfait. La virtualisation de masse c'est toutes les merdes de l'hébergement mutu avec toutes les merdes du serveur dédiés. Mais pour ceux qui aiment les defis c'est parfait comme projet. Je reste toujours admiratifs de ces admins là.
> Alors la dessus je serais plutôt d'un avis contraire :-)
Certes, lorsque l'on prend en considération l'espace immense nécessaire pour
10.000 clients (donc 10.000 serveurs), l'investissement est de taille bien
plus considérable que pour l'équivalent de 10.000 serveurs VPS.
la difference de puissance entre le CPU physique le moins puissant
et le CPU (bi ou quand) le plus puissant ne permet pas une mutualisation
de resources interessant pour proposer le VPS de qualité. en gros,
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai)
le moins puissant que decouper un bi-quad car le bi-quad n'est pas si
puissant que ça par rapport au CPU le moins puissant. puis le grain le
plus faible est le process sur un serveur. Au final tu ne peux pas fournir
moins de puissance qu'un core d'un serveur. Tu peux fournir plus, mais pas
moins. Mutualiser un serveur pour X VPS est donc un jeu d'équilibre avec
une limite atteinable facilement. Maintenant on peut imaginer composer
plusieurs serveurs bi-quad pour faire un pseudo serveur sur lequel on va
pouvoir lancer les VPS. le probleme de grain CPU reste le même. Et les pertes
liés à la virtualisation de la pseudo machine sont énormes, sans parler de
bugs. Puis moi je dis, plus c'est simple, mieux ça marche. Et quand on veut
des solutions fiables il faut simplifier les choses au lieu de les complexifier.
La virtualisation de quelques VPS c'est parfait. La virtualisation de masse
c'est toutes les merdes de l'hébergement mutu avec toutes les merdes du
serveur dédiés. Mais pour ceux qui aiment les defis c'est parfait comme
projet. Je reste toujours admiratifs de ces admins là.
> Alors la dessus je serais plutôt d'un avis contraire :-) Certes, lorsque l'on prend en considération l'espace immense nécessaire pour 10.000 clients (donc 10.000 serveurs), l'investissement est de taille bien plus considérable que pour l'équivalent de 10.000 serveurs VPS.
la difference de puissance entre le CPU physique le moins puissant et le CPU (bi ou quand) le plus puissant ne permet pas une mutualisation de resources interessant pour proposer le VPS de qualité. en gros, c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai) le moins puissant que decouper un bi-quad car le bi-quad n'est pas si puissant que ça par rapport au CPU le moins puissant. puis le grain le plus faible est le process sur un serveur. Au final tu ne peux pas fournir moins de puissance qu'un core d'un serveur. Tu peux fournir plus, mais pas moins. Mutualiser un serveur pour X VPS est donc un jeu d'équilibre avec une limite atteinable facilement. Maintenant on peut imaginer composer plusieurs serveurs bi-quad pour faire un pseudo serveur sur lequel on va pouvoir lancer les VPS. le probleme de grain CPU reste le même. Et les pertes liés à la virtualisation de la pseudo machine sont énormes, sans parler de bugs. Puis moi je dis, plus c'est simple, mieux ça marche. Et quand on veut des solutions fiables il faut simplifier les choses au lieu de les complexifier. La virtualisation de quelques VPS c'est parfait. La virtualisation de masse c'est toutes les merdes de l'hébergement mutu avec toutes les merdes du serveur dédiés. Mais pour ceux qui aiment les defis c'est parfait comme projet. Je reste toujours admiratifs de ces admins là.
Mickaël Wolff
Cornelia Schneider a écrit :
Cornelia, qui est en VPS parce que pas les moyens pour un dédié (oui, même pas pour un Kimsufi)
C'est moins chère de faire croire que tu auras des ressources machines en les mutualisant que de te les garantir.
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai) le moins puissant que decouper un bi-quad
Dans ce cas je me demande d'où provient alors la différence de tarif très notable entre les dédiés et les VPS.
Cornelia, qui est en VPS parce que pas les moyens pour un dédié (oui, même pas pour un Kimsufi)
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Music etc : www.bownbend.com GPG key ID 83FF7452
oles@ovh.net wrote in news:48b450ea$0$27507$426a34cc@news.free.fr:
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un
vrai) le moins puissant que decouper un bi-quad
Dans ce cas je me demande d'où provient alors la différence de tarif très
notable entre les dédiés et les VPS.
Cornelia, qui est en VPS parce que pas les moyens pour un dédié
(oui, même pas pour un Kimsufi)
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : www.sts67.org
Music etc : www.bownbend.com
GPG key ID 83FF7452
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai) le moins puissant que decouper un bi-quad
Dans ce cas je me demande d'où provient alors la différence de tarif très notable entre les dédiés et les VPS.
Cornelia, qui est en VPS parce que pas les moyens pour un dédié (oui, même pas pour un Kimsufi)
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Music etc : www.bownbend.com GPG key ID 83FF7452
Cornelia Schneider
=?ISO-8859-15?Q?Mickaël_Wolff?= wrote in news:48b45d34$0$3794$:
C'est moins chère de faire croire que tu auras des ressources machines en les mutualisant que de te les garantir.
Admettons, mais j'ai déja titillé mon VPS (chuis une vicieuse...), et il tient ses promesses. Au prix où je le paie, ça me va parfaitement à ce jour. Payer deux à cinq fois plus cher, même avec plus de ressources, j'peux pas, sorry.
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Music etc : www.bownbend.com GPG key ID 83FF7452
=?ISO-8859-15?Q?Mickaël_Wolff?= <mickael.wolff@laposte.net> wrote in
news:48b45d34$0$3794$426a74cc@news.free.fr:
C'est moins chère de faire croire que tu auras des ressources
machines en les mutualisant que de te les garantir.
Admettons, mais j'ai déja titillé mon VPS (chuis une vicieuse...), et il
tient ses promesses. Au prix où je le paie, ça me va parfaitement à ce
jour. Payer deux à cinq fois plus cher, même avec plus de ressources,
j'peux pas, sorry.
Cornelia
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : www.sts67.org
Music etc : www.bownbend.com
GPG key ID 83FF7452
=?ISO-8859-15?Q?Mickaël_Wolff?= wrote in news:48b45d34$0$3794$:
C'est moins chère de faire croire que tu auras des ressources machines en les mutualisant que de te les garantir.
Admettons, mais j'ai déja titillé mon VPS (chuis une vicieuse...), et il tient ses promesses. Au prix où je le paie, ça me va parfaitement à ce jour. Payer deux à cinq fois plus cher, même avec plus de ressources, j'peux pas, sorry.
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Music etc : www.bownbend.com GPG key ID 83FF7452
Aurelgadjo
Cornelia Schneider a écrit :
=?ISO-8859-15?Q?Mickaël_Wolff?= wrote in news:48b45d34$0$3794$:
C'est moins chère de faire croire que tu auras des ressources machines en les mutualisant que de te les garantir.
Admettons, mais j'ai déja titillé mon VPS (chuis une vicieuse...), et il tient ses promesses. Au prix où je le paie, ça me va parfaitement à ce jour. Payer deux à cinq fois plus cher, même avec plus de ressources, j'peux pas, sorry.
Cornelia
Ben voilà, parce que le minimum c'est un kimsufi, et que tu n'as pas besoin d'autant (ou ?). Mettre une machine plus vieille qu'un kimsufi ne serait p-e pas intéressant niveau performances (quoique ?). Tu as juste trouvé moins puissant (je pense) qu'un kimsufi, à un prix moindre, ce qui te correspond. Tu as regardé au niveau des RPS pour comparer ton rapport puissance/prix ?
Cornelia Schneider a écrit :
=?ISO-8859-15?Q?Mickaël_Wolff?= <mickael.wolff@laposte.net> wrote in
news:48b45d34$0$3794$426a74cc@news.free.fr:
C'est moins chère de faire croire que tu auras des ressources
machines en les mutualisant que de te les garantir.
Admettons, mais j'ai déja titillé mon VPS (chuis une vicieuse...), et il
tient ses promesses. Au prix où je le paie, ça me va parfaitement à ce
jour. Payer deux à cinq fois plus cher, même avec plus de ressources,
j'peux pas, sorry.
Cornelia
Ben voilà, parce que le minimum c'est un kimsufi, et que tu n'as pas
besoin d'autant (ou ?).
Mettre une machine plus vieille qu'un kimsufi ne serait p-e pas
intéressant niveau performances (quoique ?).
Tu as juste trouvé moins puissant (je pense) qu'un kimsufi, à un prix
moindre, ce qui te correspond.
Tu as regardé au niveau des RPS pour comparer ton rapport puissance/prix ?
=?ISO-8859-15?Q?Mickaël_Wolff?= wrote in news:48b45d34$0$3794$:
C'est moins chère de faire croire que tu auras des ressources machines en les mutualisant que de te les garantir.
Admettons, mais j'ai déja titillé mon VPS (chuis une vicieuse...), et il tient ses promesses. Au prix où je le paie, ça me va parfaitement à ce jour. Payer deux à cinq fois plus cher, même avec plus de ressources, j'peux pas, sorry.
Cornelia
Ben voilà, parce que le minimum c'est un kimsufi, et que tu n'as pas besoin d'autant (ou ?). Mettre une machine plus vieille qu'un kimsufi ne serait p-e pas intéressant niveau performances (quoique ?). Tu as juste trouvé moins puissant (je pense) qu'un kimsufi, à un prix moindre, ce qui te correspond. Tu as regardé au niveau des RPS pour comparer ton rapport puissance/prix ?
oles
Cornelia Schneider a écrit:
wrote in news:48b450ea$0$27507$:
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai) le moins puissant que decouper un bi-quad
Dans ce cas je me demande d'où provient alors la différence de tarif très notable entre les dédiés et les VPS.
j'inverserais la question: quel est la valeur ajouté de VPS ? on peut supporter que c'est l'administration du VPS dans la mesure où c'est du mutualisé et que le serveur de base a un driver quand mêmem.
concernant le cout, on ne peut rien faire sur le CPU, il faut proposer une puissance minimal, non decoupable et qui fait que le CPU total du serveur de base peut être rapidement à 100%. mais on peut être radin sur la RAM et le disque. le reseau de notre jour ce n'est pas un point de comparaison (enfin je pense).
Cornelia Schneider <cschneider@pccsxb.com> a écrit:
oles@ovh.net wrote in news:48b450ea$0$27507$426a34cc@news.free.fr:
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un
vrai) le moins puissant que decouper un bi-quad
Dans ce cas je me demande d'où provient alors la différence de tarif très
notable entre les dédiés et les VPS.
j'inverserais la question: quel est la valeur ajouté de VPS ? on peut
supporter que c'est l'administration du VPS dans la mesure où c'est
du mutualisé et que le serveur de base a un driver quand mêmem.
concernant le cout, on ne peut rien faire sur le CPU, il faut proposer
une puissance minimal, non decoupable et qui fait que le CPU total
du serveur de base peut être rapidement à 100%. mais on peut être
radin sur la RAM et le disque. le reseau de notre jour ce n'est pas
un point de comparaison (enfin je pense).
c'est plus simple, moins couteux et plus fiable de proposer le CPU (un vrai) le moins puissant que decouper un bi-quad
Dans ce cas je me demande d'où provient alors la différence de tarif très notable entre les dédiés et les VPS.
j'inverserais la question: quel est la valeur ajouté de VPS ? on peut supporter que c'est l'administration du VPS dans la mesure où c'est du mutualisé et que le serveur de base a un driver quand mêmem.
concernant le cout, on ne peut rien faire sur le CPU, il faut proposer une puissance minimal, non decoupable et qui fait que le CPU total du serveur de base peut être rapidement à 100%. mais on peut être radin sur la RAM et le disque. le reseau de notre jour ce n'est pas un point de comparaison (enfin je pense).
