Jukien

En passant, je profite de ces attaques contre OVH pour le souligner : le "support incompétent" en question m'a changé une alim défectueuse en moins de 10 minutes, sur un Kimsufi (donc un serveur sans SLA, il faut le préciser), à 6h00 du mat'. Comme quoi, parfois, ils sont pas si incompétents que ça, hein. * Il est toujours plus simple de critiquer que de remercier *

Mon point de vue rejoint directement celui d'Occi. Visiblement, cet hébergeur à l'air de sous-louer ses serveurs chez OVH, je ne vois pas comment ils peuvent promettre de tels chiffres. Peut être que c'est simplement une manière de dire que la bande passante mensuelle n'est pas comptée (même s'il y a un limite de débit). Si c'est un site web perso, pourquoi pas, mais pour un projet plus sérieux ou professionnel, passe ton chemin.

Que ce soit un serveur dédié, un RPS ou un VPS, d'un point de vue software, c'est exactement pareil. Les limitations et différences hardware n'entrent pas vraiment en compte dans la configuration de la machine (à quelques détails près, mais ces détails sont gérés directement dans la distribution de base, tu n'as pas à t'en occuper (ex : chez OVH, l'utilisation un disque iscii au lieu d'un disque interne est géré dans la distribution que tu installes)). Et donc, sur un VPS, si, tu as un accès root, et tu peux installer la distribution de ton choix. Si tu as des limitations, elles sont imposées par ton hébergeur (VPS infogéré sans accès root ?), mais ne sont pas obligatoires.

Je doute que les contacter change quelque chose. Visiblement, le problème vient de toi, soit de ton Joomla, soit d'un module que tu utilises. Sinon, les centaines de sites hébergés sur la même infrastructure que ton site souffriraient du même problème. Ca ne semble pas être le cas, je n'ai pas vu de plaintes allant dans ce sens sur les forums OVH.

Une question : quel interet ? Je peux comprendre l'interet d'avoir plusieurs instances de MySQL, en prod, mais en developpement, c'est déjà plus flou. Sinon, pour reprendre les propos de f_trt, tu dois en effet utiliser des ports différents. En espérant qu'il n'y ait pas de conflit au niveau des dossiers d'installation (car vu que ce sont des "packs" tout-en-un, tu n'as pas forcément la main sur toute la config...).

Pour reprendre la réponse de Kioob, ce problème peut venir des DNS. Si le serveur (ou un des serveurs) DNS ne renvoie pas la bonne IP, les 404 seront inévitables... Par contre, il peut être intéressant de regarder si ces 404 sont "vues" par le serveur Apache (et donc de voir si le domaine pointe bien vers le bon serveur). Utiliser des commandes telles que dig ou nslookup sur chacun des serveurs DNS peut aussi te permettre de vérifier tes zones. L'outil de l'afnic peut aussi te dépanner (http://www.afnic.fr/outils/zonecheck/).

Pour revenir sur le RPS, ce n'est pas le top non plus. Le processeur et la ram te sont dédiés... mais pas le disque dur ! Ce disque reste mutualisé. Je ne sais pas ce qu'il en est actuellement, mais il y a quelques mois, il y avait beaucoup de soucis à cause de ça ; la baie de disque n'arrivait pas à suivre, entrainant de nombreux ralentissements (ou indisponibilités complètes) sur les RPS. Je crois que des limitations ont été mises en place depuis, c'est probablement mieux. Mais ça reste un disque mutualisé.

Ok, c'est un Kimsufi 2008 XXL. Je pensais à un Kimsufi de base (celeron, 1 Go ram) au début. Ceci dit, ça reste une belle performance. Sur mon PC Portable tourne bien évidement sous Linux, mais il est vrai que la configuration MySQL n'est pas forcément ajustée avec finesse. Mais il faudrait que je teste sur un vrai PC, avec un vrai disque. Celui-là est vraiment vraiment trop lent. Enfin, je constate quand même que le ["le", car un raid 1 n'a pas d'impact sur l'écriture, et c'est ce qui m'intéresse ici] disque de ton serveur encaisse bien. Donc du coup, je vais peut être privilégier la ram.

Chaque requête manipule une dizaine de ko. Le problème est essentiellement lié au nombre important d'insertions dans la base : En testant sur mon pc portable (donc avec un DD assez lent...), ça ramait assez rapidement. Le problème est surtout lié aux pics : c'est 15 requêtes en moyenne, mais il peut y avoir des pics de 300 à 500 en une seconde, puis un calme plat pendant une 20ene de secondes. Cela dit, je suis assez impressionné par tes 3'000 requetes / secondes. C'est du continu, 24h/24 ? De l'insertion aussi ? Concernant le raid 1, le serveur étant entièrement redondé, je ne pense pas que cela soit utile : les données sont déjà dupliquées en permanence sur deux serveurs. Les 3 Go de données sont susceptibles d'etre manipulées en permanence, mais les requetes de lecture concernent en général moins de 100 enregistrements (donc maximum 1Mo).

Bonjour, Un nouveau projet, tout beau tout neuf, est sur le point d'être lancé. Ce projet utilise intensivement une BDD MySQL en écriture (de 1 à 15 requêtes par seconde), mais beaucoup moins en lecture. Cette base est constituée à 98% de tables au format InnoDB, truffés d'index. Une de ces tables fait actuellement 500 Mo, mais atteindra les 2/3 Go dans peu de temps. Deux choix se présentent pour le dédié (budget 50 max, mais je devrais réussir à pousser jusqu'à 60 euros) : - OVH :: SP Mini (Core2Duo 2x2.33 Ghz, 2 Go DDR2, DD 2 x 500 Go) http://www.ovh.com/fr/particulier/produits...erplan_mini.xml - Kimsufi :: 4XL (Quad Q6600 4x2.40 Ghz, 4 Go DDR, 1 x 250 Go) http://www.kimsufi.com/ Sachant que je me contre-fiche des SLA (tout est redondé), et que la consommation en Bande Passante sera ultra-faible, que me conseillez-vous ? J'ai fait quelques tests sur mon PC, le processeur n'est pas vraiment chargé, ça ne semble donc pas être un critère de choix. Par contre, pour la RAM et le DD, c'est une autre histoire : Est-il préférable de disposer de deux fois plus de RAM, ou d'un joli RAID 0 ? Merci de votre lecture, et merci pour vos éventuelles réponses.

En réponse à Arlette : Ma remarque n'était pas dite méchamment ; Je n'ai absolument rien contre Dan, et sa prestation me semble très bonne. Seulement, en tant que client, lorsque je souhaite me renseigner sur un produit, j'évite de lire les critiques sur le site même du vendeur. Question de logique, les avis ne sont pas toujours très objectifs. Je ne dis pas que c'est le cas ici, je n'ai jamais testé cette prestation donc je peux pas en juger. Or, j'ai parfois l'impression que certains membres conseillent les services de Dan sans les avoir testé. Cependant, si je vous ai froissé, j'en m'en excuse, ce n'était nullement mon intention.

Salut, Pour l'infogérance, je préfère éviter de te conseiller, dans la mesure où je n'ai testé aucune des trois. On entend beaucoup de bien de celle de Dan (mais on est sur son forum, les avis ne sont pas forcément objectifs). Niveau matériel, par contre, je pense que je me serai tourné vers ce type de configuration : http://www.ovh.com/fr/particulier/produits/eg_max.xml C'est toujours difficile de répondre, sans connaître précisément tes besoins en terme de ressources, mais vu que tu sembles faire énormément d'accès MySQL, les 8 Go de mémoire vive seront un vrai régal ! Par contre, au moment de l'achat, fais attention aux garanties données (temps de interventions pour les problèmes Hardware, etc...).

Il fallait bien entendu comprendre "il possède un plan mutualisé 60gp chez OVH". Et là, je suis formel, c'est bel et bien une grappe de serveurs qui répond aux requêtes. Et ce cluster est capable d'encaisser des milliers de requêtes à la seconde, donc cela absorbera la montée en charge bien mieux qu'avec un dédié. Et si ce pic ne représente que mille ou deux milles visiteurs, je pense même qu'OVH ne s'en rendra pas compte, vu que ce n'est qu'une goutte d'eau par rapport à l'ensemble des requêtes traitées.

Il est en mutualisé, donc ce n'est pas un unique serveur qui répondra aux requêtes Apache, mais une baie complète de serveur. Vu les chiffres qu'il donne, ces requêtes seront encaissées sans aucun soucis par les serveurs OVH. Et si ça ne dure que quelques heures, je doute qu'OVH dise quoi que ce soit. Par contre, s'il y a de grosses images, ça peut facilement lui ruiner son quota de bande passante mensuel ! Pour ceux qui ont un serveur dédié par contre, oui, la puissance de calcul peut rapidement être saturée.