Et ça continue,

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

Dans cette partie, on va laisser proxmox et le réseau de coté pour se concentrer sur la VM qui fait office de serveur web.
On va s’attaquer à un peu tous les éléments d’un serveur qui impacte le temps de rendu d’un site : Mysql/Apache2/PHP/Wordpress

Bon pour premièrement, on va utiliser une commande assez simple permettant de vérifier nos optimisations.

ab -t30 -c5 //blog.mondomaine.com/

C’est un tools de Apache nommé ApacheBench et qui permet de faire plein de requêtes sur une url unique.
C’est beaucoup moins réaliste et complet que le test précédent, mais ça peut se faire en local et c’est simple à lancer.
Vous pouvez le relancer en boucle à différents point du tuto pour suivre l’évolution de perf.

Ajoutons quelques tools

Installation de Memcache & Xcode :

aptitude install libcache-memcached-perl php5-memcache memcached
aptitude install php5-xcache

Et modifier /etc/php5/conf.d/xcache.ini

xcache.size = 64M

Pour Mysql

Hum … j’ai la flemme donc ca sera mysqltuner

aptitude install mysqltuner
mysqltuner

C’est un script bien connu qui va s’occuper de vous suggérer des optimisations en fonction de votre utilisation.
Il est vivement conseillé de l’exécuter après des heures/jours d’usage de votre site.
Voici le type d’informations qu’il fournit :

General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
tmp_table_size (> 50M)
max_heap_table_size (> 50M)

Passons à Apache

Donc toujours dans /etc/apache2/apache2.conf

StartServers 4
MinSpareServers 4
MaxSpareServers 12
MaxClients 200
MaxRequestsPerChild 10000

KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 5
Timeout 50

/etc/init.d/apache2 restart

Passons à WordPress

Pour wordpress c’est assez simple, il faut installer le plugin suivant : W3 Total Cache
C’est un plugin qui va vous permettre de configurer l’utilisation automatique de cache par wordpress.

Donc une fois l’installation terminée, se rendre dans Performance > General Settings :

• Page Cache ( Enabled + Memcached )
• Database Cache ( Enabled + Memcached )

Et là normalement, en quelques minutes, on a un blog qui va vraiment bien mieux répondre.

Finissons par un retour à Nginx

Ce n’est pas vraiment une optimisation, plus par sécurité qu’autre chose.
Mais on va rajouter quelques règles à notre nginx (donc toujours /etc/nginx/nginx.conf)

# Limit Connexion
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
limit_conn perip 50;
limit_conn perserver 800;

# Limit Request (50r/s avec des burst 200r lors des chargements de pages)
limit_req_zone $binary_remote_addr zone=req_perip:10m rate=50r/s;
limit_req zone=req_perip burst=200;

Ça semble assez clair, ça permet de limiter le nombre de connexions/requêtes par ip.
Ces règles sont vraiment permissives, c’est plus pour éviter des emmerdes qu’autre chose.
Un utilisateur qui fait plus de 50requetes seconde ou plus de 50 connexions a un gros problème ou cherche à faire une connerie.

Et voilà

P.S. j’ajoute un bonus finalement. Un élément encore un peu plus tricky et donc totalement à vos risques et périles 😛

Bonus track : Passer à Apache 2 Worker et PHP FastCGI (totalement optionnel)

La procédure est assez simple, mais permet de gagner en perf/stabilité. Par contre cette solution n’est pas threadsafe toussa toussa.
Pour l’install :

apt-get install apache2-mpm-worker libapache2-mod-fcgid php5-cgi

On active le module apache

a2enmod fcgid

Et après le plus chiant, c’est qu’il va falloir aller modifier ses host présents dans /etc/apache2/sites-enabled/
Pour remplacer tous les

<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>

par des

<Directory />
<strong>AddHandler fcgid-script .php
FCGIWrapper /usr/lib/cgi-bin/php5 .php</strong>
Options <strong>ExecCGI</strong> FollowSymLinks
#Options FollowSymLinks
AllowOverride All
</Directory>

Sans ça, vous n’aurez tout simplement plus de php, quand je vous avez dit que c’était un peu tricky 🙂

P.S. pour vous donner un ordre d’idée, sur le blog avec le même outil que celui de départ, voilà le type d’info que j’obtiens :

Total transferred:      346811329 bytes
HTML transferred:       344570593 bytes
Requests per second:    274.49 [#/sec] (mean)
Time per request:       36.431 [ms] (mean)
Time per request:       3.643 [ms] (mean, across all concurrent requests)
Transfer rate:          11289.00 [Kbytes/sec] received

J’étais au départ aux alentours de ~10 Requests per Second, ce qui fait grosso modo x20 sans avoir passé trop de temps, ni changé de serveur.
Pour rappel ce nombre ne prend en compte que la page php, par les fichiers static eux géré par le nginx en frontend.
Je referai un jolie graph de benchmark à l’occasion.