Lenteur des requêtes SQL chez OVH

WRInaute accro
Bonjour,

J'aimerais avoir un avis là dessus :

Depuis quelques jours, les serveurs sql d'OVH sont très lents. Du moins chez moi. Est-ce la même chose pour ceux qui sont hébergés sur OVH.
La plupart de mes pages font des appels à la base sql et le chargement se fait lentement. Du coup, je dois perdre pas mal de visites.:?

Pensez-vous que le passage du 240Pan au 720Pan va changer quelque chose ?
Je ne crois pas... les serveurs sql seront les mêmes :roll:
 
Nouveau WRInaute
Demande une explication à OVH. Si elle ne te paraît pas convainquante, change d'hébergeur : Rester chez le même serait être stupide, car un hébergeant qui surcharge ses serveurs (ou sous-dimensionne ceux-ci) le fera pour une bonne part de ses services, si ce n'est tous.

Il faut sortir du mythe de la "fidélité". Il n'y a pas de fidélité à avoir envers un commerçant : Il convient, on reste ; il ne convient plus, on part. Point.



Nota : 13h28, heure française. Ton site s'est affiché instantanément (bon, j'ai du 1024, faut dire). Ton moteur de recherche a répondu instantanément à la requête "Mexico".
 
Nouveau WRInaute
Moi aussi je suis chez OVH, et ça fait quelques temps que je ne suis plus satisfait par leurs "services".
Lenteur de calcul des pages, problèmes sérieux de stats URCHIN, soucis dans les envois de mails, etc.
J'ai aussi un 240 plan.
 
WRInaute accro
le souci d envoi de mail ou de contenu formulaire en php, je connais aussi...! j ai un peu "gueulé", ca a´été résolu aussitot et depuis, plus de probleme. mais c est vrai que c est chiant de devoir "tester" regulierement pour voir si ca fonctionne toujours....
 
WRInaute discret
Salut a tous :wink:

Je me demander si il existe des logiciels qui permete de tester automatiquement par exemple toutes les heures si le site s'affiche rapidement ?
 
WRInaute accro
Purée... qu'est-ce que ça traine... je vais essayer de voir du côté du support technique pour voir ce qu'il se passe :roll:

Et je ne suis même pas sûr que ce soit les requêtes sql car les pages qui n'en contiennent pas rament aussi.

Ce doit être un bouffeur de ressource hébergé sur le même disque dur... je ne vois que ça :roll:
 
WRInaute accro
Bon... je crois qu'il ne faut pas aller chercher plus loin... c'est chez France Telecom que ça déconne... Ne tirez plus sur OVH :lol:

Salut,
La connexion vers France Telecom n'est pas très stable depuis
debut de la semaine. Apparament ils ont des problèmes sur les
équipements de routage au niveau des ports 10Gbs. Ils se
pourraient qu'ils changent une carte 10Gbs cette nuit.

Enfin, c'est un problème interne à FT mais avec un incident
direct que la qualité de connexion vers les sites hébergés
chez Ovh et pas seulement.

Amicalement
Octave
 
WRInaute passionné
Extrait de la mailing-list d'OVH:

Salut,
Comme annoncé sur la page d'histoire des travaux, nous
avons eu hier des gros problèmes de ralentissements au
niveau du mutualisé. Nous avons en effet ajouté des
nouvelles machines pour faire face à l'augmentation de
charge et ceci a provoqué des problèmes reseau interne
(que nous avons déjà eu). Nous avons reçu hier aussi
les pieces en commande pour resoudre ce problème. Et
donc aujourd'hui matin et toute l'après midi nous avons
procédé aux maintenances sur les machines et le reseau.
Nous avons corrigé 72 machines aujourd'hui et il nous
reste encore 67 machines à corriger mais tout refonctionne
déjà correctement. Demain et Lundi nous allons finir
le reste des machines et on devrait retrouver des très
bonnes performances. Ces maintenances vont fixer
définitivement ces problèmes de bruit reseau (qui bloque
toute la communication entre les machines).

Bon wk

Amicalement
Octave
 
WRInaute discret
Salut à tous,

