Utiliser LXC avec Apache + MariaDB.
Sur mes deux conteneurs LXC 1 et 2 j'ai installé ce qui suit :
1) Apache2 + Opcache (448Mo RAM/ 640Mo RAM+SWAP), sur le CPU 3.
Installation d'une copie du site ...
Configuration du site pour Apache en HTTPS, y compris une installation des clefs SSL du site réel, cela me signalera une erreur lors de l'accès puisque le nom de site est modifié.
Reconfiguration de l'accès à la base de données vers ma deuxième instance de machine LXC dédiée à MariaDB.
2) Mariadb (512Mo RAM / 768Mo RAM+SWAP) sur le CPU 2
Installation d'une copie de la base du site et création d'un user adéquat.
Après quelques ajustements l'accès au site est correct (sauf erreur SSL signalée comme prévu), mais on peut passer outre et cela n'influence pas le système de test adopté.
La machine dédiée au site "KVM" est, elle aussi, limitée aux CPU 2 et 3 (même machine) et possède 1536 Mo de RAM + 2Go de swap.
Premier test :
L'accès est apparemment aussi rapide que sur la version standard du site qui est installée dans une machine virtuelle KVM (Apache et MariaDB) avec 1536Go de mémoire et deux processeurs.
Tests comparés chiffrés.
Les tests ont été réalisés avec le programme "siege" paramétré comme suit :
- 7 users en parallèle
- Durée de 3 minutes
- Fichier de l'ensemble des pages du site extrait du fichier "sitemap.xml"
- Prise des mesures CPU sur la machine physique avec "sar" et quelques scripts de mise en forme, les graphes sont réalisés avec OpenOffice sur les données "sar" mises en forme par les scripts.
Les tests ont été réalisés deux fois pour chaque "site" :
- Premier test juste après démarrage
- Deuxième test peu après
Quelques résultats tirés de ces tests.
Machine « KVM » | Machine « LXC » | |||||
TEST 1 : après démarrage des machines | ||||||
Transactions: | 38450 | hits | 67415 | hits | ||
Availability: | 100.00 % | 100.00 % | ||||
Elapsed | time: | 179.95 | time: | 179.69 | secs | |
Data | transferred: | 537.99 | transferred: | 941.41 | MB | |
Response | time: | 0.03 | time: | 0.02 | secs | |
Transaction | rate: | 213.67 | rate: | 375.17 | trans/sec | |
Throughput: | 2.99 | MB/sec | 5.24 | MB/sec | ||
Concurrency: | 6.91 | 6.92 | ||||
Successful | transactions: | 36335 | transactions: | 63621 | ||
Failed | transactions: | 0 | transactions: | 0 | ||
Longest | transaction: | 1.52 | transaction: | 2.98 | ||
Shortest | transaction: | 0.00 | transaction: | 0.00 | ||
TEST2 : à la suite du 1 | ||||||
Transactions: | 53626 | hits | 68353 | hits | ||
Availability: | 100.00 | % | 100.00 | % | ||
Elapsed | time: | 179.21 | time: | 179.76 | secs | |
Data | transferred: | 749.06 | transferred: | 954.27 | MB | |
Response | time: | 0.02 | time: | 0.02 | secs | |
Transaction | rate: | 299.24 | rate: | 380.25 | trans/sec | |
Throughput: | 4.18 | MB/sec | 5.31 | MB/sec | ||
Concurrency: | 6.85 | 6.92 | ||||
Successful | transactions: | 50610 | transactions: | 64540 | ||
Failed | transactions: | 0 | transactions: | 0 | ||
Longest | transaction: | 2.19 | transaction: | 1.20 | ||
Shortest | transaction: | 0.00 | transaction: | 0.00 |
J'aussi mesuré la consommation CPU lors de ces tests, et voici quelques graphes de consommation.
On peut remarquer une consommation du CPU 1 parfaitement parallèle à celle du CPU 2 qui est celui consacré à la base de données, après les lectures initiales la base fonctionne sur les caches, il s'agit donc probablement de la charge due aux IO initiales de la base de données.
Le CPU "Apache" est proche de 100%, celui de la base de données stagne à moins de 20% après un plateau à 40%.
Les deux CPU sont proches de 100% (mesure faite sur la machine physique).
On constate un "rendement" meilleur du site "LXC" dont la consommation CPU totale est inférieure et le débit assez nettement supérieur.