blog
Prestashop et Cloud Public : la fausse illusion

Prestashop et Cloud Public : la fausse illusion

Chez Nexylan, on adore tester tout et n’importe quoi ! Alors quand un de nos clients est venu vers nous pour s’assurer que son site de vente privée tiendrai le choc de la prochaine vente, on s’est dit que c’était l’occasion de tester du Cloud public.

 

Le Cloud public, c’est quoi ?

C’est la possibilité d’avoir accès à une puissance informatique illimitée que l’on paye à la consommation. C’est un peu comme EDF : on considère que c’est illimité (à l’échelle de la maison, de l’entreprise, ou même du pays), l’on paye uniquement ce que l’on utilise.

 

Le Cloud public, sous quelle forme ?

Il existe principalement 3 types de services Cloud :

– Le IaaS : du serveur (AWS, Rackspace, Joyent, etc…

– Le PaaS : de l’hébergement basé sur un langage en particulier (Azure avec le .Net, Heroku avec leRuby, Google Engine avec GWT, etc.)

– Le SaaS : de l’application (BaseCamp, Google Apps, etc.)

 

Etude de cas

L’architecture est simple : un serveur web (Nginx), des serveurs PHP (FPM) alimentés par un load-balancer (HaProxy) et une base de données (MySQL). La boutique de vente-privée a été intégrée sur la solution Open-Source Prestashop (dernière version).

 

Nous savons que si le nombre de visiteurs est important, c’est la partie PHP et la base de données qui vont souffrir le plus. Nous avons donc défini 2 cas de figures :

– Les serveurs PHP/FPM dans le Cloud

– Les serveurs PHP/FPM et la base de données MySQL dans le Cloud

 

A l’aide de nos outils de Benchmark (aka « lance-requêtes » ou « lance-patates»), nous avons simulé des visites sur le site, allant de 1 à 1000 utilisateurs simultanés (1 visiteur étant considéré comme un psychopathe qui rafraichit sa page 1 fois par seconde avant l’ouverture de la vente privée).

Quel Cloud ?

Côté Cloud, le choix a été plutôt simple : Amazon Web Services (N°1 en IaaS), et Rackspace (le N°2).

Résultats des tests

Après 2 semaines de tests intenses et d’optimisations, voici notre bilan :

– Le nombre de CPU chez Rackspace est limité à 4, ce qui est trop peu pour nos besoins.

– Les temps de création de machines chez Rackspace sont particulièrement longs (jusqu’à 5min). Depuis qu’AWS a ajouté des fonctions de check sur la création de ses serveurs, le temps est presque identique. Pas facile d’être réactif si on perd 5min par serveur…

– La distribution Gentoo, qui représente la quasi-totalité du parc Nexylan, n’existe pas chez Amazon en tant que distribution officielle.

– S’il est possible de stopper un serveur chez AWS (et de ne plus être facturé), ce n’est pas le cas chez Rackspace. Il est possible de s’en sortir en faisant une sauvegarde de la machine, et d’en recréer une nouvelle à partir de là. On perd donc 5min à nouveau.

– Les performances MySQL de la solution RDS (hébergement de base de données) sont bien inférieures à ce que nous avons sur nos propres machines, alors que la configuration matérielle est inférieure chez nous.

– Les temps de lecture / écriture sur les disques sont courts chez Rackspace, ce qui est un bon point. Cette vitesse est identique quelle que soit la taille de la machine que l’on prends. Ce qui n’est pas le cas chez AWS : pour obtenir des performances similaires, il faut prendre les machines les plus chères…

– Les réseaux d’AWS et de Rackspace sont publics. Ce qui signifie qu’en terme de sécurité, il est nécessaire de passer en SSL pour les transactions MySQL. Bien que possible, cela joue beaucoup sur les performances de façon significative.

– Le réseau chez AWS est très problématique avec une configuration vraiment spécifique. Il se trouve que les machines ne sont pas directement accessibles par Internet (NAT), ce qui n’arrange rien aux temps de réponse :

– 15ms pour relier notre réseau à celui d’AWS

– 15ms supplémentaire pour accéder au serveur à partir du réseau AWS

Au total, 30ms séparent donc nos serveurs internes à ceux d’Amazon. C’est beaucoup trop pour être efficace. Prestashop effectuant des centaines de requêtes pour chaque page de la boutique de notre client, si on multiplie par la latence, le temps total de chargement devient vite inacceptable.

Chez Rackspace, situé en Angleterre, le temps de réponse est de 10ms, ce qui est bien plus acceptable mais toujours impactant.

En conclusion, le résultat de notre étude est décevant. Bien qu’attrayant à la base, les solutions Cloud proposées par Rackspace et Amazon ne répondent pas à toutes les promesses qu’on attend du Cloud (rapidité d’installation, puissance temporaire, facturation à l’heure, etc…).

Dans notre cas d’étude, leur offre est parfaite pour des plateformes « full » hébergées chez eux (Web, load-balancer, PHP, MySQL)… Autant dire que pour un site e-commerce de vente privée (concept évènementiel), le tarif atteint vite des sommets comparé à un hébergement dédié (par exemple).

Pour ce client, nous avons choisi de passer par notre propre Cloud, d’ailleurs vous en saurez plus très prochainement 😉