Perso j'ai un serveur dédié chez eux, et il rame, vu que j'ai trop de monde :) Donc pas de leur faute non plus ;)
Et côté requête SQL, faut pas oublier d'optimiser vos requêtes ;) Après on dit que c'est la faute d'OVH, mais y'en a combien qui optimisent leurs requêtes ? Moi je dois faire partie d'une poignée de gars qui le font, pour éviter de devoir prendre un 2e serveur dédié, mais c'est sûr qu'en 240 on peut se plaindre très fort, alors que le pb n'est pas forcément où on le pense ;) Voilà, soit dit en passant, j'attends ma 2e bécane !!! C'est quand qu'elle arrive ? (Sont lents chez OVH :p)
 
WRInaute discret
Contre 5% de tes ventes on peut s'arranger :) Tout dépend de ton trafic ;) Mais faut savoir que c'est plus craignos qu'un 240... Vu que je fais tout moi-même. Ca me coûte 106€/mois (TTC), enfin le double dans pas longtemps.
J'héberge gratuitement un pote et son site (enfin mon site, vu que j'en ai fait 95% ;)), mais ça c'est tout différent (vu qu'il doit consommer moins de 5% des ressources serveur !).
 
WRInaute discret
Sache qu'avoir son dédié c'est bien (tu peux très bien commencer par le Superplan tout court, à 82€TTC/mois), mais forcément, vu que tu es plus libre, tu as forcément plus de contraintes : les attaques sont pour ta pomme, la config du serveur Apache (nb de connexions simultanées etc...) idem, MySQL ça va encore y'a presque rien.
Mais c'est vrai que si t'as besoin d'un sous-domaine, tu te le fais en 5 min, il est actif en 1h, si il te manque un plug-in PHP, tu l'ajoutes (perso j'ai mes propres compilations de PHP, au moins je n'ai que l'essentiel, idem pour Apache/MySQL).
Je me suis installé aussi TMDA (un anti spam qui fonctionne en envoyant un message de confirmation auto à la personne qui t'écrit pour la première fois, et qui en renvoyant le message auto s'inscrit dans une white list (et non une blacklist)), c'est bien sympa comme truc :)
De même tu peux héberger autant de domaines que tu le souhaites, c'est la magie :)
Un seul truc par contre : ne pas acheter le serveur. C'est ce que je préconise (sachant que si tu l'achètes, il est rentabilisé au bout de 2 ans), parce que si tu le loues tu as la garantie Hardware à vie (donc si un disque tombe en rade, c'est pour eux, et non pour toi). Enfin là encore il faut bien faire le calcul... Si tu as besoin d'infos, je serai ravi de t'aider :)
 
WRInaute passionné
Yvan a dit:
Un seul truc par contre : ne pas acheter le serveur. C'est ce que je préconise (sachant que si tu l'achètes, il est rentabilisé au bout de 2 ans), parce que si tu le loues tu as la garantie Hardware à vie (donc si un disque tombe en rade, c'est pour eux, et non pour toi). Enfin là encore il faut bien faire le calcul... Si tu as besoin d'infos, je serai ravi de t'aider :)

Si je ne m'abuse, ils ne proposent plus d'acheter un dédié.

aK, qui n'ose pas encore beaucoup chipoter à son dédié de peur de casser le jouet ;-)
 
WRInaute impliqué
Yvan a dit:
Ca me coûte 106€/mois (TTC), enfin le double dans pas longtemps.

Ovh, je les trouve un peu nul au niveau de la ram...

106 euros ttc pour avoir 256mo et une bande passante limitée...

Surtout que 256mo, faut pas avoir beaucoup de trafic pour vite en atteindre les limites !
 
WRInaute discret
aK : t'as un dédié ? SInon je ne savais pas qu'ils ne les vendaient plus...

Kali : je suis ok sur le fait que leur première offre n'a que 128 de RAM, c'est abusé. De là à ce que ce soit un vrai inconvénient, j'en doute fort. Perso je tournais y'a 3 mois avec 128, j'avais aucun souci. Et 7 à 8000 personnes par jours (donc environ 700 000 hits). Je suis passé à 256 en croyais que c'était mon souci, mais maintenant je m'aperçois que le vrai problème c'est le CPU désormais (j'ai qu'un 1.7GHz), car le PHP consomme énormément. Donc je dois limiter à 35 connexions simultanées pour éviter que le serveur tombe, à cause du manque de CPU, et non du manque de RAM. Il faut bien faire la différence :
- site HTML > besoin d'un max de RAM car y'a beaucoup de connexions, et peu de CPU nécessaire.
- site PHP > si les scripts sont optimisés (les miens font entre 100 et 500 ms de création, avec système de cache etc...), ça peut encore aller quand y'a pas beaucoup de peuple. Mais le CPU prend très vite très cher, car PHP consomme infiniment fois plus qu'une bonne vieille requête sur une image/page HTML simple. Donc là c'st le CPU qui prime, et non la RAM (même si y'en a tjs besoin, notamment pour la conso des scripts en plus d'Apache).

106 euros ttc pour avoir 256mo et une bande passante limitée...
Faudra que tu m'expliques quel hébergeur ne limite pas la bande passante ! Dans ce cas je cours chez eux (et tout le monde avec). Il faut bien faire une différence en bande passante limitée et bande passante garantie... Limitée > tu es limité comme avec l'ADSL à 1024Kb par exemple, et il se peut que tu n'aies rien parce que ceci ou cela. Garantie > tu es sûr de l'avoir quel que soit les conditions du réseau ! Sans compter un petit burst à 10Mb/s pour 32Mo/mois (donc on peut dépasser le 1024Kb/s pour monter à 10Mb/s et ce pour 32Mo de données maximum, je l'ai testé, ça calme :)).

Donc 256Mo, c'est 10 fois trop pour 3000 personnes/jour si on configure bien son serveur Apache ! Quand je vois des MaxClients réglés à 256 (donc 256 connexions en simultané), c'est de la pure idiotie ! Là forcément vous allez prendre très cher lorsqu'un gars va passer avec son aspirateur de site, la RAM va tomber à 0, le swap va se mettre en branle, et aurevoir le serveur (même le SSH ne répond plus dans ce cas). Vous pourrez noter que mon site rame tous les soirs en ce moment, tout simplement parce que j'ai 10 000personnes/jour, 1 million de requêtes/jour, et que PHP consomme un max de CPU... Et côté RAM, tout va bien, je pourrais même enlever ma barrette de 128 à 20€HT/mois... Ne mélangeons pas tout, merci...
 
WRInaute passionné
Yvan a dit:
aK : t'as un dédié ? SInon je ne savais pas qu'ils ne les vendaient plus...

Oui, j'ai un dédié chez OVH (superplan), qui comporte mon plus gros site qui ne tenait plus sur 720plan. Mais le site de ma signature n'y est pas encore, vu que ce n'est pas encore indispensable (j'ai encore 6 mois loués sur mon 60gp) et que je dois adapter ce site à un serveur avec variables globales à "off".

aK.
 
WRInaute discret
aK : pour les variables globales "Off" (ainsi que les register_globals à "Off"), rien ne t'empêche dans un premier temps de les mettre à On, puis ensuite de les repasser à Off une fois que tout va bien. D'autant que c'ets un dédié, donc tu fais ce que tu veux (enfin n'abuse pas non plus, je me suis retrouvé après moultes magouilles d'installation de packages sans pouvoir accéder au serveur en SSH... avec un telnet pourri j'ai pu remettre la lib SSL, et retrouver mon SSH, mais j'ai eu peur de la réinstall complète à 129€ !).
En tout cas chapeau pour passer en register off etc, c'est pas du tout cuit, moi-même je suis encore en train de modifier tout mon site pour qu'il passe ça (entre ça, le XHTML et tout le reste, on s'en sort plus pour faire un simple echo() :))
 
WRInaute passionné
Yvan a dit:
En tout cas chapeau pour passer en register off etc, c'est pas du tout cuit, moi-même je suis encore en train de modifier tout mon site pour qu'il passe ça (entre ça, le XHTML et tout le reste, on s'en sort plus pour faire un simple echo() :))

Merci ;-) En fait ça a été encore relativement vite (un ou deux jours pour 95% du site) pour le plus gros site, qui comportait pourtant des centaines de pages à modifier avec du code plutôt complexe. Donc pour le site de ma signature, je compte que ça me prendra une bonne heure environ.

Par contre, passer au XHTML et abandonner les tableaux c'est pas encore gagné pour mes sites, malheureusement :cry:

aK.
 
WRInaute discret
aK : t'as bien de la chance pour passer une heure à le modifier ! Moi il me faudra 3 semaines (enfin je change de système de cache etc... donc forcément).

Mais pourquoi cet acharnement sur le XHTML :
Par contre, passer au XHTML et abandonner les tableaux c'est pas encore gagné pour mes sites, malheureusement :(
Depuis quand les <b>, les <i>, les <table> ont disparus du XHTML ???? Faut lire le Document Type Definition avant de se plaindre !! Regarde mon site, regarde la source de la page d'accueil. Si tu arrives à me faire ça sans tableau et sans 50 div, je t'offre un hébergement sur mon dédié (mais je limite à 100 visites/jour, des fois que je dise une connerie !).
Et pourtant en bas, clique sur XHTML 1.0. Tu verras que je passe en Transitional sans souci ! J'ai même testé pour toi le Strict : 15 erreurs :
- 10 du fait d'une erreur de mise en page (un <form> en dehors de tout div ou p)
- une du fait du target qui a été supprimé
- un align, un width non accepté (mais qu'il faut mettre dans le style="width:50%" tout bêtement).
- un script mal annoncé (language="" n'existe plus)
Nulle part il n'a bronché pour une table (sinon ça aurait été pour me dire que je me suis raté dans l'enchaînement tr/td). Donc où est le souci ?
 
WRInaute passionné
Je suis tout à fait d'accord avec toi, Yvan !

Nous nous sommes (un peu) mal compris: je parlais d'abandonner les tableaux pour la mise en page, ce qui est plus une question de respect de "l'esprit" des standards que des balises en elles-mêmes.

Quant au fait que le site de ma signature ne comporte "que" 15 erreurs par rapport au "strict", j'en suis plutôt satisfait, mais ce site-là est infiniment mieux codé que mon site le plus gros pour plusieurs raisons:

1) Il est beaucoup plus récent
2) Pour mon gros site, nous sommes 2 webmasters, ce qui rend un petit peu plus complexe le fait de respecter toutes les règles et d'éviter les erreurs de codage
3) Notre gros site est beaucoup plus complexe tant au niveau des requêtes mysql que de l'affichage

