Doezer
28/05/2015, 19h58
Envoyé par sloomy
Je n'ai pas encore eu le temps d'y travailler. Vu qu'OVH propose un mois de cloud gratuit, je vais en profiter pour m'y mettre.
Machine mal dimensionnée ?
Envoyé par sloomy
Je n'ai pas encore eu le temps d'y travailler. Vu qu'OVH propose un mois de cloud gratuit, je vais en profiter pour m'y mettre.
sloomy
17/05/2015, 21h51
Bonjour,
Avez-vous solutionné votre problème ?
Cordialement,
Avez-vous solutionné votre problème ?
Cordialement,
Doezer
17/05/2015, 13h05
Envoyé par buddy
Salut,
Je faisais du caching avant via un plugin WP mais je l'ai enlevé car ça ne changeait rien au temps de réponse. Niveau visiteurs, en moyenne c'est du 100-120/jour (ça peut monter pas mal en fonction du contenu) donc rien de très demandeur non plus.
Le serveur est à jour, mais de toute manière c'est un problème que j'ai depuis mi-2013.
buddy
13/05/2015, 20h14
Salut,
pour le "Leverage browser caching"
çà se fait très vite via ceci :
http://www.how-to.ovh/viewtopic.php?t=71
Pour le reste, l'atom reste quand même un petit CPU ... selon le nombre de visiteurs que tu as, çà peut vite saturer, idem pour les 4 Go de ram ...
ton serveur est bien à jour ?
apt-get update && apt-get upgrade -y
pour le "Leverage browser caching"
çà se fait très vite via ceci :
http://www.how-to.ovh/viewtopic.php?t=71
Pour le reste, l'atom reste quand même un petit CPU ... selon le nombre de visiteurs que tu as, çà peut vite saturer, idem pour les 4 Go de ram ...
ton serveur est bien à jour ?
apt-get update && apt-get upgrade -y
Doezer
13/05/2015, 18h56
Merci de vos réponses rapides.
BBR, j'avais déjà utilisé ce site, qui est d'ailleurs très bien fichu. Il y en a pas mal dans ce genre là. Le problème c'est que tout n'est pas forcément facilement changeable via un CMS comme wordpress.
Janus, je tiens compte de tes conseils et je pense que je ferais un test avec une machine de dev quand j'aurais un ou deux jours devant moi (malheureusement pas ce week-end ) Si cela se révèle payant, je ferais sûrement une réinstallation complète de ma machine principale. Cela doit bien faire trois ans que je l'ai, avec tous les configurations plus ou moins bancales que ça peut impliquer...
BBR, j'avais déjà utilisé ce site, qui est d'ailleurs très bien fichu. Il y en a pas mal dans ce genre là. Le problème c'est que tout n'est pas forcément facilement changeable via un CMS comme wordpress.
Janus, je tiens compte de tes conseils et je pense que je ferais un test avec une machine de dev quand j'aurais un ou deux jours devant moi (malheureusement pas ce week-end ) Si cela se révèle payant, je ferais sûrement une réinstallation complète de ma machine principale. Cela doit bien faire trois ans que je l'ai, avec tous les configurations plus ou moins bancales que ça peut impliquer...
janus57
13/05/2015, 14h07
Bonjour,
déjà perso je dirais d'éviter le monitoring manager qui peu ne pas être fiable, le mieux est de mettre son propre monitoring en place (un bon vieux munin suffit).
Ensuite si vous avez que des sites qui tourne sur des CMS, perso je passerais sous Ebian Jessie avec apache 2.4 et PHP5.6, activerais OPCache dans PHP, continuerais avec MySQL et au bout de 4jours je lancerais un mysqltuner + prime-tuner.sh pour voir si MySQL peu être optimisé.
Si avec ça le site n'est pas plus rapide je passerais sous PHP5-FPM plutôt que mod_php5 (qui consomme plus et aussi plus lent de par son fonctionnement).
Perso j'ai testé le couple Jessie + apache 2.4 (mpm-wworker, mais j'aurais du garder event après documentation) + pp5-fpm + MySQL avec un CMS, je suis passé d'un temps de génération PHP de 0.200s à 0.050s juste avec OPCache (sans optimisation à côté, comme la désactivation de la lecture .htaccess ou optimisation MySQL).
OPCache : https://php.net/manual/fr/intro.opcache.php
PHP5-FPM : https://packages.debian.org/fr/jessie/php5-fpm
apache2.4 (par défaut mpm-event sous Jessie) : https://packages.debian.org/fr/jessie/apache2
MySQL : https://packages.debian.org/fr/jessie/mysql-server-5.5
MariaDB (qui remplacera surement MySQL dans stretch) : https://packages.debian.org/fr/jessie/mariadb-server
PHP5-FPM couplé avec Apache 2.4 en mode MPM-EVENT devrait bien apprécier ton processeur qui a la technologie Inntel HT hors apache2.4 (mpm-event) et php5-fpm travail sur des threads et non des processus comme apache2 (mpm-prefork).
Cordialement, janus57
déjà perso je dirais d'éviter le monitoring manager qui peu ne pas être fiable, le mieux est de mettre son propre monitoring en place (un bon vieux munin suffit).
Ensuite si vous avez que des sites qui tourne sur des CMS, perso je passerais sous Ebian Jessie avec apache 2.4 et PHP5.6, activerais OPCache dans PHP, continuerais avec MySQL et au bout de 4jours je lancerais un mysqltuner + prime-tuner.sh pour voir si MySQL peu être optimisé.
Si avec ça le site n'est pas plus rapide je passerais sous PHP5-FPM plutôt que mod_php5 (qui consomme plus et aussi plus lent de par son fonctionnement).
Perso j'ai testé le couple Jessie + apache 2.4 (mpm-wworker, mais j'aurais du garder event après documentation) + pp5-fpm + MySQL avec un CMS, je suis passé d'un temps de génération PHP de 0.200s à 0.050s juste avec OPCache (sans optimisation à côté, comme la désactivation de la lecture .htaccess ou optimisation MySQL).
OPCache : https://php.net/manual/fr/intro.opcache.php
PHP5-FPM : https://packages.debian.org/fr/jessie/php5-fpm
apache2.4 (par défaut mpm-event sous Jessie) : https://packages.debian.org/fr/jessie/apache2
MySQL : https://packages.debian.org/fr/jessie/mysql-server-5.5
MariaDB (qui remplacera surement MySQL dans stretch) : https://packages.debian.org/fr/jessie/mariadb-server
PHP5-FPM couplé avec Apache 2.4 en mode MPM-EVENT devrait bien apprécier ton processeur qui a la technologie Inntel HT hors apache2.4 (mpm-event) et php5-fpm travail sur des threads et non des processus comme apache2 (mpm-prefork).
Cordialement, janus57
BBR
13/05/2015, 14h00
utilise htop au lieu de top, c'est plus parlant (apt-get install htop )
la lenteur peut aussi venir de tes voisins de baie qui utilisent beaucoup de BP et comme il n'y a rien de garanti sur ks cela peut venir de là
regarde ce que tu peux améliorer en explorant les divers onglets :
http://gtmetrix.com/reports/www.krew...ce.fr/2bI0kPJT
http://gtmetrix.com/reports/www.baden-alba.org/qHHIG4pX
la lenteur peut aussi venir de tes voisins de baie qui utilisent beaucoup de BP et comme il n'y a rien de garanti sur ks cela peut venir de là
regarde ce que tu peux améliorer en explorant les divers onglets :
http://gtmetrix.com/reports/www.krew...ce.fr/2bI0kPJT
http://gtmetrix.com/reports/www.baden-alba.org/qHHIG4pX
Doezer
13/05/2015, 13h29
Bonjour à tous,
Je viens vous voir, pas pour un incident ponctuel mais plutôt pour essayer de résoudre les lenteurs dont mon serveur web est victime. Je ne suis pas assez compétent pour régler ma machine aux petits oignons et malheureusement, les tutos sont généralement soit obsolètes, soit à côté de la plaque... Car bien sûr, c'est le genre de problème qui se règle au cas par cas.
J'ai un KS-4G d'ancienne génération :
OS : Debian 6.0 LTS ("Squeeze")
Boot : 3.14.32 (Stable Kernel, with GRSec - 64bit)
CPU : Intel(R) Atom(TM) CPU N2800 @ 1.86GHz
HDD : 1To
Carte Mère : DN2800MT
Voilà deux sites présents sur la machine :
http://www.krewella-france.fr/
http://www.baden-alba.org/
Sont présents sinon :
- un serveur TS3
- un bot musical de temps à autre, mais qui n'influe pas
- un serveur Subsonic
- un serveur minecraft éteint
- serveurs mail
- quelques panels (raccourcisseur de liens, postfix admin, webmin, et munin)
Comme vous pouvez le constater, les deux sites sont suffisamment lents pour que cela soit une plaie à naviguer, le premier considérablement plus que l'autre, même avec un cache bien rempli. Les lenteurs sont présentes depuis aussi longtemps que je me souvienne.
Voici les graphes présents sur le manager OVH sur les 30 derniers jours :
CPU : http://i.imgur.com/fVAJ98e.png - Les 20% sont causés par le bot musical pour teamspeak qui, a priori, doit avoir quelques soucis. Mais même éteint, cela n'intervient pas.
RAM : http://i.imgur.com/r0UGTQS.png - rien de grave
SWAP : http://i.imgur.com/0tE33IY.png - pareil ici, il y a quelques mois je me suis rendu compte qu'elle plafonnait et j'ai agrandi la partition, mais cela n'a rien changé.
Load average : http://i.imgur.com/2UUPT8Y.png - rien d'extraordinaire
Au niveau MRTG, c'est pareil, rien d'affolant :
Trafic : http://i.imgur.com/KnQWw7F.png
Paquets : http://i.imgur.com/8hvnKcg.png
Et rien en erreur.
Vu ces graphes, la machine n'a pas l'air surdimensionnée pour le site.
J'ai joué un peu avec top, et à chaque chargement de la page, les process apache2 plafonnent à 99% CPU. Peut-être est-ce une piste ? J'ai un sentiment qui me dit que c'est à peu près logique.
Voilà ce que ça peut donner : http://i.imgur.com/L5esozD.png
Les deux sites utilisent tous les deux Wordpress, qui, on le sait tous, peut être une formidable usine à gaz si mal utilisé. Mais le fait est que si le premier comporte en effet 20 extensions activées en tout temps, le second, lui, n'en utilise que très peu (1 ou 2).
Advanced Page Manager : système permettant une gestion plus pointue des pages, uniquement visible sur le panel admin
Akismet : système anti-spam
Copyright Proof : gère le copyright par article
Google Analytics par Yoast : aide GA
Google XML Sitemaps v3 for qTranslate
iThemes Security : plugin de sécurité et de surveillance
Jetpack par WordPress.com : plugin officiel rajoutant pas mal de choses mais un peu usine à gaz
NextGEN Gallery by Photocrati : Gallerie d'images, un peu usine à gaz aussi
Opengraph and Microdata Generator : plug-in pour les meta données utilisées par FB
Page-list : rajoute quelques shortcodes
Scroll Back to Top
Social : diffusion vers les réseaux sociaux
Tabby Responsive Tabs : shortcodes permettant l'usage d'onglets
Тоp 10 : top 10 des articles visités
User Role Editor
WordPress SEO : aide SEO
WP-DBManager : optimise et gère la BDD : compression, nettoyage, réparation...
WP-Optimize : optimise WP (enlever brouillons, révisions d'articles...)
WP-Polls : sondages
YOURLS Link Creator : plugin pour le raccourcisseur de liens
Lorsque tous les plugins sont désactivés, on gagne quelque chose comme 2 secondes de chargement sur les 6-8 dont le serveur a besoin. Cela fait quelques temps que j'ai réalisé mes tests de latence mais j'en avais conclu que cela venait du temps de traitement par le serveur, d'où le fait que je suspect un pb de configuration côté apache. Les appels BDD ne me paraissent pas suffisamment nombreux pour que cela vienne de ce côté.
Voilà un scan avec P3 Plugin performance profiler :
http://i.imgur.com/oNjiqks.png
On voit que ce n'est pas cohérent avec le temps de chargement qui s'approche des 6 secondes.
Merci de votre aide.
Je viens vous voir, pas pour un incident ponctuel mais plutôt pour essayer de résoudre les lenteurs dont mon serveur web est victime. Je ne suis pas assez compétent pour régler ma machine aux petits oignons et malheureusement, les tutos sont généralement soit obsolètes, soit à côté de la plaque... Car bien sûr, c'est le genre de problème qui se règle au cas par cas.
J'ai un KS-4G d'ancienne génération :
OS : Debian 6.0 LTS ("Squeeze")
Boot : 3.14.32 (Stable Kernel, with GRSec - 64bit)
CPU : Intel(R) Atom(TM) CPU N2800 @ 1.86GHz
HDD : 1To
Carte Mère : DN2800MT
Voilà deux sites présents sur la machine :
http://www.krewella-france.fr/
http://www.baden-alba.org/
Sont présents sinon :
- un serveur TS3
- un bot musical de temps à autre, mais qui n'influe pas
- un serveur Subsonic
- un serveur minecraft éteint
- serveurs mail
- quelques panels (raccourcisseur de liens, postfix admin, webmin, et munin)
Comme vous pouvez le constater, les deux sites sont suffisamment lents pour que cela soit une plaie à naviguer, le premier considérablement plus que l'autre, même avec un cache bien rempli. Les lenteurs sont présentes depuis aussi longtemps que je me souvienne.
Voici les graphes présents sur le manager OVH sur les 30 derniers jours :
CPU : http://i.imgur.com/fVAJ98e.png - Les 20% sont causés par le bot musical pour teamspeak qui, a priori, doit avoir quelques soucis. Mais même éteint, cela n'intervient pas.
RAM : http://i.imgur.com/r0UGTQS.png - rien de grave
SWAP : http://i.imgur.com/0tE33IY.png - pareil ici, il y a quelques mois je me suis rendu compte qu'elle plafonnait et j'ai agrandi la partition, mais cela n'a rien changé.
Load average : http://i.imgur.com/2UUPT8Y.png - rien d'extraordinaire
Au niveau MRTG, c'est pareil, rien d'affolant :
Trafic : http://i.imgur.com/KnQWw7F.png
Paquets : http://i.imgur.com/8hvnKcg.png
Et rien en erreur.
Vu ces graphes, la machine n'a pas l'air surdimensionnée pour le site.
J'ai joué un peu avec top, et à chaque chargement de la page, les process apache2 plafonnent à 99% CPU. Peut-être est-ce une piste ? J'ai un sentiment qui me dit que c'est à peu près logique.
Voilà ce que ça peut donner : http://i.imgur.com/L5esozD.png
Les deux sites utilisent tous les deux Wordpress, qui, on le sait tous, peut être une formidable usine à gaz si mal utilisé. Mais le fait est que si le premier comporte en effet 20 extensions activées en tout temps, le second, lui, n'en utilise que très peu (1 ou 2).
Advanced Page Manager : système permettant une gestion plus pointue des pages, uniquement visible sur le panel admin
Akismet : système anti-spam
Copyright Proof : gère le copyright par article
Google Analytics par Yoast : aide GA
Google XML Sitemaps v3 for qTranslate
iThemes Security : plugin de sécurité et de surveillance
Jetpack par WordPress.com : plugin officiel rajoutant pas mal de choses mais un peu usine à gaz
NextGEN Gallery by Photocrati : Gallerie d'images, un peu usine à gaz aussi
Opengraph and Microdata Generator : plug-in pour les meta données utilisées par FB
Page-list : rajoute quelques shortcodes
Scroll Back to Top
Social : diffusion vers les réseaux sociaux
Tabby Responsive Tabs : shortcodes permettant l'usage d'onglets
Тоp 10 : top 10 des articles visités
User Role Editor
WordPress SEO : aide SEO
WP-DBManager : optimise et gère la BDD : compression, nettoyage, réparation...
WP-Optimize : optimise WP (enlever brouillons, révisions d'articles...)
WP-Polls : sondages
YOURLS Link Creator : plugin pour le raccourcisseur de liens
Lorsque tous les plugins sont désactivés, on gagne quelque chose comme 2 secondes de chargement sur les 6-8 dont le serveur a besoin. Cela fait quelques temps que j'ai réalisé mes tests de latence mais j'en avais conclu que cela venait du temps de traitement par le serveur, d'où le fait que je suspect un pb de configuration côté apache. Les appels BDD ne me paraissent pas suffisamment nombreux pour que cela vienne de ce côté.
Voilà un scan avec P3 Plugin performance profiler :
http://i.imgur.com/oNjiqks.png
On voit que ce n'est pas cohérent avec le temps de chargement qui s'approche des 6 secondes.
Merci de votre aide.