Gandi qui annonce un hébergement élastique, ça demande qu’on aille y voir de plus près. Kesako ? Gandi dispose dans ses baies de nombreuses machines ultra-puissantes, sur lesquelles ils vendent de l’hébergement. Contrairement aux dédiés ou semi-dédiés habituels, cet hébergement est « élastique » au sens où, à travers quelques clics sur une interface de gestion (et sur sa CB), on peut ajouter des « parts » à notre hébergement, pour le faire grossir, en capacité disque et en capacité de calcul (CPU). On peut le faire grossir quand le site commence à avoir du succès, ou parce qu’on a de plus en plus de vidéos à stocker, ou parce qu’on a envie que ça aille plus vite.

Les explications sont assez claires sur le site https://www.gandi.net/hebergement/, n’ayant rien à ajouter, je ne les répète pas ici.

Les serveurs fonctionnent avec Xen, un virtualiseur qui permet de démarrer un serveur virtuel, lequel nous est entièrement affecté. Le temps CPU est réparti entre les différents serveurs installés sur la même machine, chaque instance ayant strictement 1/64e du temps CPU. On peut — c’est là que c’est élastique — prendre plusieurs « parts », et obtenir dès lors non pas 1/64 mais une fraction plus importante du temps CPU : 2/64, 3/64 etc. Bien sûr c’est plus cher, en proportion du nombre de parts qu’on loue.

Est-ce que ça va vite ?

Nos premiers tests consistent à installer un SPIP tout vide, version stable (1.9.2d), et à lancer ab dessus, comme d’habitude [1] :

# ab -c10 -n1000 http://xxxxxx/

Le résultat est un peu décevant : avec une part, on n’arrive à sortir que 3.9 pages par seconde (les pages sont dans le cache de SPIP).

Comme d’habitude, Jacky installe eaccelerator, et respire alors un peu mieux : 11 pages/s.

On ajoute alors une seconde part, et là, surprise : 11 pages/s. En vérifiant l’interface de gestion de l’hébergement on comprend qu’il ne suffit pas de prendre des parts, mais qu’on peut choisir de les affecter soit à un seul processeur, soit à des processeurs différents.

En choisissant de les affecter à deux processeurs, on obtient 22 pages/s. Pas si mal. Reste à voir si on peut continuer à monter comme ça proportionnellement au nombre de parts, et jusqu’où ça nous mène si on prend 4, 8 ou 16 parts.

Bien sûr il faudra aussi comparer avec d’autres solutions, et installer autre chose qu’une base de données vide (comme on « tape » dans le cache de SPIP, on n’a testé ici, en fait, que la capacité d’Apache et de PHP).

 

Nouvel essai, avec 7 parts cette fois-ci :

1er test :
- 1 part, 1 CPU : on retrouve 11 pages/s

2ème test :
- 7 parts, 1 CPU : 87 pages/s (résultat stable)

3ème test :
- 7 parts, 7 CPU : de 40 pages/s à 88 pages/s (résultat variable)

Bilan : cette fois les performances de ce test sont bien environ 7 fois meilleures avec 7 parts ; l’effet constaté avec 2 parts, sur la dispersion des CPUs, semble s’être inversé.

À suivre... n’hésitez pas à ajouter dans le forum vos expériences et des liens vers d’autres tests peut-être déjà publiés ailleurs.

.

Résultats décevants

Modif de l’article au 15 mai 2008

Bon après quelques tests c est tout de même très decevant. Visiblement avec une seule part il est difficile de faire tourner apache php mysql. Il m’a été conseiller de mettre httpd plutôt que apache. on me conseille aussi d’essayer avec 2 parts. Je m’execute, en effet c’est beaucoup mieux mais c’est deux parts donc plus cher. Oui parlons un peu du prix, mon idée était de transférer les quelques sites que j’avais (sur une dedibox a 30 euros ht) vers un gandi une part à 10 euros. En effet, je me disais que les sites que j’avais sur la dédibox n’utilisait pas la puissance entière de la dédibox.

mais bon trève de blabla, voici les chiffres d’acces au site :

dedibox : 72 ms gandi 1 part : 533 ms gandi 2 parts : 135 ms

moralité, je ne m’embette pas à déménager de dedibox vers gandi .

P.S : bien sur ces remarques ne tiennent pas compte des possibilité d’évolutions qu’offre gandi (en particulier gandi flex) et du support que l’on peut avoir.