Bref, j'essaierai d'abord de respecter les standards à 100% sur mes sites les plus petits avant de tenter le coup sur le "gros" ;-)

aK.
 
WRInaute accro
Pour en revenir aux lenteurs d'OVH... et ses requêtes SQL... bon... on a vu que cela allait être rectifié dans peu de temps car ils sont en train de bosser sur les machines.
Lundi tout devrait être rentré dans l'ordre. Ouf !

Par contre... et là j'ai besoin d'une réponse rapide :wink: ... Je compte déménager cette nuit sur un plan 720.
Quelqu'un a-t-il déjà fait ce genre de migration ? Comment cela s'est-il passé ?

J'espère que le site pourra être accessible dès le redémarrage des machines dimanche matin à 09h00 :roll:

Et faire ça pendant qu'une menace de Google Dance approche... va pas y avoir de facheuses conséquences ? :roll:
 
Olivier Duffez (admin)
Membre du personnel
La Google Dance n'est que le résultat d'une mise à jour des serveurs de Google. Ca n'a rien à voir précisément avec la venue de GoogleBot sur nos sites. Donc tu peux y aller, fonce !
 
WRInaute accro
Merci Olivier,

c'est ce que je pensais aussi... mais j'avais peur que le bot s'emballe un peu à ce moment là :lol:

