Tag: cache

Serveur dédié : installer et configurer Varnish 4

16 August 202427 octobre 2014 by Matt Biscay · Lecture: 11 minutes

Cette semaine, j’ai décidé de mettre mon installation de Varnish à jour.

La version 3.0.5 date de décembre 2013 et il est temps de mettre le serveur à jour pour bénéficier des dernières nouveautés et corrections de bugs. Nous passons donc de Varnish 3 à Varnish 4.

Cela ne se fait pas sans peine car chez Varnish, ils renomment certaines directives d’une version à l’autre… ce qui fait planter le serveur Varnish puisqu’il ne reconnait plus les directives.

Résultat : le fichier de configuration de la version précédente plantera obligatoirement sous la dernière version !

Ce tutoriel en 3 étapes nous donnera l’occasion de mettre à jour Varnish et de scinder notre fichier de configuration en plusieurs modules de manière à en simplifier l’édition et la maintenance futures.

Etape 1 : mise à jour des dépôts Varnish

Pour mettre à jour Varnish, il suffit de pointer apt vers les derniers dépôts à jour. On édite donc /etc/apt/sources.list :

nano /etc/apt/sources.listCode language: PHP (php)

et on y met à jour nos dépôts:

# varnish
deb http://repo.varnish-cache.org/debian/ wheezy varnish-4.0Code language: PHP (php)

On rafraîchit la liste des paquets et on lance la mise à jour :

apt-get update && apt-get upgradeCode language: JavaScript (javascript)

Varnish est maintenant mis à jour mais loin d’être fonctionnel étant donné que le format du fichier de configuration a changé.

Etape 2 : le nouveau fichier de configuration de Varnish 4 pour WordPress

Certaines directives ont changé de nom et, malgré avoir lu le guide de migration officiel, j’ai modifié mon fichier de configuration en corrigeant les erreurs une à une. Cela prend du temps mais au final, le fichier est plus clair qu’avant.

OVH : activez PHP-FPM sur votre hébergement

28 December 202318 octobre 2013 by Matt Biscay · Lecture: 3 minutes

OVH est en pleine implémentation du module PHP-FPM sur ses offres, (et ici dans leur guide), ce qui permettrait selon la team OVH “d’accélérer les temps de réponses de PHP et d’obtenir des performances jusque 7 fois plus rapides dans nos labos par rapport au moteur actuel”.

Activation de PHP-FPM

Pour activer ce mode sur votre offre, il suffit de créer un fichier .ovhconfig à la racine de l’arborescence FTP, dans le dossier parent du répertoire /www.

Si vous souhaitez activez PHP 7, voici ce que doit contenir votre .ovhconfig:

app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production

Si vous souhaitez activez PHP 5.6, voici ce que doit contenir votre .ovhconfig:

app.engine=php
app.engine.version=5.6
http.firewall=none
environment=production

PHP: résoudre l'erreur "file_get_contents(): SSL operation failed with code 1" photo

PHP : les bons en-têtes pour permettre la mise en cache d’une page

27 March 202429 octobre 2012 by Matt Biscay · Lecture: 1 minute

Je me suis rendu compte qu’un des fichiers javascript d’un plugin WordPress est appelé sur chaque article du site et qu’il n’est pas mis en cache par défaut…

C’est très moyen au niveau optimisation étant donné que c’est typiquement le genre de fichier statique qui n’est pas prêt d’être modifié.

Voici donc les en-têtes (headers) qui vont nous permettre de mettre un fichier en cache en PHP :

<?php
/*
|--------------------------------------------------------------------------
| Enable Caching with PHP headers by Matt - www.skyminds.net
|--------------------------------------------------------------------------
|
| Let's set it to 90 days caching.
| seconds, minutes, hours, days 
|
*/
$expires = 60*60*24*90;

header('Pragma: public');
header('Cache-Control: maxage='.$expires);
header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$expires) . ' GMT');Code language: HTML, XML (xml)

Et voilà, page mise en cache.

Cela fait moins de requêtes sur le serveur puisque le navigateur n’a pas besoin de redemander la page à chaque visite.

Serveur dédié : analyse des performances du serveur

9 April 202230 juin 2011 by Matt Biscay · Lecture: 2 minutes

Cela fait quelques mois que le nouveau serveur est en place et il est temps de faire un petit bilan au niveau des performances.

Charge processeur

Tout d’abord, bien que le serveur soit équipé des mêmes caractéristiques techniques (même CPU, même quantité de RAM), il s’avère qu’il est beaucoup plus réactif que l’ancien.

Le processeur n’est plus surchargé en permanence et lorsque l’on lance un top, la charge du processeur est le plus souvent entre 0.05 et 0.20, ce qui est idéal.

A titre de comparaison, l’ancien serveur avait une charge souvent supérieure à 2.

Analyse du temps de chargement des pages via Google Webmaster Tools

