les perfs de online.fr sont catastrophiques!
voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s
- chez free.fr : ~0.0204s
- chez ovh: ~0.0070s
pour infos :
j'ai testé 2 types d'include
- inclusion depuis www/include (include_path de php.ini est
renseigné chez online.fr et le safe_mode est activé)
- inclusion relative et absolue depuis une autre répertoire
Avant de changer d'hebergement, j'aimerais connaître votre retour
d'experience avec eux, vos recours pour les faire bouger, qui contacter
à part leur mail de support...
Payez un service soit-disant "professionnel" (non remboursable selon
eux) pour ce genre de perf, c'est du vol...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas
ce n'est pas nouveau, depuis 4 ans c'est la même chose....
"poofpoof" a écrit dans le message de news: 414be7a2$0$2383$
Hello,
les perfs de online.fr sont catastrophiques! voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s - chez free.fr : ~0.0204s - chez ovh: ~0.0070s
pour infos : j'ai testé 2 types d'include - inclusion depuis www/include (include_path de php.ini est renseigné chez online.fr et le safe_mode est activé) - inclusion relative et absolue depuis une autre répertoire
Avant de changer d'hebergement, j'aimerais connaître votre retour d'experience avec eux, vos recours pour les faire bouger, qui contacter à part leur mail de support...
Payez un service soit-disant "professionnel" (non remboursable selon eux) pour ce genre de perf, c'est du vol...
merci pour vos réponses.
ce n'est pas nouveau, depuis 4 ans c'est la même chose....
"poofpoof" <poofpoof@free.fr> a écrit dans le message de news:
414be7a2$0$2383$626a14ce@news.free.fr...
Hello,
les perfs de online.fr sont catastrophiques!
voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s
- chez free.fr : ~0.0204s
- chez ovh: ~0.0070s
pour infos :
j'ai testé 2 types d'include
- inclusion depuis www/include (include_path de php.ini est
renseigné chez online.fr et le safe_mode est activé)
- inclusion relative et absolue depuis une autre répertoire
Avant de changer d'hebergement, j'aimerais connaître votre retour
d'experience avec eux, vos recours pour les faire bouger, qui contacter
à part leur mail de support...
Payez un service soit-disant "professionnel" (non remboursable selon
eux) pour ce genre de perf, c'est du vol...
ce n'est pas nouveau, depuis 4 ans c'est la même chose....
"poofpoof" a écrit dans le message de news: 414be7a2$0$2383$
Hello,
les perfs de online.fr sont catastrophiques! voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s - chez free.fr : ~0.0204s - chez ovh: ~0.0070s
pour infos : j'ai testé 2 types d'include - inclusion depuis www/include (include_path de php.ini est renseigné chez online.fr et le safe_mode est activé) - inclusion relative et absolue depuis une autre répertoire
Avant de changer d'hebergement, j'aimerais connaître votre retour d'experience avec eux, vos recours pour les faire bouger, qui contacter à part leur mail de support...
Payez un service soit-disant "professionnel" (non remboursable selon eux) pour ce genre de perf, c'est du vol...
merci pour vos réponses.
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, poofpoof ecrivait (wrote) :
Bonjour,
les perfs de online.fr sont catastrophiques! voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s - chez free.fr : ~0.0204s - chez ovh: ~0.0070s
Sans répondre sur le fond (est-ce que tel hébergeur est meilleur que tel autre), les temps de réponse ne dépendent pas que de l'hébergeur, mais aussi de la route entre le lieu où on procède aux tests et celui où est situé le serveur.
En gros, la vitesse maximum est celle du point de passage le plus lent entre le client et le serveur. On voit ça assez bien en faisant un traceroute entre les deux, et si possible plusieurs depuis plusieurs points « clients » utilisant des réseaux différents (un chez Wanadoo, un autre chez Nerim, un troisième chez 9Telecom par exemple).
En d'autres termes, les temps de réponse sont aussi affaire de transit IP et d'accords de peerings conclus entre hébergeurs et opérateurs de télécoms.
Imaginons un abonné AOL à Marseille. S'il envoie une requête à un serveur hébergé à Paris, sa requête passera obligatoirement (sauf évolutions récentes) par le coeur du réseau AOL situé aux Etats-Unis. De même, la réponse du serveur devra traverser deux fois l'océan atlantique et une bonne partie du territoire des Etats-Unis avant de lui revenir.
Donc même si l'hébergeur propose un service de haute qualité et dispose d'une bande passante conséquente, la route sera longue entre lui et le client qui l'interroge. Si en plus les opérateurs de transit utilisés par l'hébergeur n'ont pas d'accord d'interconnexion avec ceux d'AOL, la route s'en trouvera encore rallongée jusqu'à trouver un opérateur commun proposant un point d'interconnexion entre les deux réseaux.
Je me rappelle d'un exemple concret ou une entreprise devait établir un lien entre Paris et Delhi en Inde. En passant par France-Telecom, la liaison transitait par les USA, l'Australie et le Japon avant de parvenir à destination. En passant par British Telecom, elle passait par Londres qui disposait d'un lien direct avec Delhi. Les temps de réponse étaient divisés par 10...
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, poofpoof <poofpoof@free.fr>
ecrivait (wrote) :
Bonjour,
les perfs de online.fr sont catastrophiques!
voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s
- chez free.fr : ~0.0204s
- chez ovh: ~0.0070s
Sans répondre sur le fond (est-ce que tel hébergeur est meilleur que tel
autre), les temps de réponse ne dépendent pas que de l'hébergeur, mais
aussi de la route entre le lieu où on procède aux tests et celui où est
situé le serveur.
En gros, la vitesse maximum est celle du point de passage le plus lent
entre le client et le serveur. On voit ça assez bien en faisant un
traceroute entre les deux, et si possible plusieurs depuis plusieurs
points « clients » utilisant des réseaux différents (un chez Wanadoo, un
autre chez Nerim, un troisième chez 9Telecom par exemple).
En d'autres termes, les temps de réponse sont aussi affaire de transit
IP et d'accords de peerings conclus entre hébergeurs et opérateurs de
télécoms.
Imaginons un abonné AOL à Marseille. S'il envoie une requête à un
serveur hébergé à Paris, sa requête passera obligatoirement (sauf
évolutions récentes) par le coeur du réseau AOL situé aux Etats-Unis. De
même, la réponse du serveur devra traverser deux fois l'océan atlantique
et une bonne partie du territoire des Etats-Unis avant de lui revenir.
Donc même si l'hébergeur propose un service de haute qualité et dispose
d'une bande passante conséquente, la route sera longue entre lui et le
client qui l'interroge. Si en plus les opérateurs de transit utilisés
par l'hébergeur n'ont pas d'accord d'interconnexion avec ceux d'AOL, la
route s'en trouvera encore rallongée jusqu'à trouver un opérateur commun
proposant un point d'interconnexion entre les deux réseaux.
Je me rappelle d'un exemple concret ou une entreprise devait établir un
lien entre Paris et Delhi en Inde. En passant par France-Telecom, la
liaison transitait par les USA, l'Australie et le Japon avant de
parvenir à destination. En passant par British Telecom, elle passait par
Londres qui disposait d'un lien direct avec Delhi. Les temps de réponse
étaient divisés par 10...
dans (in) fr.reseaux.internet.hebergement, poofpoof ecrivait (wrote) :
Bonjour,
les perfs de online.fr sont catastrophiques! voici une comparaison sur 3 serveurs:
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s - chez free.fr : ~0.0204s - chez ovh: ~0.0070s
Sans répondre sur le fond (est-ce que tel hébergeur est meilleur que tel autre), les temps de réponse ne dépendent pas que de l'hébergeur, mais aussi de la route entre le lieu où on procède aux tests et celui où est situé le serveur.
En gros, la vitesse maximum est celle du point de passage le plus lent entre le client et le serveur. On voit ça assez bien en faisant un traceroute entre les deux, et si possible plusieurs depuis plusieurs points « clients » utilisant des réseaux différents (un chez Wanadoo, un autre chez Nerim, un troisième chez 9Telecom par exemple).
En d'autres termes, les temps de réponse sont aussi affaire de transit IP et d'accords de peerings conclus entre hébergeurs et opérateurs de télécoms.
Imaginons un abonné AOL à Marseille. S'il envoie une requête à un serveur hébergé à Paris, sa requête passera obligatoirement (sauf évolutions récentes) par le coeur du réseau AOL situé aux Etats-Unis. De même, la réponse du serveur devra traverser deux fois l'océan atlantique et une bonne partie du territoire des Etats-Unis avant de lui revenir.
Donc même si l'hébergeur propose un service de haute qualité et dispose d'une bande passante conséquente, la route sera longue entre lui et le client qui l'interroge. Si en plus les opérateurs de transit utilisés par l'hébergeur n'ont pas d'accord d'interconnexion avec ceux d'AOL, la route s'en trouvera encore rallongée jusqu'à trouver un opérateur commun proposant un point d'interconnexion entre les deux réseaux.
Je me rappelle d'un exemple concret ou une entreprise devait établir un lien entre Paris et Delhi en Inde. En passant par France-Telecom, la liaison transitait par les USA, l'Australie et le Japon avant de parvenir à destination. En passant par British Telecom, elle passait par Londres qui disposait d'un lien direct avec Delhi. Les temps de réponse étaient divisés par 10...
-- Eric Demeester - http://www.galacsys.net
Gilles Pion
Ref: de Eric Demeester <eric+
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s - chez free.fr : ~0.0204s - chez ovh: ~0.0070s
Sans répondre sur le fond (est-ce que tel hébergeur est meilleur que tel autre), les temps de réponse ne dépendent pas que de l'hébergeur, mais aussi de la route entre le lieu où on procède aux tests et celui où est situé le serveur.
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php s'exécute, je ne vois pas de quelle manière la liaison entre le client et le serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le script php lui-mème!
Pour info, je suis client Online depuis plus d'un an maintenant et je dois avouer que j'ai aussi constaté que ça rame quasiment en permanence (mais sans d'éléments de comparaison objectifs cependant). Je reste chez eux un peu par flemme, et surtout parce que le seul site php que j'ai la-bas n'est pas de la plus haute importance mais je me pose des questions.
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient gratuitement d'un serveur dédié! -- Gilles
Ref: <kj3rk0d68irijbjg7agd94tfqr5ahgmtkg@4ax.com> de Eric Demeester
<eric+usenet@galacsys.net>
test de 100 include_once sur plusieurs jours:
- chez online.fr : ~2.2s
- chez free.fr : ~0.0204s
- chez ovh: ~0.0070s
Sans répondre sur le fond (est-ce que tel hébergeur est meilleur que tel
autre), les temps de réponse ne dépendent pas que de l'hébergeur, mais
aussi de la route entre le lieu où on procède aux tests et celui où est
situé le serveur.
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php
s'exécute, je ne vois pas de quelle manière la liaison entre le client et le
serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le
script php lui-mème!
Pour info, je suis client Online depuis plus d'un an maintenant et je dois
avouer que j'ai aussi constaté que ça rame quasiment en permanence (mais sans
d'éléments de comparaison objectifs cependant). Je reste chez eux un peu par
flemme, et surtout parce que le seul site php que j'ai la-bas n'est pas de la
plus haute importance mais je me pose des questions.
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que
cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque
c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient
gratuitement d'un serveur dédié!
--
Gilles
- chez online.fr : ~2.2s - chez free.fr : ~0.0204s - chez ovh: ~0.0070s
Sans répondre sur le fond (est-ce que tel hébergeur est meilleur que tel autre), les temps de réponse ne dépendent pas que de l'hébergeur, mais aussi de la route entre le lieu où on procède aux tests et celui où est situé le serveur.
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php s'exécute, je ne vois pas de quelle manière la liaison entre le client et le serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le script php lui-mème!
Pour info, je suis client Online depuis plus d'un an maintenant et je dois avouer que j'ai aussi constaté que ça rame quasiment en permanence (mais sans d'éléments de comparaison objectifs cependant). Je reste chez eux un peu par flemme, et surtout parce que le seul site php que j'ai la-bas n'est pas de la plus haute importance mais je me pose des questions.
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient gratuitement d'un serveur dédié! -- Gilles
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, Gilles Pion ecrivait (wrote) :
Bonsoir Gilles,
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php s'exécute, je ne vois pas de quelle manière la liaison entre le client et le serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le script php lui-mème!
Oups, désolé, tu as probablement raison sur ce point. Je ne suis pas technicien alors il m'arrive de dire des bétises :(
J'espère néanmoins que le reste de ma démonstration est perninent...
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, Gilles Pion
<nosuchuser@nosuchdomain.com> ecrivait (wrote) :
Bonsoir Gilles,
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php
s'exécute, je ne vois pas de quelle manière la liaison entre le client et le
serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le
script php lui-mème!
Oups, désolé, tu as probablement raison sur ce point. Je ne suis pas
technicien alors il m'arrive de dire des bétises :(
J'espère néanmoins que le reste de ma démonstration est perninent...
dans (in) fr.reseaux.internet.hebergement, Gilles Pion ecrivait (wrote) :
Bonsoir Gilles,
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php s'exécute, je ne vois pas de quelle manière la liaison entre le client et le serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le script php lui-mème!
Oups, désolé, tu as probablement raison sur ce point. Je ne suis pas technicien alors il m'arrive de dire des bétises :(
J'espère néanmoins que le reste de ma démonstration est perninent...
-- Eric Demeester - http://www.galacsys.net
poofpoof
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php s'exécute, je ne vois pas de quelle manière la liaison entre le client et le serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le script php lui-mème!
exactement
Pour info, je suis client Online depuis plus d'un an maintenant et je dois avouer que j'ai aussi constaté que ça rame quasiment en permanence (mais sans d'éléments de comparaison objectifs cependant). Je reste chez eux un peu par flemme, et surtout parce que le seul site php que j'ai la-bas n'est pas de la plus haute importance mais je me pose des questions.
Même expérience, j'avais deux sites qui ne demandaient pas de ressource machine. Mais là j'ai une grosse appli. Et les perfs sont ridicules. Online.fr doit-il garantir un niveau de perf minimum??
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient gratuitement d'un serveur dédié!
Exact, j'ai eu le même genre de réponse...Et le problème ne se résoud pas...Que faire sinon changer d'hebergeur?
Merci pour vos retours d'expérience...
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php
s'exécute, je ne vois pas de quelle manière la liaison entre le client et le
serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le
script php lui-mème!
exactement
Pour info, je suis client Online depuis plus d'un an maintenant et je dois
avouer que j'ai aussi constaté que ça rame quasiment en permanence (mais sans
d'éléments de comparaison objectifs cependant). Je reste chez eux un peu par
flemme, et surtout parce que le seul site php que j'ai la-bas n'est pas de la
plus haute importance mais je me pose des questions.
Même expérience, j'avais deux sites qui ne demandaient pas de ressource
machine. Mais là j'ai une grosse appli. Et les perfs sont ridicules.
Online.fr doit-il garantir un niveau de perf minimum??
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que
cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque
c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient
gratuitement d'un serveur dédié!
Exact, j'ai eu le même genre de réponse...Et le problème ne se résoud
pas...Que faire sinon changer d'hebergeur?
Allô??? "include_once" ne fait intervenir *que* le serveur où le script php s'exécute, je ne vois pas de quelle manière la liaison entre le client et le serveur peut avoir le "*moindre* impact sur le temps d'exécution mesuré par le script php lui-mème!
exactement
Pour info, je suis client Online depuis plus d'un an maintenant et je dois avouer que j'ai aussi constaté que ça rame quasiment en permanence (mais sans d'éléments de comparaison objectifs cependant). Je reste chez eux un peu par flemme, et surtout parce que le seul site php que j'ai la-bas n'est pas de la plus haute importance mais je me pose des questions.
Même expérience, j'avais deux sites qui ne demandaient pas de ressource machine. Mais là j'ai une grosse appli. Et les perfs sont ridicules. Online.fr doit-il garantir un niveau de perf minimum??
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient gratuitement d'un serveur dédié!
Exact, j'ai eu le même genre de réponse...Et le problème ne se résoud pas...Que faire sinon changer d'hebergeur?
Merci pour vos retours d'expérience...
Francois Garnier
poofpoof à écrit:
Même expérience, j'avais deux sites qui ne demandaient pas de ressource machine. Mais là j'ai une grosse appli. Et les perfs sont ridicules. Online.fr doit-il garantir un niveau de perf minimum??
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient gratuitement d'un serveur dédié!
Exact, j'ai eu le même genre de réponse...Et le problème ne se résoud pas...Que faire sinon changer d'hebergeur?
Merci pour vos retours d'expérience...
Tout pareil ! Donc je suis passé chez OVH (60GP mutualisé) et, c'est magique !, tout fonctionne normalement... Online ne veut pas que ses clients fasse tourner des applis en PHP, c'est la seule explication possible.
-- François Garnier ___________________ Pour répondre : supprimez la mention STOPSPAM de l'adresse email.
poofpoof à écrit:
Même expérience, j'avais deux sites qui ne demandaient pas de ressource
machine. Mais là j'ai une grosse appli. Et les perfs sont ridicules.
Online.fr doit-il garantir un niveau de perf minimum??
Quand on se plaint sur leur forum de support (en faisant gentiment
remarquer que cela marche mieux chez Free) la réponse type est qu'il faut
faire avec, puisque c'est du mutualisé: je ne savais pas que les clients
Free bénéficiaient gratuitement d'un serveur dédié!
Exact, j'ai eu le même genre de réponse...Et le problème ne se résoud
pas...Que faire sinon changer d'hebergeur?
Merci pour vos retours d'expérience...
Tout pareil !
Donc je suis passé chez OVH (60GP mutualisé) et, c'est magique !, tout
fonctionne normalement...
Online ne veut pas que ses clients fasse tourner des applis en PHP, c'est la
seule explication possible.
--
François Garnier
___________________
Pour répondre : supprimez la mention STOPSPAM de l'adresse email.
Même expérience, j'avais deux sites qui ne demandaient pas de ressource machine. Mais là j'ai une grosse appli. Et les perfs sont ridicules. Online.fr doit-il garantir un niveau de perf minimum??
Quand on se plaint sur leur forum de support (en faisant gentiment remarquer que cela marche mieux chez Free) la réponse type est qu'il faut faire avec, puisque c'est du mutualisé: je ne savais pas que les clients Free bénéficiaient gratuitement d'un serveur dédié!
Exact, j'ai eu le même genre de réponse...Et le problème ne se résoud pas...Que faire sinon changer d'hebergeur?
Merci pour vos retours d'expérience...
Tout pareil ! Donc je suis passé chez OVH (60GP mutualisé) et, c'est magique !, tout fonctionne normalement... Online ne veut pas que ses clients fasse tourner des applis en PHP, c'est la seule explication possible.
-- François Garnier ___________________ Pour répondre : supprimez la mention STOPSPAM de l'adresse email.
