Aller au contenu

mtcocktail

Webmaster Régulier
  • Compteur de contenus

    64
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par mtcocktail

  1. Avec ce nombre de visiteur mensuel ça m'étonnerais que tu trouve mieux qu'ovh. Tu peux déjà remercier ovh d'avoir continuer à hébergé ton site en mutualisé. J'imagine que tu n'a pas réussi à monétiser les visiteurs ? Ou alors si c'est un service qui ramène de l'argent le laisser sur du mutualisé ovh c'est un peu gros. Donc j'ai bien peur que tu va être obligé de passer sur serveur dédié et ne pas négliger un service d'infogérance. Car seul sans connaissance système tu risques d'avoir des problèmes pour faire tourner 40 000 V/jours. Si le service ne ramène pas d'argent (étonnant car j'ai des sites qui font beaucoup beaucoup d'argent en pub avec le même volume de visiteurs ) laisse le chez ovh et attend que l'orage passe.
  2. Demandé à Ovh si il y'a des différence de puissance entre les offres genre nombre de connexion simultané sur le site. C'est qu'il semble annoncer avec leur nouvelle architecture pour les mutualisés. Mais bon l'illimité n'existe jamais réellement Et je me répète tous dépend de ton site, Wordpress par exemple avec les plugin de cache ou pas. Le nombre d'articles, la taille de la base, nettoyage des moteurs d'indexation... C'est peut-être ton php qui rame. Sinon oui un sql privé avec 512Mo de ram suffira je pense pour ta volumétrie. Imagine que sur un serveur dédié 80% des gens ne font pas attention à optimiser le moteur mysql et ils utilisent un Mysql avec seulement 16Mo de RAM (Conf par défaut de mysql ). Maintenant pareil j'ai jamais essayé ces offres mutualisés. Tu peux peut-être poser la question sur le forum ovh : http://forum.ovh.net/forumdisplay.php?f=8
  3. Oui faut pas hésiter a prendre l'option car je crois qu'il limite sur les sqlperso le nombre de connexion simultané. Si vraiment la puissance ne suffit pas, j'ai lu qu'en quelques clic tu peux transformer ton offre mutualisé OVH en Serveur Cloud OVH.
  4. Effectivement, c'est marrant que vous ayez accès à une utilisation CPU en environnement mutualisé. Difficile de juger ce que demande ton site ça dépend de son développement, c'est sûr que par exemple un wordpress ça mange beaucoup surtout si tu ne met pas en place les plugins de cache.. Je dirais plusieurs solutions s'offre à vous : - Votre site nécessites des configurations particulière qui ne peuvent être mis en place que sur un serveur dédié. Mais vous n'avez pas les moyens d'un vrai dédié => Direction les cloud type VPS chez ovh ou gandhi par exemple. => Attention problème d'administration système et d'infogérance. Et surtout pas sûr que votre site ne soit pas trop gourmand pour ce type d'offre a moins de prendre une VPS à 60 ou plus. - Vous voulez de très bon temps de réponse sur votre site, un dédié plus un prestataire pour l'infogérance et l'optimisation. C'est valable que si le site à un intérêt économique - Moi je tenterais une offre mutualisé chez OVH, ils ont changer dernièrement leur plateforme mutualisé. Aucune idée si elle fonctionne bien puisque j'ai que des serveurs dédiés. Mais je pense que ca vaut le coup d'essayer, peut-être que certains ont des retour d'expèrience d'un wordpress sur un mutualisé ovh.
  5. Moi j'ai plutot tendance à déconseillé 1and1. J'infogere un serveur cloud dynamique 1and1 et franchement niveau perf ça fait peur. Entre ce qui est annoncé et la vitesse du truc y'a un gap. On a l'impression de se retrouver avec une brouette... Faudrait savoir combien de bande passante ou de trafic généré ton site. Qu'est-ce qu'il t'on dit exactement infomaniak. Car le problème d'un dédié c'est qu'il faut aussi s'en occuper et l'infogérer.
  6. Je dirais que sur les kimsufi 750G y'a quand même une SLA standard. A la place de premium sur les offre ovh. Par contre effectivement sur les kimsufi tu ne peux pas déclarer un incident de niveau 3 (ticket payant) et La GTI sur un serveur indisponible est de 2h pour un kimsuffi contre 1h pour un ovh.
  7. Pas de raid soft possible sur le kimsufi qui a un seul disque.
  8. Humm Effectivement sur des vieilles URL indexé, il faut bien rajouter les redirections 301 sur les anciennes URL. J'avais jamais pensé à ce problème.
  9. Je voies pas pourquoi le apache-noscript blacklist les moteurs ?
  10. Pour un Magento il est fortement déconseille un hébergement mutualisé. Magento est très gourmand et nécessite plusieurs point spécifique comme par exemple l'installation de surcouche de précompilation php pour avoir un résultat correct. Il faut se tourner au minimum vers une offre serveur virtuel avec une RAM consequente. Nous par exemple on fournit des VPS infogéré Magento avec 2 ou 4Go de RAM pour que le résultat soit correct. D'autre prestataire font également des vps infogéré, renseigne toi bien sur les services associés c'est le principal. Pour plus de détail MP car pas trop de pub sur les forums
  11. Oui j'ai fait ça de tête, les erreur de syntaxe peuvent se glisser
  12. Stop mysql /etc/init.d/mysql stop Lance mysql sans tenir compte des droit et sans le réseau pour eviter les hack. mysqld_safe skip-grant-tables skip-networking & mysql -u admin mysql A partir de la tu rétablit le mot de passe et les droits complet de admin. Soit remettre un mot de passe : > UPDATE user SET Password=PASSWORD('mot de passe plesk') WHERE User='admin'; > GRANT all privileges on *.* to admin_AT_localhost; > exit ( Remplacer le _AT_ par @ ) Et tu relance mysql pour tester killall mysqld_safe && /etc/init.d/mysql start
  13. Essaye ça, pour revenir avec le mot de passe plesk que tu avais mysqladmin -u admin -p'le_nouveau_pass_mis_par_accident' password le_mot_de_passe_admin_plesk
  14. Tu as changé le mot de passe du user admin de mysql ? c'est ça ?
  15. Oui pour changer le mot de passe admin de plesk il vaut mieux passer par les outils de plesk Essaye de changer le mot de passe contenu dans dans cat /etc/psa/.psa.shadow ensuite service psa stop , service psa start
  16. Oui moi pour certains dédié ou il n'y a qu'un seul site je monte quand même un openvz (Avec proxmox) pour pouvoir justement faire ce type de dump. La taille du dump fera que la taille des données utilisées donc ici seulement 5Go, car avec openvz c'est du paravirtualisé, il prend donc que les datas et non une image d'un disque virtuel. Voir moins si tu le compresse. Le dump se fait même à chaud si tu es sur une partition de type LVM, la restauration se fait en une seule ligne de commande toute bête aussi.
  17. Moi pour ce genre de chose je conseille fortement de virtualiser l'ensemble. Ensuite tu fais un dump de ton vps tous les 15 jours et entre temps tu continues à sauvegarder tes data journalierement par ton backupmanager. Petit hic ça se fait bien si ta vps ne fais pas 200Go d'espace disque et prend toute la place sur le serveur. Sinon faut rattacher des filer ou un autre serveur en iscsi pour pouvoir faire le backup.
  18. Effectivement il faut vérifier les slots apache. Je suis d'accord avec l'analyse donc je vais pas recapetete ce que jacque a dit
  19. Et donc les temps de début de chargement ? ça l'air rapide le coucou.
  20. et avec une page toute bête .html avec coucou dedans ça fait pareil ?
  21. 3 dns chez Gandi pourquoi aller chercher un autre serveur secondaire. C'est déjà pas mal.
  22. Modifie ton fichier host de ta machine qui est consulté avant les DNS cache indiqué dans ta configuration réseau. Pour cela : - Sur windows : c:/windows/system32/drivers/etc/hosts - Sur Linux / Mac : /etc/hosts Tu rajoute une ligne a la fin avec : ADRESSE_IP www.tondomaine.com Tu relances tes navigateurs, et alors quand tu vas taper ton nom de domaine c'est comme si tu aurais fait la migration DNS.
  23. Oui effectivement la premiere connexion était vraiment lente depuis un réseau free. Envoie à OVH un extrait d'un Top du serveur pour leur indiquer que le serveur n'est pas chargé pendant ton test. Et ensuite à partir du serveur essaye de faire des traceroute voir si y'aurais pas un problème. Par exemple avec l'utilitaire "mtr" sous linux.
×
×
  • Créer...