Aux utilisateurs d'OVH 240 plan

WRInaute accro
Je me tâte par rapport à l'OVH 240 Plan.

- 10 connexions simultanées à la DB. C'est pour les 15 bases de données ou par base de données parmi les 15 max ?
- 45 Mb pour base de données. Ca s'entend par base de données ou pour les 15 ?
- 1000 sous-domaines. C'est un total ou c'est valable pour les max. 1000 domaines hébergés (donc 1000x1000) ?
- 1000 domaines hébergés. Il y a un surcoût lorsque l'on ajoute un domaine (une option) ?
- Python. C'est toujours une version d'avant-guerre ?

Questions subsidiaires :
- pour vous, faut-il mieux prendre 4 x 60 GP ou 1 x 240 Plan ?
- quel est encore l'intérêt du 300 GP par rapport au 240 Plan ?
 
WRInaute occasionnel
Pour les sous domaines c'est 1000 sous-domaines de ton domaine principale... Pour les autres domaines que tu va héberger tu n'aura droit à aucun sous domaine.

D'ailleurs j'trouve ça vraiment nul !

j'espère que pour les DB c'est pas la même chose... Sinon effectivement ça pourrait être plus rentable de prendre plusieurs 60GP...

Autres précision, pour les emails des autres domaines hébérgés tu devra également acheté un pack email (une dizaine d'euro j'crois les 10 pop)...
 
WRInaute accro
mego a dit:
Pour les sous domaines c'est 1000 sous-domaines de ton domaine principale... Pour les autres domaines que tu va héberger tu n'aura droit à aucun sous domaine.

D'ailleurs j'trouve ça vraiment nul !

Bah, ça dépend ce que tu veux faire.
C'est le même principe que chez Online, sauf qu'OVH est plus généreux et que ça va vachement plus vite.
 
WRInaute occasionnel
ecocentric a dit:
Bah, ça dépend ce que tu veux faire.
C'est le même principe que chez Online, sauf qu'OVH est plus généreux et que ça va vachement plus vite.

Yep, disons que moi ça m'aurait bien arrangé de pouvoir dispatché mes 1000 sous domaines parmis les différents domaines hébergés...
Apparement pour ça il ne propose aucune solution, c'est un peu domage à mon gouts... (mais on s'adapte :wink: )
 
WRInaute discret
La gestion des multis-domaines est vraiment foireuse chez OVH :
- pas clair du tout
- pas simple à mettre en place
- pas de sous-domaines sur les domaines ajoutés
- pas d'email (POP ou redirection) sur les domaines ajoutés
- nécessite la gestion avancée des DNS chez le registrar des domaines ajoutés
- ...

J'avais un plan, je l'ai très vite résilié pour prendre plusieurs petites offres...
 
WRInaute accro
Sur le 60 GP, on a 3 connexions simultanées : ça représente combien de visiteurs / de pages vues par jour (à 5 requêtes en moyenne par page) ?
(ordre de grandeur très approximatif)
 
WRInaute occasionnel
En général une connexion à la base de données ne dure que quelques mseconde... Le temps de l'interroger et hop...

Donc avec 3 connexions simultannées tu peux déjà assurer pas mal de visiteur/ jour...

a toi de faire le ptit calcul pour plus de précisions.


(corrigez moi si je me trompe)
 
WRInaute accro
mego a dit:
En général une connexion à la base de données ne dure que quelques mseconde... Le temps de l'interroger et hop...

Ya pas des persistances de connexion (genre de cache ?).
De ce point de vue, faut-il mieux ouvrir et vite fermer ou laisser ouvert sur toute la page puis fermer ?
 
WRInaute occasionnel
ecocentric a dit:
Ya pas des persistances de connexion (genre de cache ?).
De ce point de vue, faut-il mieux ouvrir et vite fermer ou laisser ouvert sur toute la page puis fermer ?
Ca depends de l'hebergeur et de la version MySQL utilisée.

Pour la question de connexion persistante ou ouverture fermeture à chaque fois...
Ca depends de la machine qui heberge, l'un va pomper plus de ressources que l'autre... (je crois qu'il y a un thread d'ouvert la dessus). Dsl je n'en sait guère plus...
La seule chose dont je me rappel c'est que suite à mes lectures j'avais décidé de rester en connexion persistante (ouvre debut de page ferme en fin)...
 
