Instances DEV1 à base d'EPYC : analyse des performances, Scaleway répond à nos questions

Comme précédemment, on peut regretter le manque d'informations sur les serveurs et leur niveau de performances. Un souci régulier des offres virtualisées « dans le Cloud », mais l'on attend d'un acteur comme Scaleway qu'il se distingue. 

Le CPU utilisé n'est ainsi pas précisé, il est même question de simples vCPU dans les instances DEV1 et de vCPU AMD EPYC pour GP1, sans raison donnée. Pourtant, ces informations ne sont pas sans incidences sur les performances, notamment en cas de fréquence ou de cache différents d'une instance à l'autre. Idem pour le stockage.

Les instances à quatre cœurs pour les développeurs ont-elles la même composition que celles à vocation plus générale ? Impossible à dire en regardant le détail des offres présenté par Scaleway :

Nous avons donc analysé deux instances au même nombre de vCPU mais avec des différences notables : DEV1-L et GP1-XS. Les instances START étant toujours proposées à Amsterdam, nous en avons utilisé une à titre de comparaison, pour vérifier le gain potentiel pour les clients :

• DEV1-L : 4 vCPU, 8 Go RAM, 80 Go NVMe, 300 Mb/s, 15,99 euros par mois
• START1-L : 8 vCPU, 8 Go RAM, 200 Go NVMe, 400 Mb/s, 15,99 euros par mois
• GP1-XS : 4 vCPU, 16 Go RAM, 150 Go NVMe, 400 Mb/s, 39,00 euros par mois 

Pour un prix inchangé, Scaleway a divisé par deux le nombre de cœurs, le stockage et réduit la bande passante. Passer d'un processeur Intel à AMD ne semble donc pas se faire au profit d'une hausse des caractéristiques, contrairement à ce que l'on aurait pu croire. Mais attention, il s'agissait de puces Atom C, à l'architecture bien moins efficace.

Il faut donc juger sur les performances relevées. Yann Léger, Vice-Président en charge des offres Cloud de Scaleway se veut rassurant sur ce point :

As-tu testé les performances ? Ces machines sont plus performantes à prix égal.

— Yann Léger (@yann_eu) 28 mars 2019

Au sein de la nouvelle offre, DEV1-L parait plus intéressante que GP1-XS pour les petits besoins en stockage ou en mémoire, puisqu'elle est quasiment deux fois moins chère, avec un nombre de vCPU identiques. Mais de quoi ces instances sont-elles exactement composées ?

Côté CPU, nous avons :

• DEV1-L : AMD EPYC 7281 (1P/2P, 16C, 32T, 2,1 à 2,7 GHz, 32 Mo de cache, TDP de 155/170 W)
• START1-L :  Atom C3955 (1P, 16C, 16T, 2,1 à 4 GHz, 16 Mo de cache, TDP de 32 W)
• GP1-XS :  AMD EPYC 7401P (1P, 24C, 48T, 2,0 à 3 GHz, 64 Mo de cache, TDP de 155/170 W)

Pour le reste, la quantité de mémoire (ECC) et de stockage est respectée, avec une virtualisation via KVM/QEMU (Virtio Red Hat). Comme toujours, nous avons effectué nos tests un minimum de deux fois sur chaque machine, avec d'autres itérations lorsque cela s'avère nécessaire pour obtenir une moyenne cohérente. Les instances étaient configurées sur Ubuntu 18.10 (noyau 4.15), mis à jour et sans options particulières.

Quelles performances ?

• Débits et stockage

Nous commençons nos essais en récupérant la version 4K (Digital Cinema Package) de Tears of Steel, qui pèse un peu plus de 13 Go (compressée) et nous servira par la suite. L'occasion de relever le débit :

• DEV1-L : 4,92 Mo/s (45:16)
• START1-L : 37,6 Mo/s (5:55)
• GP1-XS : 4,89 Mo/s (45:02)

Commande utilisée :

wget https://download.blender.org/demo/movies/ToS/ToS_4k_DCP.zip

Les résultats des deux nouvelles instances sont presque similaires, et pour cause : ils sont bien moins élevés qu'annoncés ! Sur START-1L, pas de problème. Il semble que cela vienne du datacenter parisien, puisque même une instance Render-S, annoncée à 1 Gb/s, était limitée à 5 Mo/s. Pourtant, aucun lien ne semble sursollicité.

