Kimsufi vs VPS 1&1: Hébergement « low cost » pour un site LAMP / eZ Publish
Dans la lancée des tests de solution d’hébergement dites « low Cost », et après divers posts Twitter, je me suis commandé un VPS 1&1 (serveur virtuel L) pour le confronter à ma petit Kimsufi OVH de « test », comme j’avais pu le faire avec l’offre Gandi pour les accès disque.
Configuration globale des machines
VPS 1&1
- Nbre CPU: 4
- RAM: 2 Go
- Disque: 20Go – Stockage sécurisé des données avec RAID 5
- Prix / mois: 11,95€ TTC/mois
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : Quad-Core AMD Opteron(tm) Processor 2352
stepping : 3
cpu MHz : 527.436
cache size : 512 KB
Serveur OVH Kimsufi
- Nbre CPU: 2
- RAM: 2 Go
- Disque: 250 Go SATA
- Prix / mois: 17,93€ TTC/mois
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 3.00GHz
stepping : 4
cpu MHz : 2999.890
cache size : 2048 KB
Environnement LAMP / eZ Publish
Afin d’effectuer des tests comparatifs les plus justes possible, j’ai installé sur la VM 1&1 les mêmes versions du socle LAMP que sur le serveur Kimsufi (versions différentes de Debian).
Version eZ Publish: ezpublishcommunity-4.4.0-with_ezc-gpl
Version eZFind: ezfind-2.3.0
Site eZ Publish utilisé: Site « Company » de base disponible avec le setup
VPS 1&1
s15763544:~# sh env_lamp.sh Server version: Apache/2.2.17-MartY (Unix) Server built: Aug 25 2011 12:23:19 PHP 5.2.17 (cli) (built: Aug 25 2011 18:50:39) + APC 3.1.2
Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies mysql Ver 14.12 Distrib 5.0.51a, for unknown-linux-gnu (x86_64) using EditLine wrapper memcached 1.4.5 s15763544:~# cat /etc/debian_version 5.0.8
Serveur OVH Kimsufi
root@srv1:~# sh env_lamp.sh Server version: Apache/2.2.17-MartY (Unix) Server built: Mar 5 2011 11:21:21 PHP 5.2.17 (cli) (built: Feb 27 2011 21:01:47) + APC 3.1.2 Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies mysql Ver 14.12 Distrib 5.0.51a, for unknown-linux-gnu (x86_64) using EditLine wrapper memcached 1.4.5 root@srv1:~# cat /etc/debian_version 6.0
Tests effectués
Ecriture disque
dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
Moyenne débits écriture disque MB/s
ab (Apache HTTP server benchmarking tool) sur 3 URLs différentes
Load Average
ab (Apache HTTP server benchmarking tool) sur 3 URLs différentes
Requêtes par secondes
Requêtes par secondes
Temps d’exécution du bench pour traiter le nombre de requêtes
Temps d’exécution du bench
Durée de la requête la plus longue
Durée de la requête la plus longue
Délai d’indexation Solr (updatesearchindexsolr.php)
php extension/ezfind/bin/php/updatesearchindexsolr.php -s ezwebin_site_admin
Délai d'indexation Solr (updatesearchindexsolr.php)
Délai de compilation des templates (eztc.php)
php bin/php/ezcache.php --clear-all && time php bin/php/eztc.php
Délai de compilation des templates (eztc.php)
Bilan
On voit toute l’importance du CPU et des performances des accès disques.
En effet, le serveur OVH semble pouvoir répondre à un plus grand nombre de requêtes, mais son « Load Average » assez élevé lors des tests peut s’expliquer par les mauvaises performances disque.
Coté VPS 1&1, on voit clairement que les faibles ressources CPU et RAM disponibles limitent les traitements, comme l’indexation de contenus et le traitement des requêtes http.
En somme, l’idéal serait d’avoir les ressources RAM et CPU du Kimsufi, et les I/O disque du VPS 1&1.
Les 2 peuvent répondre à des besoins d’hébergement de petits sites, attention toutefois si vous souhaitez utiliser des outils « tierces » tel que eZ Find / JAVA, qui semble vite montrer les limites avec le VPS 1&1.
Note 1: J’ai eu une saturation de la mémoire sur le VPS 1&1 lors des tests de compilation des templates eZ Publish;
Cela a eu pour effet de me couper l’accès SSH, le front web restant disponible.
J’ai du rebooter la VM pour retrouver mes accès SSH.
Je pense que cela est du au fait que j’ai réservé auparavant (et après indexation) 500Mo de RAM pour le processus Solr, ce qui a généré une « alerte » sur la VM. Inquiétant pour un environnement ou je suis le seul dessus !
Les » 512 Mo de RAM garantie » semble expliquer ce phénomène. Au delà, je ne sais pas trop ce qu’il est possible de faire :/
Méfiance donc!
Resource Alerts
fonctions_vps_1&1
Note 2: Vis à vis des tests I/O que j’avais fait notamment avec une VM Gandi, j’arrive à un bon résultat… ce qui était déjà visible sur les tests ci-dessus.
1226 files created in 30 seconds.
1501 files created in 30 seconds.
1424 files created in 30 seconds.
1446 files created in 30 seconds.
- Plus d’articles sur l’hébergement eZ Publish
