Accélérer un site wordpress

Posté par le 21 février 2012 Commentaires fermés

En discutant l’autre jour avec un ami utilisant pas mal la plateforme WordPress, l’idée est venue de parler des performances du moteur. Certains de ses sites étant assez utilisés, la performance n’est pas toujours au rendez-vous. L’idée est donc de propose une configuration un peu plus rapide et moins gourmande pour la machine.

Point de départ

On commence donc par une installation standard Debian Squeeze (dans mon cas), apache2 et la dernière version de WordPress. On va ajouter un article de type LoremIpsum pour remplir la page et regarder ce que ça donne. La machine est une machine virtuelle avec 512 Mo de RAM, rien de très follichon. Je vous la fais courte

ab -c 5 -n 10 'http://xxx/'
...
Total transferred:      131473 bytes
HTML transferred:       128633 bytes
Requests per second:    2.80 [#/sec] (mean)
Time per request:       1786.356 [ms] (mean)
Time per request:       357.271 [ms] (mean, across all concurrent requests)
Transfer rate:          35.94 [Kbytes/sec] received
...

Ouais, donc nativement comme ça, template de base, peu d’images on tourne à 2.8 requêtes par seconde. Temps moyen de réponse 1786 ms. Le programme ab n’est qu’un indicateur qui va nous permettre de mesurer l’amélioration. On peut utiliser d’autres outils de mesures de montée en charge d’un site web comme loadimpact par exemple.

Le plugin W3 Total Cache

Première chose qu’on va faire, c’est de mettre en place ce plugin. C’est assez vite fait, et l’amélioration est flagrande. C’est la version 0.9.2.4 au moment où j’écris ces lignes. J’installe le plugin, et je l’active, que se passe-t-il ? Rien ! Il va falloir en effet le configurer, et c’est là où beaucoup prennent peur !

Donc, dans la page Performance qui est apparue sur la gauche de mon écran, je choisis Preview tout en haut de la page , ce qui me permet de vérifier que le site est bien visible. Il est visible ? Alors je fais Deploy au même endroit. Que me dit ab cette fois ?

Total transferred:      133740 bytes
HTML transferred:       130610 bytes
Requests per second:    39.21 [#/sec] (mean)
Time per request:       127.507 [ms] (mean)
Time per request:       25.501 [ms] (mean, across all concurrent requests)
Transfer rate:          512.15 [Kbytes/sec] received

Déjà, il y a un mieux flagrant, d’ailleurs je dois augmenter le temps de test, car la réponse est trop rapide.

ab -c 50 -n 1000 'http://xxx/'
...
Total transferred:      13374000 bytes
HTML transferred:       13061000 bytes
Requests per second:    61.32 [#/sec] (mean)
Time per request:       815.336 [ms] (mean)
Time per request:       16.307 [ms] (mean, across all concurrent requests)
Transfer rate:          800.93 [Kbytes/sec] received
...

Plus de 60 requêtes par secondes, on a multiplié notre performance par plus de 20 !

Maintenant, sur le serveur, installons le paquet php-apc. Ce dernier va nous permettre de ne mettre en cache les requêtes au niveau php. Après avoir redémarré Apache, on doit voir apparaître l’option APC dans la section Page Cache qui doit être activée. On la choisit.

ab -c 50 -n 1000 'http://xxx/'
...
Total transferred:      13564000 bytes
HTML transferred:       13251000 bytes
Requests per second:    136.58 [#/sec] (mean)
Time per request:       366.081 [ms] (mean)
Time per request:       7.322 [ms] (mean, across all concurrent requests)
Transfer rate:          1809.17 [Kbytes/sec] received
...

Hum, ça commence à être pas mal non ? Plus de 130 requêtes par seconde.

Conclusion

Il y a encore beaucoup d’autres méthodes pour accélérer la réponse de WordPress, mais déjà, en quelques minutes, on lui a donné un bon coup de fouet. Ça fonctionne très bien sur une installation standard. Dans le cas du multisite, il y a des possibilités dont je parlerai dans un prochain article.

Samsung Galaxy Nexus et l’autonomie

Posté par le 7 février 2012 Commentaires fermés

Le week end dernier, je me suis payé un Samsung Galaxy Nexus. On trouve plein de revues sur ce téléphone, je vous laisse chercher ça sur Google. N’ayant pas de Galaxy SII, je ne le compare pas. En tous cas, bel appareil, agréable à utiliser, et un écran très réactif, presque pas de lag par rapport à mes autres Androids.

Par contre, la surprise a été au niveau de l’autonomie. Après avoir totalement chargé la batterie, le téléphone a tenu 10h avant d’atteindre 15%. Surtout que je l’ai assez peu sollicité. En recherchant un peu dans la configuration, j’ai constaté que le Wifi était activé 100% du temps, même quand le téléphone se met en veille… Je pensais que c’était parce que je n’étais pas couvert en 3G par mon opérateur et que le téléphone s’épuisait à scanner la 3G… Mais non, reconfigurer le wifi pour qu’il se coupe lorsque l’écran s’éteint a corrigé le problème. Pour aujourd’hui, j’obtiens:

Comme on peut le voir, en 8h, j’ai perdu 20%. J’ai un peu joué, un peu de maps et c’est tout. C’est beaucoup mieux qu’avant.

Pour gérer la mise en veille du Wifi, ça se trouve dans les paramètres. On choisit Wifi (pas sur la zone On/Off mais sur le mot Wifi.

   

Sur la page du wifi, on va sur les trois points verticaux pour faire apparaître le menu « Options avancées ».

On peut alors choisir « Wifi actif en veille » pour le désactiver.

Personnellement j’ai mis de le laisser actif en veille quand je suis sur chargeur. Ça permet de mettre toutes les applications à jour si besoin.

Et voilà, l’autonomie vient de prendre un coup de fouet !

Android ICS sur Acer Iconia A500

Posté par le 29 janvier 2012 Commentaires fermés

Cette fois, j’ai mis à jour ma tablette Iconia A500 avec la dernière version d’Android. Tout d’abord au niveau des pré-requis. J’avais une version GingerBread rootée, avec un recovery d’installé.

La ROM utilisée est celle de thor2002ro. Je l’ai trouvée sur le forum de TegraOwners puisque la section Iconia de chez XDA est un peu morte… J’ai dû réinstaller toutes les applications, la mise à jour nécessitant un full wipe. Tout fonctionne excepté l’appareil photo/caméra. La puce 3G intégrée à la version A501 ne fonctionne pas non plus. Vu que je ne me sers pas de la caméra, aucun soucis pour moi.

La méthodologie est simple si vous avez déjà installé une ROM alternative sur un périphérique Android. On récupère le ZIP et le GAPPS pour avoir le market et compagnie qu’on place sur la carte SD. Ensuite, redémarrage en Recovery. Là, on fait un wipe complet (option « Wipe data/Factory reset »). Ensuite on installe le fichier zip de la ROM et ensuite celui des gapps. Un reboot, et hop, on est avec ICS.

ATTENTION: faites bien un backup de vos données, la méthode efface toutes les données ou les applications installées. Et le market ne va pas les réinstaller automatiquement. De plus, si vous avez sauvegardé vos applications avec Titanium (ou autre), attention à ne pas restaurer d’applications systèmes d’une version GingerBread, elles sont évidemment incompatibles.

 

Android Ice Cream Sandwich (ICS) sur HTC Desire

Posté par le 21 décembre 2011 Commentaires fermés

Mise à jour du 7/2/2012: On est passé à la 0.3.9. Évidemment, encore un full-wipe depuis la 0.2. L’appareil photo fonctionne, les vidéos sont par contre saccadées. Le projet avance pas mal, à son rythme…

Mise à jour du 9/1/2012: La partie appareil photo fonctionne maintenant (mais est encore plutôt instable). Ça se passe dans la version 0.2.1, qui a vu un changement de framework. Par conséquent il est nécessaire de faire un full wipe pour passer de la 0.1.x à la 0.2.x.

Bien que très peu de téléphones aient été mis à jour officiellement en ICS, la publication du code source a déchaîné les développeurs de ROMs. À tel point qu’une ROM existe pour mon HTC Desire. Il est d’ailleurs intéressant de remarquer que le Nexus One n’aura pas ICS de façon « officielle » (c’est à dire mis à jour directement par Google ou l’opérateur), et que le Nexus One et le Desire sont extrêmement proches. Je suppose que ICS sera porté sur le Nexus One de manière similaire au Desire (qui a un peu plus de mémoire interne).

Les informations sont sur le site http://www.sandvold.as/ , ainsi qu’un thread sur xda. La ROM est encore beta (la 0.1.4 au moment où j’écris ces lignes) et donc pas encore super stable. Je l’utilise depuis quelques jours, et je dois dire qu’elle marche franchement pas mal. Il y a des défauts, l’appareil photo ne marche pas encore, et le Wifi est parfois un peu capricieux, mais pour consulter ses mail, facebook, twitter ou G+, ben ça tourne pas mal.

Les pré-requis sont d’avoir un partitionnement standard. J’ai donc du le restaurer, moi qui avait mis le partitionnement adapté à la ROM CyanogenMod. (voir sur http://alpharev.nl/ pour les tables des partitions et sur http://www.roms-au.com/faq/hboot/ pour l’explication des redimmensionnements), ainsi que d’avoir déjà installé une recovery facilement accessible. Il faudra de plus avoir une sdcard rapide (Classe 6 minimum) partitionnée avec une partition en ext (peut être en ext3 aussi…). En effet, il n’y a pas assez de place sur la mémoire interne du Desire pour mettre ICS ! C’est d’ailleurs la raison qui fait que le Nexus One n’est pas sensé avoir droit à sa mise à jour officielle.

Pour le reste, un full-wipe, installation de la ROM, installation d’un script pour utiliser la partition de la sdcard, et ça roule ! Attention, le premier boot est assez long.

C’est une beta, y’a des bugs, donc ce n’est pas fait pour une utilisation quotidienne…

Pour le reste, quelques screenshots de mon téléphone…

   

Récupérer la table des partitions après une fausse manip sous Linux…

Posté par le 2 novembre 2011 Commentaires fermés

Cet article fait suite à la mésaventure arrivée à un client. Lors d’une manipulation dangereuse (sfdisk…), il a totalement écrasé la table des partitions de son disque système. Fort heureusement il a laissé son système en marche, il ne l’a surtout pas redémarré.

 

Attention, cet article s’adresse à des utilisateurs confirmés. Si vous n’avez pas l’habitude de fdisk, ou que vous avez déjà redémarré votre machine, cet article n’est pas pour vous. Si vous perdez vos données, vous en êtes responsable. Ce n’est pas parce que ça a marché dans mon cas, que ça marchera dans le votre. Les commandes données ne sont pas complètes, il ne s’agit pas d’un tutoriel. L’explication sera parlante aux personnes capables de réaliser les commandes. Bref, tout ceci pour vous dire que je ne suis pas responsable en cas de soucis sur vos données.

 

Pourquoi c’est une bonne idée de ne pas l’avoir redémarré après l’erreur ?

Lors de son démarrage, le noyau a mémorisé la table des partitions de son disque de démarrage. C’est d’ailleurs pour ça qu’on doit redémarrer la machine, ou lancer l’outil partprobe après avoir modifié la table des partitions du disque de démarrage. Sinon, la table des partitions du disque est différente de la table des partitions mémorisée par le noyau…

Heureusement qu’il n’a pas lancé partprobe /dev/sda !

En fait, il a lancé la commande. Et c’est ce qui lui a mis la puce à l’oreille. Partprobe lui a répondu par pleins d’erreurs, qui pourraient être traduites par je ne peux pas changer la table des partitions dans le noyau, car les partitions utilisées ont été modifiées. En effet, sa partition / est forcément montée, et dans la nouvelle table des partitions, elle n’existe plus. Le noyau continue donc d’utiliser l’ancienne table, puisqu’il s’appuie sur cette ancienne table pour fonctionner.

La méthode.

L’idée repose sur le fait que justement, le noyau a gardé en mémoire l’ancienne table des partitions. On va donc regarder ce qu’il a en mémoire, et remettre la même chose sur le disque. La machine ne doit en aucun cas être arrêtée ou redémarrée tant que l’opération n’est pas complète. On pourra voir ce qu’il a en mémoire à l’aide des informations accessibles dans /sys.

[root@localhost ~]# cat /sys/block/hda/hda1/start
63
[root@localhost ~]# cat /sys/block/hda/hda1/size
208782

L’opération est à refaire pour chaque partition.

[root@localhost ~]# cat /sys/block/hda/hda2/start
208845
[root@localhost ~]# cat /sys/block/hda/hda2/size
16563015

Dans mon exemple, j’ai deux partitions:

  • hda1 commençant au secteur 63 de taille 208782 secteurs.
  • hda2 commençant au secteur 208845 de taille 16563015 secteurs.
C’est donc le moment de lancer fdisk, et de détruire toutes les mauvaises partitions qu’on a créé. Je ne détaillerai pas ces opérations. Une fois que notre table des partitions est vide, on peut mettre les valeurs qu’on a trouver:
Commande (m pour l'aide): p

Disque /dev/hda: 8589 Mo, 8589934592 octets
255 heads, 63 sectors/track, 1044 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système

Commande (m pour l'aide):

Les partitions sont affichées en cylindres, ce qui ne nous arrange pas. Passons les en secteurs avec la commande u

Commande (m pour l'aide): u
Modification des unités d'affichage/saisie à secteurs

Commande (m pour l'aide): p

Disque /dev/hda: 8589 Mo, 8589934592 octets
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 secteurs
Unités = secteurs de 1 * 512 = 512 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système

Commande (m pour l'aide):
Faisons notre partition 1, début 63 et taille de 208782. Attention, quand on précise la taille, on enlève 1 à la valeur trouvée dans /sys. Je dois avouer que je ne sais pas pourquoi, mais sinon, on ne tombe pas sur un nombre de cylindres entier… Si quelqu’un a une explication plus propre, je suis preneur ;) . Donc on fera +208781.
Commande (m pour l'aide): n
Action de commande
   e   étendue
   p   partition primaire (1-4)
p
Numéro de partition (1-4): 1
Premier secteur (63-16777215, par défaut 63):
Utilisation de la valeur par défaut 63
Dernier secteur ou +taille or +tailleM ou +tailleK (63-16777215,
par défaut 16777215): +208781

Commande (m pour l'aide): p

Disque /dev/hda: 8589 Mo, 8589934592 octets
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 secteurs
Unités = secteurs de 1 * 512 = 512 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/hda1              63      208844      104391   83  Linux

Commande (m pour l'aide):
Ça a l’air d’être ce qu’on veut. Seconde partition maintenant, début 208845 de taille 16563015, donc +16563014 pour fdisk:
Commande (m pour l'aide): n
Action de commande
   e   étendue
   p   partition primaire (1-4)
p
Numéro de partition (1-4): 2
Premier secteur (208845-16777215, par défaut 208845): 208845
Dernier secteur ou +taille or +tailleM ou +tailleK (208845-16777215,
par défaut 16777215): +16563014        

Commande (m pour l'aide): p

Disque /dev/hda: 8589 Mo, 8589934592 octets
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 secteurs
Unités = secteurs de 1 * 512 = 512 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/hda1              63      208844      104391   83  Linux
/dev/hda2          208845    16771859     8281507+  83  Linux

Et là, oh miracle, on a retrouvé notre table originale. Un reboot permet de vérifier ça (mais attention, si vous redémarrez et que vous n’avez pas passé les bonnes tailles, il faudra alors utiliser un outil de récupération de partitions, avec les risques d’erreurs que ça engendre…).