Un dédié ou pas.

[Karedas]

Je viens vous trouver en quête de conseil.

J'ai depuis quelques années un hebergement illimité à 9,95$ chez dreamhost.

Le mois dernier j'ai lancé une application Facebook qui en un mois envoi 400k requêtes/jour au serveur et elle continue de monter.
Le problème est que le procwatch du serveur ou je suis plante 1.5% de mes requêtes pour cause de trop de RAM mangée.

J'ai donc tenté le VPS de dreamhost, mais voilà, à l'heure qu'il est il me faudrait 600Mb de ram soit 60$ et je crains que ça n'explose si l'appli continue de croitre.
D'où mon problème existentiel, pourquoi ne pas migrer le tout vers un Kimsufi. ? A quelques euros près, ça ferait un Quad Core Q6600 avec 4Gb de RAM.

Le soucis c'est que, si je suis pas trop mauvais comme programmeur, coté admin je suis plutôt pas bon. Ma seule expérience se résumant à monter un LAMP sur ubuntu à la maison, pour tester et me faire la main. Mais je doute de pouvoir installer du jour au lendemain un serveur super sécurisé et optimisé.

Si on est plutôt débrouillard et qu'on sait lire des tutos, est-ce ci compliqué que ça d'entretenir un serveur ?
Cours-je à la rencontre de multiples emmerdes si je me lance dans l'aventure d'un dédié ?
Dans le pire des cas, combien pensez vous qu'un freelance me prendrait pour m'installer un serveur tout propre ? Pour le maintenir en cas de besoin ? (faut savoir externaliser ce qu'on ne sait pas faire)

 

[Karedas]

J'en rajoute une:

Sur la page décrivant les Kimsufi

Votre serveur avec LAMP ou WAMP et plesk à la demande ! Il ne vous reste qu'à uploader vos sites !

Vous connaissez les Kimsufi ? Effet de pub, ou je peux m'imaginer ne pas me prendre la tête autant que je ne le crains avec l'administration ?

 

[spout]

Vous connaissez les Kimsufi ? Effet de pub, ou je peux m'imaginer ne pas me prendre la tête autant que je ne le crains avec l'administration ?

Si tu installes la release 2 OVH (par défaut), la gestion des noms de domaines et des hébergements se passe dans un module Webmin spécial OVH, OVHm (OVH manager). Je ne suis pas du tout un pro en gestion de dédié, mais avec OVHm c'est très simple

 

[passion]

perso j'ai fait mes débuts sur la première gamme des kimsufi sur distrib DEBIAN 4.0.
Je compte pas le nb de fois ou j'ai dû réinstaller la distrib loool

Mais pour 20€/mois, ça vaut le coup de prendre un dédié et de te faire la main dessus !
Et une fois que tu te sens prêt, tu héberges tes sites par la suite!

Perso, je te conseillerai de commencer directement en te lançant dans le grand bain, tu apprendras plus vite et ce que j'ai fait avec Debian.
Maintenant je ne changerai certainement pas de distrib et je ne pourrai plus revenir sur du mutualisé!

De plus, tu as aussi l'infogérance si besoin??!!
Je pense que c'est un bon début:
http://olange.developpez.com/articles/debian/installation-serveur-dedie/
et avec une interface webadmin:
http://www.webmin.com/

 

[Karedas]

Merci pour vos réponses,
Je viens de chercher un peu d'infos sur la release 2 d'OVH, effectivement ça a l'air plutôt simple pour le nul en admin que je suis.
Je pense que je vais tenter le coup avec une release 2 d'OVH, quitte à passer sur une debian si besoin quand j'aurais fais mes armes.

 

[loran750]

Attend ! j'ai 3 commentaires si tu le veux bien :

si tu va chez OVH, pense à :
* utiliser le serveur de mail Postfix au lieu de Qmail ... Qmail n'est pas terrible ... J'ai la Release 2 et c'est le point chiant de cette distrib
* optimise MySQL, il existe des scripts qui t'analysent le serveur et te font des préconisations
* Si tu as un peu de temps pour tester la distribution ISP Config 3, essaye, elle est bien plus récente que la Release 2 et est optimisée pour le web (bon, comme la R2, mais voilà). En plus ISP Config 3 est sur debian 5

jette un oeil sur les distributions : http://www.ovh.com/fr/items/distributions.xml?sort=use

 

[Julia41]

Surtout pas la release 2 OVH... C'est bien pour les débutants mais si un jour tu veux apprendre un peu plus, tout de suite, tu vas avoir du mal...
Je rejoins loran750 : à mort qmail

Tu pourrais aussi voir au niveau de tes scripts (j'ignore ce qui consomme actuellement) mais par exemple, mettre un peu de cache par ci par là, pourrait être une bonne idée.

 

[Karedas]

Merci pour les tuyaux.
En effet ISP Config 3 a l'air pas mail, un bon compromis en release 2 et debian brut de décoffrage.
Pour mysql je vais essayer de voir ce que je peux faire.

Entre le 500G et le 750G la différence est vraiment aussi significative qu'il y parrait ? Je pense pas avoir besoin de 4Gb de RAM avant un moment, mais la différence de processeur me semble sympa.
Si je restais chez dreamhost en VPS je serais dans les 90 dollars, l'appli faisant des pointes à 800 Mb mangé (ils s'ennuient pas DH avec leurs VPS à 1$ les 10Mb). Ce qui correspond au prix d'une 750,donc j'ai tendance à me laisser prendre au jeu

Dans tout les cas je pense que je vais garder Dreamhost un mois le temps de patauger sur le dédié avec l'appli sur un sous domaine. Et switcher définitivement une fois bien à l'aise avec le nouveau jouet. Des heures de retournage de cerveau en perspective.

 

[Karedas]

Tu pourrais aussi voir au niveau de tes scripts (j'ignore ce qui consomme actuellement) mais par exemple, mettre un peu de cache par ci par là, pourrait être une bonne idée.

Je ne peux rien quasiment rien mettre en cache, s'agissant d'une appli facebook ou chaque requête doit renvoyer des informations fraiches et personnelles.
Les scripts consomment entre 256 et 768 kb en moyenne avec des pointes à 1.5/2Mb sur certaines requêtes (on va dire 15% qui montent jusqu'à plusieurs Mb et 85% entre 256 et 768 K).
Je suis en train d'optimiser l'architecture pour minimiser le nombre de requêtes et la mémoire utilisée par chaque, mais étant déjà pas mal pensé au départ, je vais pas gagner plus de 10% de ressources (ce qui est déjà bien, mais il faudra quand même déménager).

 

[Julia41]

Je ne connais pas trop le principe de fonctionnement des applis facebook, mais par exemple le nom d'un utilisateur peut être mis en cache jusqu'à "l'infini" donc tu gagnes la partie d'un SELECT en plus, tout dépends comment tu gères le tout.

Attention toutefois car si tu as un nombre énorme de requete SQL, tu vas déjà perdre en temps de réponse si ton serveur est situé en France (le trajet US<=>FR prends quelques ms).

Perso pour diminuer le traffic SQL de l'un de mes sites, (j'étais à 10MB/s de traffic) ne serais-ce qu'en renommant ma base de données de "ceci_est_un_test" en "c" j'avais gagné quelques Ko (sur 2K de query/secondes ça commence à faire), pareil pour le mot de passe et le nom de l'user pareil pour certaines tables en ne laissant qu'une seule lettre. C'est bien sûr de la micro optimisation, mais si tu payes ta BP ça devient vite rentable. Pareil pour les SELECT, verifie que tu sélectionnes uniquement le strict minimum, et si ce n'est pas fait utilise la compression SQL.

 

[Karedas]

Je dois pas avoir un seul script qui lance plus de 3 requêtes et elles sont toutes plutôt bien optimisées.
Si je passe en dédié, je lui met la mysql avec, j'ai pas encore besoin d'assez de ressource pour justifier de séparer les 2. Le jour ou ce sera le cas, je prendrais éventuellement un 2ème dédié pour ça, mais on en est loin, cette appli a une conso de mysql vraiment ridicule.
Ce qui me bouffe le plus c'est pas mysql, c'est les appels à l'API facebook, comme récupérer 200 publications pour un utilisateur, à sa première connexion, puis les plus récentes toutes les minutes, et c'est précisément ce qui me prend le plus de ressources que je ne peux pas mettre en cache.

 

[Julia41]

Autant pour moi (au temps pour moi?) je n'y étais pas du tout.

 

[Leonick]

C'est bien sûr de la micro optimisation, mais si tu payes ta BP ça devient vite rentable.

la BP que tu paies, c'est celle externe, pas au niveau de ton UC

 

[Julia41]

C'est bien sûr de la micro optimisation, mais si tu payes ta BP ça devient vite rentable.

la BP que tu paies, c'est celle externe, pas au niveau de ton UC

Pas sûr d'avoir compris le terme "UC", mais dès que tu sépares ton SQL du reste, tu payes forcément ce traffic et encore heureux que tu ne payes pas le local.

 

[Leonick]

Unité Centrale. Si ton serveur web et ton serveur SQL sont chez le même hébergeur, tu ne paie pas le trafic entre les 2, donc le nom de la BDD, du user et du password ne comptent pas dans le calcul de ta bande passante.

 

[Julia41]

Unité Centrale. Si ton serveur web et ton serveur SQL sont chez le même hébergeur, tu ne paie pas le trafic entre les 2, donc le nom de la BDD, du user et du password ne comptent pas dans le calcul de ta bande passante.

Tout dépends de l'hébergeur (certains sont plus honnête que d'autres mais ça reste du externe), et aussi tout dépends dans combien de pays/hébergeur tu as tes dédiés.

 

[Karedas]

Pfiou, en attendant de me lancer sur un dédie, j'évalue mon appli sur le VPS dreamhost que j'ai pris en secours.
Et ben pfiou là là, ça consomme, avec des pointes à 2.5Gb de RAM utilisée (je comprend mieux pourquoi ça souffrait sur le mutu).
Un top à l'instant

top - 10:29:43 up 1:53, 1 user, load average: 0.01, 0.07, 0.07
Tasks: 216 total, 1 running, 214 sleeping, 0 stopped, 0 zombie
Cpu(s): 14.6%us, 3.1%sy, 0.6%ni, 77.6%id, 3.7%wa, 0.1%hi, 0.4%si, 0.0%st
Mem: 3475456k total, 1606404k used, 1869052k free, 0k buffers
Swap: 921600k total, 0k used, 921600k free, 0k cached

A quoi correspondent les 214 sleeping ? Des processus apaches en attente ?