RPS-1 vs SuperPlan 2006

Ce qui m’intéresse, en matière de performances, ce sont des résultats pratiques sur mes propres sites, essentiellement des sites WordPress, à savoir des sites au contenu dynamique nécessitant entre 10 et 40 requêtes SQL par page affichée.

Et en matière de RPS, ma seule crainte concerne d’ailleurs les accès à MySQL sur SAN. Comme je ne suis pas doué en administration serveur, j’ai installé tant bien que mal ce qu’il faut sur la Debian qui nous est fournie en test. Principal regret : l’absence, jusqu’à présent, du moins, d’une Linux Gentoo OVH Release 2, de sorte à obtenir un environnement réellement équivalent (si tant est que cela soit possible, compte tenu des diverses optimisations apportées à la configuration MySQL par défaut, afin qu’elle s’adapte aux besoins de mes sites).

METHODE DE MESURE

Ce que je vous propose, c’est de mesurer les performances d’affichage d’un même site sur deux serveurs dédiés OVH (RPS-1 et un vieux Superplan 2006) via Firefox et l’addon Firebug installé : cet addon permet d’afficher une frise de temps de chargement de tous les éléments composant une page web, ainsi que les durées de chargement de chacun d’eux. Aussi, afin de ne pas fausser les résultats, videz votre cache et rechargez la page testée, puis recommencez plusieurs fois.

MATERIEL DE COMPARAISON

Voici les configurations de test, d’un point de vue matériel :

RPS-1 Intel Celeron à 1,2 GHz 512Mo de RAM 100Mbps illimité 10Go iSCSI/NFS à 9.99Euro HT/mois la possibilité d’augmenter l’espace (jusqu’à 1To): 10Go pour 2Euro HT/mois

Superplan 2006 Intel Pentium IV à 3 GHz 1 Go de RAM 80 Go RAID-1 (2×80 Go) en SATA2 à 69,00 € HT / mois

Pour le Superplan 2006, notez que je cite de mémoire, mais à part pour le RAID-1 où j’ai un doute, le reste me semble tout à fait bon.

SITE DE TEST

Quoi qu’il en soit, voici le site original et voici son équivalent sur RPS.

Notez que les défauts d’affichage ne viennent pas du RPS, mis de mon import à la va vite de la BDD originale ; de plus, en l’absence de mod_rewrite installé sur le RPS, vous ne pourrez admirer que la page de garde du site.

De plus, notez que le Superplan 2006 est un serveur en production qui héberge une bonne demi-douzaine de sites de taille moyenne, alors que le RPS ne sert qu’aux tests, essentiellement celui-ci. Il est donc possible, selon l’utilisation réelle de chacun des deux serveurs, que les résultats varient suivant les essais.

Si vous souhaitez mesurer le temps de chargement de l’ensemble de la page, veillez à bien vider le cache avant chaque mesure. Si vous souhaitez mesurer le temps d’exécution du PHP, celui-ci n’étant pas caché (à moins que vous ayez configuré votre navigateur ou proxy en conséquence), il vous suffit de recharger, sans nécessairement vider le cache au préalable.

RESULTATS

Que ce soit pour le Superplan 2006 ou le RPS, depuis chez moi, la page se charge en environ 1,5 à 1,9 s. Je noterai cependant une variation plus importante de la génération du PHP sur RPS. En revanche, alors que le PHP est généré en environ 100 ms sur le Superplan 2006, le RPS subit une inflation importante, la page PHP se charge entre 170 et 300 ms environ.

Je l’explique d’une part par l’optimisation des paramètres de MySQL sur le Superplan 2006, notamment par l’augmentation du cache des requêtes, et l’absence de la moindre configuration sur le RPS, sinon l’installation de MySQL ; d’autre part, le Superplan 2006 tourne sous PHP 4, alors que le RPS tourne sous PHP 5. Rien que ces deux points pourraient à eux seuls expliquer cette différence de performances, d’où mon regret, en préambule, de ne pas disposer de machines configurées de manière équivalente.

Néanmoins, j’ai des soupçons quant à l’efficacité d’un RPS en matière de requêtes SQL. En effet, à défaut d’un cache efficace, et par conséquent d’une configuration adéquate de MySQL côté RPS, celui-ci risque de faire souvent appel au réseau pour des données de petite taille, une page web telle que celle de mon site exécutant dix à quarante requêtes pour à peine 14 Ko de contenu HTML produit au final. En matière, de cache, si MySQL ne devait pas en avoir assez, le Superplan 2006 dispose de 1 Go de mémoire, permettant de garder des données en cache disque en lecture plus longtemps que pour les 512 Mo du RPS-1 testé ici. Cependant, compte tenu de la petite taille des données envoyées (moins de 260 Ko), on ne peut imaginer que le RPS ne sache les garder en cache mémoire dans le cas étudié.

CONCLUSION

Compte tenu des différences de configurations présentées ici, je n’envisage pas de renouveler ce type de tests à l’avenir à défaut d’une distribution linux prête à l’emploi équivalente à celle installée sur mon autre serveur.

Néanmoins, j’invite tous ceux qui ont des sites en production sur des serveurs tournant sur une Debian équivalente à celle proposée par défaut sur cette beta du RPS par OVH à réaliser des tests similaires. Cela permettra d’avoir une meilleure idée des qualités et des défauts d’un RPS en comparaison d’un serveur dédié, que ce soit un Kimsufi, un Start ou un Superplan.

Pour conclure, on peut dire que le RPS est pleinement exploitable en production sans aucune honte en comparaison des serveurs dédiés classiques pourtant plusieurs fois plus onéreux. Il faudra cependant veiller à bien configurer le serveur en tenant compte de son utilisation réelle et, si les accès SAN devaient s’avérer être un goulot d’étranglement, opter pour des solutions de cache locales, telles que le module mem_cache d’Apache, car les RPS vont arriver avec 512 Mo,  1 Go et 2 Go de RAM, ce qui permet ce genre de mises en place si le besoin devait se faire sentir. Mais cette phase d’optimisation n’est pas spécifique au RPS, car tout serveur nécessite une optimisation des performances en fonction de son utilisation, si l’on souhaite se contenter de résultats supérieurs à la moyenne.

La question que l’on pourrait se demander, c’est si cela est si important de gagner 50 ou 100 ms dans le chargement d’une page. Cela a certainement un sens sur des sites à fort trafic ou multipliant les requêtes dynamiques (je pense notamment aux applications AJAX). En revanche, dans l’immense majorité des cas, il est probablement moins cher d’upgrader son serveur, ou d’en louer un deuxième, un troisième ou un quatrième, en particulier avec une solution aussi bon marché que le RPS, que de passer une à deux journées pour revoir la configuration du serveur ou le code qui tourne dessus…