Bon... je fonce :wink:
 
WRInaute accro
si pas d'acces a ton site c'est clair que tu y perdras quelques plumes (quelques pages qui ressortiront sans titre ni description) mais bon, ca rentre tres vite dans l'ordre ..
 
WRInaute passionné
Americas a dit:
Par contre... et là j'ai besoin d'une réponse rapide :wink: ... Je compte déménager cette nuit sur un plan 720.
Quelqu'un a-t-il déjà fait ce genre de migration ? Comment cela s'est-il passé ?

J'espère que le site pourra être accessible dès le redémarrage des machines dimanche matin à 09h00 :roll:

Et faire ça pendant qu'une menace de Google Dance approche... va pas y avoir de facheuses conséquences ? :roll:

Le déménagement est toujours une chose pénible... surtout pour les bases de données :( Tu n'as pas d'accès ssh avant le 720plan (tu peux toujours demander au support de te bouger tes bdd mais ils ne sont pas tenus de le faire).

Faudra aussi attendre la propagation des DNS pour que tout se remette en ordre de marche, ça aussi c'est pénible..

Prochaine étape pour toi: le dédié !

aK
 
WRInaute discret
Salut a tous :wink:

Si j'ai bien compris ce que tu dis Yvan :

site HTML > besoin d'un max de RAM car y'a beaucoup de connexions, et peu de CPU nécessaire.
site PHP > si les scripts sont optimisés (les miens font entre 100 et 500 ms de création, avec système de cache etc...), ça peut encore aller quand y'a pas beaucoup de peuple. Mais le CPU prend très vite très cher, car PHP consomme infiniment fois plus qu'une bonne vieille requête sur une image/page HTML simple. Donc là c'st le CPU qui prime, et non la RAM


Le serveur Superplan+ de ovh
Celeron 2.6Ghz
256Mo de Ram

Pourra supporter beaucoup plus de visite pour un site en PHP que le serveur premier prix de SIVIT ?? (qui a un Celeron 1.8Ghz et 256 de ram )
 
WRInaute occasionnel
J'aimerai savoir ce que vous entendez par système de cache.
Je pense que nous sommes plusieurs à suivre avec intérêt ce message car à terme, certains d'entre nous passerons sur dédié.
Bref, quelle solution de cache avez vous adopté ?

Le post d'avant est aussi intéressant : entre le serveur de Sivit et celui d'OVH, il y a une différence de vitesse assez importante entre les processeurs. Est-ce que cela se ressent dans la rapidité du serveur et pour la consultation des sites ?
 
WRInaute passionné
bjp a dit:
J'aimerai savoir ce que vous entendez par système de cache.
Je pense que nous sommes plusieurs à suivre avec intérêt ce message car à terme, certains d'entre nous passerons sur dédié.
Bref, quelle solution de cache avez vous adopté ?

Pour la plupart des pages où on fait des requêtes mysql, les données ne changent pas ou pratiquement pas d'une heure à l'autre, voire d'un jour à l'autre.

Pour tous ces cas-là, je fais un test avant de commencer ma requête:

1) S'il existe un fichier cache de la page en question et que ce cache est plus récent que xxx secondes, on l'affiche et on ne fait donc pas de requête. Un bête include suffit.

2) Si les conditions ne sont pas remplies, on exécute la requête, on l'affiche et on enregistre son résultat dans un fichier texte sur le serveur.

Voilà, si quelqu'un veut un exemple, je peux en mettre un.
aK.
 
WRInaute occasionnel
Je crois savoir qu'il existe des applications de "cache" comme mmcache ou PHP Accelerator qui s'installent sur le serveur et rendent les accès aux bases plus rapides.
Je pensais qu'il s'agissait de cela. Est-ce que quelqu'un à l'expérience de ce système ?

-http://www.phpindex.com/annuaire/annuaire_infos.php3?annuaire=993
-http://www.sivit.fr/phpBB/viewtopic.php?topic=992&forum=1

Je relance aussi ma question concernant la vitesse du processeur, entre Celeron-2.6 GHz et Celeron 1.8Ghz, l'accès aux sites ou le traitement des requêtes sera-t-il nettement plu srapide ?
 
Nouveau WRInaute
syntaxerror a dit:
Yvan a dit:
Et 7 à 8000 personnes par jours (donc environ 700 000 hits)

1 VU = 100 hits avec un site bien optimisé ?

1 visiteur unique consulte combien de page. En moyenne 5 pages sur un bon site, donc ça fait 20 hits par page, mais quelque chose me dit que chaque visiteur consulte plus de 5 pages sur coc (c'est mon cas ;-), donc visiblement c'est un site trés bien optimisé.
 
WRInaute accro
toujours en rapport avec mes problèmes :

Quelle version de phpmyadmin utilisez-vous ? j'ai un problème de connexion avec la version 2.5.6 et je vois pas du tout ce qui déconne 8O

J'ai beau regarder le config.inc.php... impossible de me connecter
 
WRInaute passionné
Americas a dit:
toujours en rapport avec mes problèmes :

Quelle version de phpmyadmin utilisez-vous ? j'ai un problème de connexion avec la version 2.5.6 et je vois pas du tout ce qui déconne 8O

J'ai beau regarder le config.inc.php... impossible de me connecter

J'ai la 2.5.2... quel est ton problème ? A priori si tu as une version stable, ça doit rouler...
 
WRInaute accro
j'ai la 2.5.6

je cherche à me connecter mais j'ai
Warning: Cannot modify header information - headers already sent by (output started at /home/americas/www/phpMyAdmin-2.5.6/config.inc.php:2) in /home/americas/www/phpMyAdmin-2.5.6/index.php on line 42
 
WRInaute accro
c'est bon... problème résolu :)

c'était tout con :oops:

je travaille avec webexpert et ce con avait rajouté la ligne suivante :

Code:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
il fait ça a chaque fois que j'ouvre le fichier... et le serveur ne sait pas comment interpréter ce truc dans un code en php

Il faut que je trouve un autre éditeur pour les php.

Merci tout de même :wink:
 
WRInaute discret
aK : ça me fait plaisir que tu te penches sur le W3C :)

syntaxerror : voilà mes stats pour février :
1.23 visites/visiteur
7.36 pages/visite
41.31 hits/visite
88.58 Ko/visite

Et environ 17 500 visites/jour. Donc un peu plus de 10 000 visiteurs/jour (selon Awstats).
Ensuite un visiteur ne fait pas forcément 100 hits. Si j'avais 200 images différentes/page et 10 pages vues par visiteur, ça ferait 2000 hits/visiteur. Donc rien à voir avec l'optimisation du code !
Si tu es limité en hits, essaye de réduire le nombre d'images par page (quitte à grouper plusieurs images en une seule), intègre ton CSS dans le code de ta page (et non avec un <link ..."style.css"/>), voilà de quoi réduire ta facture de hits.
 
WRInaute discret
Vous avez oublier les questions de bjp :(

bjp a dit:
Je crois savoir qu'il existe des applications de "cache" comme mmcache ou PHP Accelerator qui s'installent sur le serveur et rendent les accès aux bases plus rapides.
Je pensais qu'il s'agissait de cela. Est-ce que quelqu'un à l'expérience de ce système ?

-http://www.phpindex.com/annuaire/annuaire_infos.php3?annuaire=993
-http://www.sivit.fr/phpBB/viewtopic.php?topic=992&forum=1

Je relance aussi ma question concernant la vitesse du processeur, entre Celeron-2.6 GHz et Celeron 1.8Ghz, l'accès aux sites ou le traitement des requêtes sera-t-il nettement plu srapide ?

je relance car je suis interessé par les reponses :D
 
WRInaute discret
Désolé, pas vu le post :(

Mon éditeur perso : vi (installé sur toutes les distrib Linux si je me trompe pas). Bien sûr on préfèrera vim (vi improved) qui permet des recherches plus puissantes + coloration du fichier, c'est très très utile (quand je reviens sur le bon vieux notepad, je me demande comment j'ai pu vivre sans vim aussi longtemps :))

bjp : j'utilise PHP Accelerator (qui est gratuit comme chacun sait). Ca accélère vraiment beaucoup le PHP, mais rien à voir avec MySQL. Seul petit souci : j'ai 300 Mo de fichiers temporaires, je ne sais pas ce qu'il compte en faire (les éffacer un jour ?). Il faut dire que derrière ça j'ai un gros système perso de templates/cache, donc il se peut qu'il croit que j'ai un fichier nouveau à chaque fois > autant de fichiers temporaires.
Mais le rendement sur un script en temps d'exécution varie entre 30 et 50% de temps en moins. Donc incomparable :)

Concernant la vitesse du CPU : elle ne compte pas pour la vitesse d'accès, ou presque.
En fait, si tu as assez de processeur, le gars en face qui appelle la page ne verra aucune différence entre 5 et 500 ms de création, qu'on se le dise :) Par contre si tu commences à ramer (c'est mon cas sur le 1,7GHz avec une limite à 35 connexions simultanées sur Apache), là ils verront une différence : le temps qu'Apache libère un processus, pour qu'un nouvel utilisateur puisse arriver. Encore un truc : le temps de connexion à Apache dépend exclusivement de la vitesse de transfert de l'info (donc une page de 300Ko en 56K, ça risque de prendre du temps !). Donc si vous limitez en nb de connexions simultanées, ça peut très bien ramer à cause du nb de connexions max atteint, et non à cause du CPU (qui se repose pendant ce temps ;)).

Je sais pas si j'ai été clair en fait... Mais de toute manière, si on peut avoir un meilleur CPU, autant le prendre ;o) A savoir que OVH ne veut pas faire de modif sur mon ancien serveur donc je suis obligé d'en prendre un nouveau (c'ets peut-être pas compatible faut dire...).
 
WRInaute occasionnel
Merci pour ces précisions. C'est intéressant.
Une petite question à Olivier : quel était le problème sur le serveur de webrankinfo ? Il y a une semaine ça ramait, et maintenant c'est bien rapide.
 
WRInaute discret
j'ai vu que dans un ancien message Nitou a dis:

"Moi je suis chez Sivit pour les dédiés et c'est vraiment très bon, comparé à OVH qui limite le burst à 1 mo pour les offres basics et 32 mo pour les autres, Sivit lui ne limite pas ses ports... si c'est pas un motif pour aller chez eux "

J'ai pas compris , ca change quoi exactement ? :roll:
 
WRInaute discret
Le burst c'est un pic. En clair si tu as à faire un pic (téléchargement d'un fichier, par exemple un .rpm assez gros), tu es autorisé à dépasser ta limite de 1024Kb/s pendant un temps limité/débit limité.
Chez OVH, tu as le droit de dépasser le 1024k pour un transfert maximal de 32Mo. Et tu dépasses à la vitesse de 100Mb/s. Donc c'est très intéressant, car tu peux télécharger un package RPM en quelques secondes au lieu de 10 min...
Pour info : tout le monde peut télécharger chez toi à cette vitesse là, donc il faut faire gaffe à bien limiter le FTP et à ne pas mettre de fichier trop gros sur le serveur Web, sinon ce sont tes internautes qui en profitent.
Un peu plus de précision sur la durée de ce burst chez OVH toujours :
burst ??? : aussi longtemps que votre reservoir de burst n'est pas vide
vous disposez de 100Mbs de bande passante garantie. Vous
commencez à vider votre reservoir lorsque vous depassez 1024 Kbs.
Une fois que votre reservoir est vide, vous êtes limités à 1024 Kbs.
Pour commencer à remplir à nouveau le reservoir il faut consomer
moins de 1024 Kbs. Le reservoir de burst est de 32Mb
Donc il est clair qu'il faut attendre que ça recharge un peu de temps en temps :) Mais bon, qui utilise sa BP à fond 24h/24 ?

C'est plus clair là ? Donc je ne suis pas trop d'accord avec Nitou... OVH limite à 32Mo pour éviter que ça ne sature son réseau (en effet les 32 Mo sont pris sur le restant de bande passante non utilisée). Et de toute manière il ne faut _pas_ compter là dessus pour avoir une connexion 100Mb/s en permanence... D'ailleurs qui utilise le burst ici ?
Autre chose : y'a aussi le système Open Brick de Lost Oasis. En clair vous avez un débit garanti, mais si vous ne vous en servez pas, quelqu'un qui en aurait besoin peut l'utiliser à votre place. Mais je pense que ce système a quand même ses limites...
 
Discussions similaires
Haut