Les bons résultats de START1-L s'expliquent sans doute par la localisation du serveur de stockage aux Pays-Bas. Contacté suite à notre première série d'essais, l'hébergeur nous a confirmé ne pas relever de problème particulier de son côté, et soupçonne plutôt une limitation qui serait appliquée par le serveur lors d'un téléchargement depuis la France. Une analyse est en cours pour tenter de comprendre le phénomène.

Nous pouvons néanmoins confirmer que nous relevons le même phénomène depuis d'autres services testés depuis, comme AWS par exemple. Pour compléter ce premier essai, nous avions effectué des tests complémentaires en récupérant une ISO de Fedora 29 depuis les serveurs du CNRS et de Free :

• DEV1-L :
  • CNRS : 49,8Mo/s (37s)
  • Free : 478 Mo/s (4s)
• START1-L :
  • CNRS : 43,3 Mo/s (42s)
  • Free : 121 Mo/s (15s)
• GP1-XS :
  • CNRS : 99,8 Mo/s (18 s)
  • Free : 464 Mo/s (4 s)

Commandes utilisées :

wget http://ftp.free.fr/pub/Distributions_Linux/Fedora/releases/29/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-29-1.2.iso
wget http://mirror.in2p3.fr/pub/fedora/linux/releases/29/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-29-1.2.iso

Les chiffres relevés sont supérieurs à ceux annoncés, mais les débits ne seront pas toujours de ce niveau. Pour s'en convaincre, il suffit d'utiliser l'outil Bench.sh, relevant au passage les performances du stockage :

• 
• 
• 

Performances DEV1-L / START1-L / GP1-XS

• 7-Zip 16.02

Passons maintenant à l'applicatif, tout d'abord avec 7-Zip en décompressant le fichier de Tears of Steel, l'application étant sensible au CPU, aux caches/mémoire et au stockage :

• DEV1-L : 96 secondes
• START1-L : 104 secondes
• GP1-XS : 93 secondes

Commande utilisée :

time 7za e -y ToS_4k_DCP.zip

Ici, DEV1 est à l'avantage par rapport à l'ancienne offre START-1, les quatre vCPU EPYC arrivant au même résultat que huit d'Atom. GP1 étant toujours en tête, même si c'est assez faible. 

• OpenSSL 1.1.0g

Nous utilisons ensuite OpenSSL, exploitant notamment le chiffrement matériel, plus sensible au nombre de cœurs et à la fréquence qu'au reste de de la machine : 

• DEV1-L :
  • 454 signatures/s
  • 29 527 vérifications/s
• START1-L :
  • 461 signatures/s
  • 30 147 vérifications/s
• GP1-XS :
  • 585 signatures/s
  • 38 648 vérifications/s

Commande utilisée : 

openssl speed --multi $(nproc) rsa4096

START-1 devance DEV1, un résultat logique puisque les architectures Intel sont en général à l'avantage dans ce test. Les différences entre chaque puce étant assez faibles, elles peuvent rapidement changer de position. GP1 reste néanmoins premier, avec 30 % d'avance sur DEV1 à nombre de vCPU identique.

• Compilation Blender

Passons à la compilation de Blender, pour laquelle nous suivons le guide officiel :

• DEV1-L : 889 secondes
• START1-L : 704 secondes
• GP1-XS : 508 secondes

Commande utilisée :  :

time make

On retrouve les résultats précédents : GP1-XS largement en tête face à START1-L. DEV1-L semble à nouveau en retrait de manière significative.

• Rendu Blender

Nous finissons en utilisant cette version compilée de Blender pour effectuer un rendu CPU via le moteur Cycles de la célèbre scène de démonstration bmw27_cpu : 

• DEV1-L : 880 secondes
• START1-L : 959 secondes
• GP1-XS : 584 secondes

Commande utilisée :

time ./blender-git/build_linux/bin/blender -b bmw27_cpu.blend -E CYCLES -t $(nproc) -f 1

Ici, l'offre EPYC semble plus à l'aise à voir les résultats de GP1-XS, mais aussi de DEV1-L dans une moindre mesure. Ces instances sont bien plus rapides que START1-L dont l'architecture manque sans doute de certaines fonctionnalités qui ont un impact important sur les performances dans de telles situations.

Contexte de la réalisation de nos tests

Lors d'une première série d'essais vendredi, nous avons parfois relevé une forte disparité de performances dans nos premiers relevés. Nos instances DEV1-L fournissaient en effet des résultats trois à dix fois moins élevés que la normale. La seule raison nous paraissant logique était alors un abus d'overprovisionning.