WRInaute passionné
ecocentric a dit:
Ya pas des persistances de connexion (genre de cache ?).

Mauvais codage ?

Une connexion à la bdd ne doit durer que le temps d'envois des requêtes.

Si pour une réson quelconque, la page met 30s à se charger, la connexion reste ouverte 30s ???
Pas bon ça.
 
WRInaute accro
Grantome a dit:
ecocentric a dit:
Ya pas des persistances de connexion (genre de cache ?).

Mauvais codage ?

Une connexion à la bdd ne doit durer que le temps d'envois des requêtes.

Si pour une réson quelconque, la page met 30s à se charger, la connexion reste ouverte 30s ???
Pas bon ça.

Non, non, ce que je veux dire, c'est que je pense avoir lu que MySQL laisse la connexion ouverte un peu plus longtemps pour pouvoir la rouvrir plus vite après. C'est un genre de cache géré par MySQL. Enfin, je me trompte pê, mais je me demandais quel impact ça a sur le nombre de connexions simultanées et sur la manière de coder.
 
WRInaute occasionnel
A mon souvenir la dernière version de MYSQL garde en cache toutes les requêtes qui ont étés effectués afin de ne pas trop saturer le serveur...

Tu trouvera plus de details sur http://dev.mysql.com/


-> concernant la question initiale du post (OVH etc...), je suis également intéressé par les réponses que tu pourra trouver...
 
Nouveau WRInaute
Grantome a dit:
ecocentric a dit:
Ya pas des persistances de connexion (genre de cache ?).

Mauvais codage ?

Une connexion à la bdd ne doit durer que le temps d'envois des requêtes.

Si pour une réson quelconque, la page met 30s à se charger, la connexion reste ouverte 30s ???
Pas bon ça.

de toutes les manieres , pour du PHP par exemple... tout ton code a deja été interpreté coté serveur , au moment ou la page se charge coté client , c'est juste de l'information qui transite plus ou moins vite , mais le server ne travaille plus (enfin a part envoyer l'info)
 
WRInaute passionné
mego a dit:
A mon souvenir la dernière version de MYSQL garde en cache toutes les requêtes qui ont étés effectués afin de ne pas trop saturer le serveur...
Tu trouvera plus de details sur http://dev.mysql.com/
-> concernant la question initiale du post (OVH etc...), je suis également intéressé par les réponses que tu pourra trouver...

Exact. Le but du cache est de minimiser le temps des requêtes à la base MySQL.

Je pense que les connexions simultanées sont indiquées pour l'ensemble des bases du 240.

J'avais un 60gp sur OVH, avec 3 connexions simultanées donc. Je faisais tourner le site Yazerty.Net dessus (700 - 1000 Visiteurs Uniques / jour à l'époque). Il tournait grâce à l'outil de blog DotClear (très bien codé, efficace). Mais de temps en temps certains visiteurs tombaient sur des "too many connexions".
Depuis j'en ai eu marre des lenteurs d'OVH, de ces petits problèmes de connexion MySQL et du faire que mes Adsense n'étaient pas très bien ciblés (Google m'a répondu que c'était OVH qui le bloquait, ça m'a paru étrange mais bon..). Je suis passé sur 1&1 en Pack Perso Confort (2 ndd, 4Go d'espace, MySQL avec connexions simultanées sans restriction il me semble - à vérifier,...). Depuis tout va mieux, alors que le nombre de visiteurs a depuis pas mal augmenté (+50%) :).
 
WRInaute discret
Je suis parti de chez OVH 240 Plan apres 1 an car trop décu par :

1) les downtime ( mail ou site ou ftp ou les 2 ou les 3 )
2) le service client...inexistant !
3) les numéros de tel clients surfacturés
4) 7 sql simultané ...une misere
5) les nombreux mailing : on a eu ce probleme, on a eu cette attaque...bref plein d'excuses ( bidon ?)
6) et finalement : les tarifs pas compétitif du tout...

Voila...

Un bon hebergeur mutualisé : www.infomaniak.ch ( j'y ai jamais été mais j'ai entendu que du bien )
 
Discussions similaires
Haut