Le grenat est un nouveau type de stockage de cache à distance développé par Microsoft Research qui offre plusieurs avantages uniques :
- Garnet prend le protocole de ligne RESP populaire comme point de départ, ce qui permet d’utiliser Garnet depuis des clients Redis non modifiés disponibles aujourd’hui dans la plupart des langages de programmation, tels que StackExchange.Redis en C#.
- Garnet offre un meilleur débit et une meilleure scalabilité avec de nombreuses connexions clients et de petits lots comparé à un stockage cache open source comparable, ce qui permet d’économiser des coûts pour les grandes applications et services.
- Garnet a démontré une latence client extrêmement faible (généralement inférieure à 300 microsecondes à 99,9 %) en utilisant des machines virtuelles Commodity Cloud (Azure) avec TCP accéléré activé, ce qui est crucial dans les scénarios réels.
- Garnet est basé sur la dernière technologie .NET et est multiplateforme, extensible et moderne. Il est conçu pour être facile à développer et à évoluer sans sacrifier la performance dans des situations courantes. Nous exploitons l’écosystème riche de bibliothèques de .NET pour étendre l’API et offrir des opportunités d’optimisation ouvertes. Grâce à notre utilisation soigneuse de .NET, Garnet atteint des performances de pointe à la fois sur Linux et Windows.
Adresse Open Source :La connexion hyperlientérée est visible. Documentation:La connexion hyperlientérée est visible.
Le grenat présente les avantages clés suivants :
- Le débit serveur (opérations par seconde) est augmenté de plusieurs ordres de grandeur pour de petits lots et de nombreuses sessions clients par rapport à un stockage de cache open source comparable.
- Sur les machines cloud classiques (Azure) avec TCP accéléré activé sous Windows et Linux, la latence par opération est extrêmement faible (généralement moins de 300 microsecondes à 99,9 %).
- À mesure que le nombre de clients augmente, une meilleure évolutivité est obtenue avec ou sans le batching client.
- Capacité à utiliser toutes les ressources CPU/mémoire d’un ordinateur serveur via une instance unique de serveur mémoire partagée (pas besoin de clustering intra-nœud).
- Prise en charge des ensembles de données plus volumineux que la mémoire qui débordent vers les dispositifs de stockage sur site et cloud.
- Fonctionnalités de base de données telles que checkpoint rapide et récupération, et publication/abonnement.
- Prise en charge du partitionnement de hachage multi-nœuds (mode « cluster » Rederis), de la migration d’état et de la réplication.
- Bien testé avec une suite de tests complète (des milliers de tests unitaires contre Garnet et son niveau de stockage Tsavorite).
- Une base de code C# facile à faire évoluer et à étendre.
Garnet ne prend pas en charge toutes les commandes Rederis, mais spécifiquement les commandes supportées pour la consultation :La connexion hyperlientérée est visible. Le projet Garnet inclut un outil de benchmark pour exécuter des benchmarks RESP utilisant différents clients, différentes charges de travail et différentes politiques pour mesurer le débit, la performance et la latence. Adresse:La connexion hyperlientérée est visible. Protocole RESP :La connexion hyperlientérée est visible.
Cet article utilise les outils de benchmarking intégrés à Redis pour des tests simples, et l’environnement de test est le suivant :
| cache | Version | | Redis | Redis 3.0.504 (00000000/0) 64 bits | | Grenat | Garnet 1.0.2 64 bits ; Mode autonome |
Benchmarks Redis
Tout d’abord, lancez le cache Redis en utilisant la ligne de commande suivante :
La commande test est la suivante :
Les résultats sont les suivants :
====== ENSEMBLE ====== 500 000 requêtes complétées en 24,38 secondes 100 clients parallèles Charge utile de 3 octets Garder la vie : 1
0,03 % <= 1 milliseconde 0,25 % <= 2 millisecondes 2,65 % < = 3 millisecondes 16,49 % < = 4 millisecondes 59,95 % < = 5 millisecondes 99,09 % < = 6 millisecondes 99,76 % < = 7 millisecondes 99,86 % < = 8 millisecondes 99,93 % < = 9 millisecondes 99,98 % < = 10 millisecondes 99,99 % < = 11 millisecondes 100,00 % <= 12 millisecondes 20512,82 requêtes par seconde
====== SE ====== 500000 requêtes terminées en 27,41 secondes 100 clients parallèles Charge utile de 3 octets Garder la vie : 1
0,03 % <= 1 milliseconde 0,19 % <= 2 millisecondes 6,44 % < = 3 millisecondes 25,82 % < = 4 millisecondes 45,65 % < = 5 millisecondes 98,79 % < = 6 millisecondes 99,98 % < = 7 millisecondes 99,98 % < = 8 millisecondes 99,98 % < = 9 millisecondes 100,00 % < = 9 millisecondes 18 238,86 requêtes par seconde
Benchmarks Garnet
Créez un nouveau projet console .NET 8 et référencez d’abord le paquet Microsoft.Garnet avec la commande suivante :
Le code est le suivant :
La commande de démarrage est la suivante :
En utilisant la même commande de benchmark, le résultat est le suivant :
====== ENSEMBLE ====== 500 000 requêtes terminées en 11,51 secondes 100 clients parallèles Charge utile de 3 octets Garder la vie : 1
75,51 % < = 1 milliseconde 88,24 % < = 2 millisecondes 92,04 % < = 3 millisecondes 99,46 % < = 4 millisecondes 99,98 % < = 5 millisecondes 99,99 % < = 6 millisecondes 100,00 % <= 12 millisecondes 100,00 % <= 12 millisecondes 43448,04 requêtes par seconde
====== SE ====== 500 000 requêtes terminées en 31,50 secondes 100 clients parallèles Charge utile de 3 octets Garder la vie : 1
0,01 % <= 1 milliseconde 0,90 % <= 2 millisecondes 27,25 % <= 3 millisecondes 97,65 % < = 4 millisecondes 99,82 % < = 5 millisecondes 99,94 % < = 6 millisecondes 99,98 % < = 7 millisecondes 99,98 % < = 9 millisecondes 99,98 % < = 10 millisecondes 99,99 % < = 11 millisecondes 100,00 % <= 12 millisecondes 100,00 % <= 12 millisecondes 15 872,01 requêtes par seconde Grâce aux outils de test, aux versions logicielles, aux paramètres de test, etc., qui donnent tous des résultats différents, les tests ne sont qu’à titre de référence, et à travers les tests simples de cet article, on peut voir que Garnet a une latence nettement plus faible que Redis.
(Fin) |