Nous avons contacté Scaleway pour en savoir plus. La société nous a répondu après la publication vendredi soir pour se dire « très surprise de lire les résultats des tests que vous avez effectués et les conclusions auxquelles vous aboutissez », nous demandant de retirer l'article en attente d'un échange et d'une enquête interne.

Une requête assez rare, surtout en l'absence de réponse concrète. Nous avons préféré relancer des séries de tests ce week-end, en suivant un protocole identique à nos premiers essais pour vérifier si le problème rencontré était toujours présent : ce n'était plus le cas (excepté pour les débits). Nous avions alors mis à jour l'article avec les chiffres obtenus.

Notez que c'est à ce moment que le site de l'hébergeur a été modifié, évoquant de simples vCPU pour DEV1 plutôt que la mention x86-64, les vCPU de GP1 étant tout de même affichés comme des AMD EPYC, sans expliquer la différence. Pour en savoir plus, nous avons pu nous entretenir avec Arnaud de Bermingham, PDG et fondateur d'Online/Scaleway.

Scaleway confirme un bug (corrigé), des benchmarks arrivent

Il confesse sans mal une défaillance technique au lancement de l'offre, et donc lors de nos tests : l'outil devant répartir les clients sur différentes machines a rencontré un problème, provisionnait toutes les instances sur un même ensemble, causant les chutes de performances relevées. 

Malgré les premières remontées de clients dans la journée, le souci n'a pas été identifié. C'est lorsque nous avons détaillé notre procédure et que nos résultats ont été connus que le problème a pu être détecté et réglé. De quoi inciter l'équipe à renforcer ses outils de monitoring. 

Il nous a également été confirmé qu'il y a bien une différence dans le provisionnement des instances DEV1 par rapport à GP1, expliquant les écarts de performances relevés lors de nos dernières séries de tests. Un billet de blog sera rapidement publié pour détailler certains points.

Scaleway nous dit travailler sur un indice de performances basé sur des chiffres constatables par les clients « dans le pire des scénarios », quand les instances sont utilisées à leur plein potentiel. Une manière de fournir une information tout en évitant les fausses promesses.

Au passage, nous avons pu apprendre que même si des EPYC 7281 2P étaient utilisés dans l'offre DEV1, ils sont exploités en solo. Scaleway préfère en effet éviter d'avoir trop de clients sur un même hyperviseur, même si à l'inverse, multiplier le matériel revient à multiplier les risques de pannes.

Pour cela, la société utilise une solution conçue avec un OEM spécifique, intégrant deux nodes par U (à la manière des châssis 2U4N) afin de préserver une bonne densité. 

Offres dans le Cloud, un besoin de transparence

En utilisant des EPYC d'AMD plutôt que des processeurs Atom, Scaleway rend son infrastructure plus flexible, sans doute plus dense mais aussi plus uniforme. L'utilisateur peut ainsi rester sur une même architecture dans une offre passant de 2 à 48 cœurs selon ses besoins, de projets minimaux à de lourds calculs.

Mais on le voit, cela ne se fait pas sans quelques aspects négatifs. Tout d'abord le manque de clarté de l'offre. L'utilisateur ne sait pas vraiment ce qu'il achète à cause de termes trop génériques – vCPU ou EPYC – aucun détail sur les processeurs, le fait qu'ils soient dédiés ou non à une instance, etc.

L'arrivée des indices de performances est une bonne chose, mais le secteur fait face à un manque de transparence global, qui va bien au-delà de cette offre ou même de Scaleway. Le client ne sait ainsi pas toujours à quoi s'attendre, ne prend pas forcément la peine de tester les performances de ses instances, alors que les écarts peuvent être importants.

Surtout que nombre de pratiques sont peu évoquées publiquement, que ce soit l'overprovisionning et la manière dont les clients sont parfois entassés sur des ressources partagées, les performances des solutions de stockage mises en place ou même les optimisations pour limiter les effets de la virtualisation.

Pour DEV1, on regrette aussi que les anciennes instances START1 paraissent plus intéressantes. Car même si EPYC est légèrement plus efficace, on doit faire avec moins stockage et de bande passante pour un tarif similaire.

Ici, Scaleway semble repenser sa gamme en augmentant ses tarifs. Un choix qui n'a rien de critiquable, chacun est après tout libre de ses prix. Mais le client pourra regretter d'être ainsi mis devant le fait accompli.

La liberté du Cloud, c'est aussi ça.