J’avais fait une petite rétrospective en 2007 avec l’évolution de la fréquentation, voici où nous en sommes aujourd’hui :
Plus de 11 millions de pages consultées en 2008 – wow !
J’avais fait une petite rétrospective en 2007 avec l’évolution de la fréquentation, voici où nous en sommes aujourd’hui :
Plus de 11 millions de pages consultées en 2008 – wow !
Je viens d’effectuer une jolie petite optimisation qui devrait bien alléger le serveur sur lequel nous tournons. Vous vous souvenez de l’article WordPress : réduire le nombre de requêtes SQL des thèmes, écrit il y a quelques mois ?
Et bien il se trouve que j’avais tout optimisé tous les fichiers de mon thème – sauf le menu du site qui se trouve dans le fichier header.php
!
Ce dernier contenait quasiment une trentaine de requêtes SQL destinées à obtenir les permalinks des pages statiques…
Je m’étais dit à l’époque que si je changeais le permalink d’une page, cela se reflèterait immédiatement dans le menu. Quand j’y pense aujourd’hui, c’est vraiment ridicule.
Si votre blog génère beaucoup de trafic, il y a fort à parier que votre consommation des ressources serveurs ira en augmentant : plus vous écrivez d’articles et plus vous avez de pages, plus vous avez de visiteurs sur le site.
Le problème, c’est que les multiples appels à la base de données pour extraire le contenu des articles peut entraîner des ralentissements, voire des erreurs lors de l’affichage de vos pages en périodes de pointe.
La solution consiste à utiliser un système de cache de fichiers. Pour SkyMinds, j’ai testé tout ce que j’ai pu trouver pour tenter d’endiguer le trafic qui ralentissait le serveur. Voici les conclusions auxquelles je suis arrivé, au bout de multiples expérimentations.
Pensez à faire une sauvegarde de votre fichier .htaccess avant de commencer.
J’ai mis à jour WordPress hier, entre deux corrections de copies. D’habitude lorsque je fais une grosse mise à jour, je la fait d’abord sur mon installation locale, sur ma machine.
Cela me permet de déceler les problèmes éventuels et de ne pas planter la base du site.
Cette fois-ci, non seulement je l’ai faite en locale mais je l’ai en plus faite sur un sous-domaine, histoire d’être vraiment sûr de mon coup. Mais cette fois-ci j’ai eu droit à une grosse étape supplémentaire, nécessaire pour la pérennité du site…
Après avoir vu comment réduire les accès des plugins, voici comment réduire le nombre d’accès à la base de données en modifiant vos fichiers de thèmes.
Il est possible de supprimer jusqu’à une bonne vingtaine d’appels à la base de données rien qu’en éditant les fichiers de votre thème. Les fichiers les plus gourmands sont header.php, sidebar.php et footer.php
. Vous pouvez remplacer :
bloginfo('charset')
par l’encodage de vos pages : UTF-8.bloginfo('stylesheet_url')
par l’URI statique de votre feuille de style.bloginfo('rss2_url')
par l’URI statique de votre flux RSS.bloginfo('pingback_url')
par l’URI statique de votre serveur XML-RPC.bloginfo('url')
par l’URI statique de votre blog (sans le slash final).Suite aux deux précédents avertissements de mon hébergeur, j’ai pris quelques mesures pour tenter d’endiguer les requêtes superflues au niveau du serveur et d’optimiser mon installation WordPress en général. Aujourd’hui, on essaie de réduire le nombre de requêtes SQL de nos plugins.
Une installation par défaut de WordPress est assez light au niveau des ressources SQL. Le problème, c’est que l’on a bien souvent tendance à ajouter des plugins à son installation de base qui finissent par ralentir l’ensemble du site. Peut-être même possédez-vous des plugins qui sont devenus obsolètes ou redondants s’ils ont été inclus dans le code source de WordPress. Faîtes un peu le ménage et supprimez les plugins dont vous ne vous servez pas.
Il y a quelques jours, mon hébergeur a mis à jour son serveur Apache qui est passé de la version 1.3.37 à la version 2.2.6.
Gros changement donc mais dont je ne me suis réellement rendu compte que lorsque j’ai voulu poster un nouvel article sur le site.
Je me suis trouvé nez à nez avec cette erreur :
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 139816 bytes) in /home/cpanel/public_html/wp-includes/cache.php on line 51
Petit mail au support qui, une fois n’est pas coutume, ne sait pas comment résoudre le problème. Etrange.
On voit bien que c’est un problème de mémoire pourtant : Apache 2 serait-il plus gourmand qu’Apache 1 ? 8 Mo seraient-ils insuffisants ?
Si vous avez suivi le tutoriel Créer son propre serveur FTP avec Filezilla Server, vous vous êtes peut-être demandés comment permettre l’accès à vos visiteurs à plusieurs répertoires.
Par défaut, lorsque vous créez un compte utilisateur, celui-ci n’a accès qu’à un seul répertoire de travail : le home directory.
Il est cependant très facile d’ajouter d’autres répertoires en créant des alias. Cela ne prend que quelques secondes et trois étapes.
Suite à une discussion à propos de WordPress entamée avec Claude, je me suis dit qu’il était temps que je vous parle un peu des solutions pour installer un serveur web chez soi.
Si vous prônez l’usage de logiciels libres, vous opterez certainement pour le trio Apache (serveur web), PHP (pages dynamiques) et MySQL (SGDB relationnel).
Je n’entre pas dans l’installation individuelle des 3 serveurs, cela pourra faire l’objet d’un tutoriel ultérieur.
Pour les gens pressés ou dont les ressources systèmes sont moindres (clés USB, portables), je vous conseille WAMP si vous tournez sous Windows.
WAMP est un installeur d’environ 18 Mo qui vous installe Apache, PHP, MySQL, SQlite et PHPmyadmin en moins de deux minutes chrono sur votre machine.
Une petite icône dans la barre des tâches et vous pouvez accéder à tous les services et autres raccourcis utiles (vos projets, PHPmyadmin…).
WAMP est mis à jour régulièrement, est compatible avec Vista et inclus les dernières versions des différents serveurs. Il possède également des add-ons très pratiques.
Vraiment utile lorsque vous devez tester un script PHP vite fait ou que vous souhaitez faire des tests sur une copie locale de votre projet.
Pour voir la différence entre une webradio maison montée avec Winamp et Icecast, je me suis lancé dans la création d’une autre webradio qui utilise toujours le serveur IceCast avec cette fois SAM Broadcaster, une solution plus professionnelle (et payante également).
Voici donc les quelques étapes pour monter votre propre webradio avec ce logiciel. Temps estimé : 20-25 minutes.
Installez SAM Broadcaster dans le répertoire par défaut et choisissez l’option MySQL pour la gestion de vos playlists. D’après mes tests répétés et infructueux, l’installeur ne trouve pas les bases SQL distantes.
J’ai donc utilisé mon installation MySQL existante.
Si vous ne possédez pas MySQL sur votre machine, téléchargez-le et installez avec les options par défaut. L’installation de SAM est maintenant terminée.
J’ai aujourd’hui mis à jour le plugin DSP Oddcast pour Winamp dont la mise à jour concerne principalement l’amélioration de la compatibilité des metadata.
J’en ai donc profité pour me documenter un peu sur les metadata, comme me l’avait demandé Rizz.
La question est donc posée : que sont véritablement les metadata et à quoi servent-elles ?
Les métadatas sont des données qui servent à donner des informations sur la musique que votre webradio diffuse.
Il s’agit d’un ensemble de tags qui sont directement intégrés dans la plupart des formats audios modernes (OGG, WMA) et qui ont également été ajoutés dans les formats plus vieux (MP3 par exemple) avec notamment les tags ID3v1 puis ID3v2.
Donc lorsque vous jouez un morceau dans votre lecteur audio, les informations qui défilent (titre, artiste, album…) sont considérées comme des metadata.
On a parfois besoin d’avoir à notre disposition un espace disque suffisant pour pouvoir partager des fichiers, images, vidéos avec des amis.
Le problème, c’est qu’on ne peut pas toujours les envoyer par email ou utiliser un système peer-to-peer parce qu’on n’a pas forcément envie de partager nos fichiers avec le tiers de la planète.
La solution consiste donc à créer un serveur FTP (File Transfer Protocol, optimisé pour les transferts de fichiers) en utilisant l’espace de notre disque dur et la bande passante de notre connexion internet.
Ce tutoriel – facilement adaptable à n’importe quel serveur FTP – prend FileZilla Server pour exemple, car il est open-source et gratuit.
La mise en place et la configuration du serveur prend environ 5-10 minutes.