Il y a quelques semaines, je me suis connecté sur Google Webmaster Tools et lorsque j’ai atteint le graphique du temps de chargement des pages du site, j’ai eu l’agréable surprise de découvrir ceci :

Serveur dédié : installer la dernière version d’APC par SVN

9 April 202220 juin 2011 by Matt Biscay · Lecture: 1 minute

Notre serveur ayant besoin de mettre les données en cache pour plus d’efficacité, il peut s’avérer intéressant de maintenir APC à jour via SVN, histoire d’être sous une version “bleeding-edge”.

Méthode automatique : installation d’APC via Dotdeb

Commencez par ajouter les dépôts Dotdeb à la configuration APT.

Ensuite, il suffit d’installer APC avec :

apt-get install php-apcCode language: JavaScript (javascript)

Configuration d’APC

J’ai un peu tweaké ma configuration d’APC par rapport au précédent article. Éditez apc.ini :

nano /etc/php/7.4/conf.d/apc.ini

et ajoutez-y :

extension=apc.so
apc.enabled=1
apc.shm_size=128M
apc.stat=0
apc.ttl=7200
apc.user_ttl=7200
apc.enable_cli=1
apc.max_file_size=10M
apc.rfc1867 = On

Et on relance Apache :

/etc/init.d/apache2 restart

Voilà, vous possédez la dernière version d’APC sur votre serveur. L’opération est à renouveler de temps à autre, histoire d’être toujours à jour.

Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances

5 April 202207 mai 2011 by Matt Biscay · Lecture: 5 minutes

Allez, on continue d’optimiser notre serveur : aujourd’hui, je vous montre comment améliorer nettement les performances du serveur.

Nous allons d’abord installer un système de cache – j’ai choisi APC – qui va soulager un peu le système en mettant en cache les pages du site les plus demandées.

Cela aura un impact sur le temps de traitement des pages (moins de traitement PHP) et sur la base de données (moins de requêtes SQL).

Dans un second temps, nous installons Varnish comme reverse-proxy pour Apache : tous les objets statiques (images, CSS, JS) seront traités par Varnish, le reste (PHP) sera traité par Apache. Cela divise sensiblement la charge serveur.

Installation d’APC

APC est un système de cache que je trouve très performant. On l’installe avec :

pecl install apc

puis on crée le fichier de configuration :

nano /etc/php/7.4/conf.d/apc.ini

et on y ajoute :

extension=apc.so
apc.enabled=1
apc.shm_size=128M
apc.stat=0
apc.ttl=7200
apc.user_ttl=7200
apc.enable_cli=1
apc.max_file_size=10M
apc.rfc1867 = On

Migration de serveur : Kimsufi 250G

18 February 202412 février 2011 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, je vous donne les quelques news techniques du site.

Serveur Kimsufi 500G

Cela fait presque un an que SkyMinds.Net tourne sur un serveur dédié hébergé chez OVH. Le serveur était un Kimsufi avec 500 Go de disque dur.

Quelques jours seulement après le transfert du site, OVH annonce le Kimsufi avec 250 Go mais… à moitié prix ! Et on ne peut rendre un serveur Kimsufi pour un autre, il s’agit de deux achats séparés.

Au niveau des performances, je dirai que mon Kimsufi 500G n’était pas terrible : il était constamment surchargé et j’avais l’impression de devoir relancer les services régulièrement pour assurer la disponibilité du service. Pas cool du tout.

SkyMinds.Net hébergé chez OVH

18 February 202415 mars 2010 by Matt Biscay · Lecture: 3 minutes

Vous ne l’avez peut-être pas remarqué mais le site a été transféré sur un nouveau serveur : changement d’hébergeur donc. Le site quitte l’Angleterre pour venir s’installer en France, chez OVH.

D’ailleurs, si vous pouvez lire cet article, cela veut dire que la propagation DNS est terminée et que je n’ai pas fait trop de bêtises.

Le serveur

Le serveur est un serveur dédié à base de Celeron 1.2 Ghz avec 2 Go de RAM donc cela devrait changer d’un hébergement mutualisé avec des centaines de sites hébergés sur le même serveur.

Là, je suis tout seul : il y a le site bien sûr mais aussi tous les services connexes tels que le serveur FTP, le serveur de mail, le serveur DNS etc.

Tout cela tourne sur la même machine donc finalement, ce qui sur le papier a l’air très bien l’est un peu moins une fois que tout est configuré.

WordPress : utilisation d’un système de cache

10 March 202413 mai 2008 by Matt Biscay · Lecture: 3 minutes

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.

WordPress : réduire le nombre de requêtes SQL des thèmes

26 September 202425 mars 2008 by Matt Biscay · Lecture: 2 minutes

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.

Des URLs statiques

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).

WordPress : réduire le nombre de requêtes SQL des plugins

7 April 202214 mars 2008 by Matt Biscay · Lecture: 2 minutes

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.

Etape 1 : réduire le nombre de 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.