titiplanti Posté 29 Janvier 2007 Posté 29 Janvier 2007 Bonjour, J'ai depuis peu mon propre serveur : un petit kimsufi (ovh). J'ai dessus un site qui fait dans les 1000 visiteurs uniques / jour pour 3500 pages vues / jour. J'ai aussi un second site qui ne dépasse pas les 50 visites/jour. Le gros site utilise beaucoup la base mysql et aussi un script cgi pour afficher des images en LaTeX. J'ai des problèmes de rapidité. Les pages du gros site mettent minimum 10s à charger. J'ai déjà réussi à améliorer les choses en réduisant les paramètres du httpd.conf (le fichier de paramétrage d'apache) notamment le maxclients que je ne peux pas monter à plus de 15 (sinon le serveur fait le mort). En fait je ne sais pas du tout comment m'y prendre pour optimiser la rapidité du serveur pour que mes pages s'affichent à une rapidité normale. Je ne sais pas quels paramètres modifier. Et je ne sais pas avec quels outils mettre le pied à l'étrier. J'ai aussi lu à droite à gauche qu'on pouvait aussi optimiser l'accès à la base mysql ... Bref, mes questions sont diverses et variées. J'aimerais qu'on m'aide à débuter, qu'on m'indique le BABA, les outils indispensables, des premières lectures, etc. Merci d'avance.
Dan Posté 30 Janvier 2007 Posté 30 Janvier 2007 Bonjour, Le principal défaut du Kimsufi est le faible niveau de la RAM. 250MB de RAM pour un site faisant appel fréquent à une grosse base de données c'est vraiment peu. Et tu n'as pas assez de RAM que pour tirer avantage du cache mysql qu'on trouve dans les versions récentes... Le fait que tu doives mettre le MaxClients à 15 au lieu de 150 à l'origine démontre bien que ton serveur doit se mettre à swapper.
Tom_Pascal Posté 30 Janvier 2007 Posté 30 Janvier 2007 Bonjour titiplanti, Je pense malheureusement que tu ne peux pas forcément gagner suffisament en optimisation simplement en jouant sur des paramètres de configuration. Comme le dit for justement Dan, les serveurs LowCost font rapidement apparaître leurs limites (notament en RAM pour le kimsufi)... ce qui est logique car autrement OVH ou les autres hébergeurs ne loueraient plus de dédiés "classiques" sir les LowCost suffisaient à tout faire... Tu devrais donc à mon avis chercher à louer une solution plus adaptée à ton trafic : soit un dédié plus performant, soit utiliser une solution à base de plusieurs dédiés lowcost (un pour le frontal web, un pour le serveur de BDD, un pour l'envoi de mails...). A moins que tu puisse déjà tenter de mettre en place une solution pour mettre en cache un maximum de page (et ainsi limiter au minimum les opérations de lecture dans la BDD). As tu déjà regardé de ce côté-là ?
titiplanti Posté 30 Janvier 2007 Auteur Posté 30 Janvier 2007 Merci pour vos réponses. Elles répondent bien à la question que je n'ai pas posée : le serveur kimsufi est-t-il assez dimensionné. Je faisais donc fausse route ... Dan, tu indiques un maxclient à 150. C'est énorme ! (j'avais essayé aussi la dédibox à 1Go de RAM). C'est une valeur en dessous de laquelle tu estimes qu'il ne faut pas descendre ? Penses-tu que l'offre d'ovh immédiatement supérieure avec une RAM de 512Mo soit suffisante pour mes besoins actuels ? Tom, mettre mes pages en cache : je n'y crois pas trop étant donné que le coeur du site est le forum avec des membres qui l'utilisent à peu près comme un tchat ! Quant à dispatcher les capacités du site sur plusieurs serveurs ... ça me paraît assez compliqué à gérer et surtout un peu disproportionné par rapport à ma connaissance actuelle des serveurs !
Tom_Pascal Posté 30 Janvier 2007 Posté 30 Janvier 2007 Titiplanti, Pour la mise en cache, cela n'empêche pas : tu as peut-être quelques membres qui se servent du forum comme chat, mais il n'empêche qu'il doit surement y avoir énormément plus d'affichage de contenus que de posts créés (les visiteurs qui ne postent pas, les robots d'indexation qui passent par là...). Optimiser la partie "présentation des informations" en affichant une version en cache d'un topic (détruite automatiquement à chaque fois qu'un membre poste) devrait tout de même contribuer à alleger la charge du serveur SQL. Mais nous aurons surement l'occasion d'en reparler prochainement
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant