Skip to content

Gandi Simple Hosting

February 8, 2017

Cet article a été rédigé depuis plusieurs mois et je n’utilise plus la solution Gandi Simple Hosting pour mon site. Les raisons sont exposées dans la partie “Verdict”.

Cela fait déjà un mois que j’ai opté pour les services de Gandi pour le “hosting” de mon site WEB koikonfait. J’ai choisi de prendre un service PaaS plutôt que IaaS. La principale raison tient au fait de ne pas avoir à gérer la base de données MongoDB sous-jacente. Les autres intérêts: le tarif, la garantie de disponibilité et le cache Varnish.

Après plusieurs mois d’utilisation, je dois avouer que je suis mitigé quant aux résultats: je suis un peu déçu de certains aspects de ce PaaS. Loin de moi d’accuser mon hébergeur Gandi, il s’agit simplement de points importants à ne pas négliger avant de choisir ce type d’hébergement.

Les points noirs

Le premier, c’est Varnish… Étonnamment, Varnish est incroyablement efficace mais induit deux effets de bord: le premier est qu’il est en tout début de chaîne, avant même le serveur Apache. Ce qui signifie que les hits sur les pages du site qui sont encore dans le cache, ne sont pas journalisés dans le fichier access.log du serveur. Inutile donc de déployer un outil d’analyse des logs tels que webalizer. Il faut donc se baser sur des appels Javascript (via Google Analytics ou un concurrent). Certains me feront remarquer que plus personne n’utilise les logs Apache depuis longtemps pour le calcul des visites…

Encore Varnish: seules les requêtes GET (et HEAD) passées sans cookie seront prises en compte. Donc, pas de session dans votre page. Sinon, plus de cache. Argh… Pour le coup, Gandi annonce bien les règles du jeu dès le départ, donc pas de (mauvaise) surprise.

Le crontab: anacron vous permet de lancer des jobs toutes les heures ou tous les jours mais vous n’avez pas la maîtrise de l’horaire… Cela peut poser problème. Dans mon cas de figure où j’importe beaucoup de données la nuit, j’ai déporté les traitements sur une autre machine! Cependant, j’utilise l’outil fourni pour faire quelques opérations comme le ménage dans la base de données et une sauvegarde. Efficace.

La version des outils proposés: PHP est en version 5.4 (la version 5.6 est annoncée) et MongoDB est en version 2.4 (il y a de l’abus on dirait!). Du coup, il faut vérifier que le code est compatible (en local, je travaille en 5.5 pour le PHP et 3.0 pour MongoDB!).

L’accès SSH est possible mais via l’interface de gestion et pour une durée limitée. Ce n’est pas vraiment une restriction.

Il y a une rotation des fichiers de logs: dès qu’ils dépassent 10Mo. Et j’ai trouvé l’information bien cachée quelque part sur un forum. Au début, je pensais que je devais fournir mon propre script de rotation! C’est bien géré, merci les gars!

En conclusion: ne prenez pas cette offre si vous devez faire de l’administration ou un truc dans le genre: vous perdriez le bénéfice du cache. Si en revanche, il s’agit d’un blog, de puiser dans une base de données ou d’un bulletin d’informations, cela devient intéressant et facile à mettre en œuvre car totalement transparent.

Les points forts

C’est le reste… Les temps de réponses sont minimaux: des pages qui mettent 8 secondes à être générées sont renvoyées en quelques millisecondes grâce au cache. C’est là le point fort. Seules 2 requêtes peuvent être exécutées simultanément mais ce n’est pas grave puisque les pages et autres objets statiques (images, scripts…) vont être servis par le cache.

Il y a une page de statistiques qui donne l’utilisation de la mémoire, du cache Varnish, de la CPU et de la bande passante utilisée: Cela donne une bonne idée de l’usage du serveur. Et des capacités utilisées: faut-il passer sur une instance de plus grande capacité?

Il y a aussi les fichiers de logs. Je passe sur le access.log de Apache pour le moins rébarbatif et finalement peu intéressant si le cache fait son office. En revanche, les autres sont pas mal: un log des opérations programmées (le crontab), les erreurs Apache error.log beaucoup plus intéressant et les erreurs PHP. Également, un log pour la base de données MongoDB qui permet de détecter les requêtes trop longues qui nécessiteraient un index.

En complément des outils pour Webmaster de Google qui permet de vérifier les temps de réponse moyen des pages, ces informations sont vraiment intéressantes.

Le verdict

Je suis loin d’être certain aujourd’hui que la solution est pérenne pour le couple PHP/Mongo. À noter que les versions ont été mises à jour entre temps. Mais MongoDB utilise beaucoup de mémoire et les temps de réponses sont assez décevants. Dans mon cas de figure, Varnish ne servait pas à grand-chose.

Aujourd’hui, je suis sur un VPS (que je possédais avant) et les performances ont été décuplées avec des réglages similaires. Je n’accuse pas Gandi, d’ailleurs des WordPress sous Gandi Simple Hosting fonctionnent parfaitement mais la solution utilisant MongoDB doit se limiter à des bases de données de petites tailles.

J’ai conservé en revanche, du moins au début, la philosophie de la solution avec des installations via git par exemple.

Aujourd’hui, la solution Gandi Simple Hosting est surtout destinée à WordPress. Et là, aucun souci. De plus qu’une solution automatique a été mise en place. C’est la solution que j’ai adoptée pour une association. Mais, concernant les autres utilisations, ce n’est pas forcément optimal d’autant que certaines solutions en VPS deviennent très concurrentielles (encore faut-il savoir gérer un serveur Linux!).

 

Advertisements

From → Other

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: