NCache peut vous aider à évoluer linéairement et à améliorer vos performances, facilement et à moindre coût. Les entreprises du Fortune 500 du monde entier lui font confiance. NCache depuis plus de 13 ans pour supprimer les goulots d'étranglement des performances liés au stockage des données et aux bases de données et pour faire évoluer les applications .NET vers le traitement des transactions extrêmes (XTP).
Ce document utilisera NCache Version 5.0 avec des API modernes et de nouvelles fonctionnalités pour démontrer l'évolutivité linéaire et les performances extrêmes que vous pouvez obtenir pour vos applications .NET. Dans cette expérience, nous avons intégré un modem. NCache API avec une topologie de cache partitionnée et le pipelining activé. Les données sont entièrement distribuées sur tous les serveurs de mise en cache et les clients se connectent à tous les serveurs pour les requêtes de lecture et d'écriture.
Dans ce benchmark, nous démontrons que le NCache cluster peut évoluer linéairement et que nous avons atteint 2 millions de transactions par seconde en utilisant seulement 5 nœuds de serveur de cache. Nous allons également démontrer que NCache peut fournir une latence inférieure à la microseconde même dans un grand cluster. Dans ce livre blanc, nous couvrirons les paramètres de référence, les étapes d'exécution des références, les configurations de test, les configurations de charge et les résultats. Vous pouvez voir l'expérience de référence en action dans ce face .
Examinons notre configuration de référence. Nous utiliserons des serveurs AWS m4.10xlarge pour ce test. Nous en avons cinq. NCache Serveurs sur lesquels nous allons configurer notre cluster de cache. Nous disposerons de 15 serveurs clients, depuis lesquels nous exécuterons des applications pour nous connecter à ce cluster de cache.
Nous allons utiliser Windows Server 2016 comme système d'exploitation – Data Center Edition, 64 bits. Le NCache La version utilisée est la 5.0 Enterprise. Dans cette configuration de référence, nous utiliserons une Topologie du cache partitionnéDans une topologie de cache partitionné, toutes les données sont entièrement réparties en partitions sur tous les serveurs de mise en cache. Tous les clients sont connectés à tous les serveurs pour que les requêtes de lecture et d'écriture puissent utiliser tous les serveurs simultanément. La réplication n'est pas activée pour cette topologie, mais il existe d'autres topologies, comme celle-ci. Topologie de réplication partitionnée qui est équipé d'un support de réplication.
Nous aurons Pipelining activé, ce qui est une nouvelle fonctionnalité dans NCache 5.0. Son fonctionnement est le suivant : côté client, il accumule toutes les requêtes en cours d'exécution et les applique immédiatement côté serveur. L'accumulation s'effectue en quelques microsecondes, ce qui le rend très optimisé et recommandé pour les charges transactionnelles élevées.
Voici un aperçu rapide de notre configuration de référence, y compris les configurations matérielles, logicielles et de charge.
| Détails du client et du serveur (Machine virtuelle) |
AWS m4.10xlarge : 40 cœurs, 160 Go de mémoire, réseau - Ethernet 10 Gbit/s |
| Nombre de nœuds de serveur | 5 |
| Nombre de nœuds clients | 15 |
| Système d'exploitation | Windows Server 2016 Édition Centre de données – x64 |
| NCache Version | 5.0 |
| Topologie des clusters | Configuration du cache partitionné |
| Taille du cache | 4 GB |
| Taille des données | Tableau d'octets de taille 100 |
| Articles au total | 1,000,000 |
| Pipelining | Les utilisateurs de l’app Smart Spaces avec Google Wallet profitent d’un accès mobile sans contact avec tout lecteur HID® Signo™ compatible NFC. |
| Rapport d'obtention/mise à jour | 80:20 |
| Threads | 1280 |
| Instances d'application | 2 instances par machine client, soit 30 instances au total |
Après avoir configuré notre environnement de référence, nous commencerons avec un cluster de cache rempli d'un million d'éléments. Nous exécuterons l'application cliente (Cache Item Loader) qui se connectera et ajoutera un million d'éléments au cache. Un client se connectera à tous les serveurs de mise en cache et ajoutera un million d'éléments au cluster de cache. Nous pourrons ensuite lancer les requêtes de lecture et d'écriture.
Vous pouvez utiliser cette Paquet Nuget – NCache SDK pour installer le SDK sur la machine cliente et configurer le pipeline entre le client et le serveur et déployer l'application de génération de charge (GitHub) pour remplir 1 million d'éléments de cache sur le cluster de cache.
Nous allons maintenant exécuter l'application pour générer une charge transactionnelle sur ce cluster de cache, avec 80 % d'opérations de lecture et 20 % d'opérations d'écriture. Vous pouvez surveiller toute l'activité grâce aux compteurs Perfmon. Dans un premier temps, nous connecterons 10 instances clientes à chaque cluster. NCache serveur avec activité sur les récupérations ainsi que sur les mises à jour par seconde.
Vous pouvez voir dans la capture d'écran qu'avec 10 instances client connectées à un cluster de 5 nœuds, nous obtenons un nombre de requêtes par seconde compris entre 180,000 190,000 et 5 XNUMX. Et comme nous avons XNUMX NCache les serveurs qui fonctionnent en parallèle, l'accumulation de ces requêtes nous amène à 1 million de requêtes par seconde par ce cluster de cache.
Nous optimisons l'utilisation de la mémoire et du processeur, et la durée moyenne d'une opération de cache en microsecondes est légèrement inférieure à 10 microsecondes. La première étape est terminée : nous avons atteint 1 million d'opérations par seconde sur notre cluster de cache.
| Étape 1 – Fiche de données récapitulative | |
| Nombre total de serveurs de cache dans le cluster | 5 |
| Nombre total d'instances client connectées | 10 |
| Requêtes par seconde / nœud | 180,0000 ~ 190,000 |
| Nombre total de requêtes - Cluster de cache | 950,000 ~ 1,000,000 |
| % Temps processeur (max.) | 20 % |
| Mémoire système | 4.2 GB |
| Latence (microseconde/opération de cache) | 10 microsecondes/opération |
Maintenant que nous avons atteint le million de TPS, il est temps d'augmenter la charge en ajoutant des instances d'application pour accroître la charge transactionnelle. Dès que ces applications s'exécuteront, le compteur de requêtes par seconde augmentera. Nous allons augmenter le nombre de clients à 1. Avec cette configuration, la capture d'écran ci-dessous montre que nous affichons désormais 20 300,000 requêtes par seconde par instance. Nous avons atteint 1.5 million de requêtes par seconde pour ce cluster de cache.
Vous pouvez constater que le nombre de requêtes par seconde pour chaque serveur est de 300,000 200,000. Les récupérations sont légèrement supérieures à 50,000 100,000 par seconde et les mises à jour entre 4 3 et 4 XNUMX. La durée moyenne par opération de cache est inférieure à XNUMX microsecondes. C'est remarquable car la latence est très faible, grâce à l'impact du pipelining. Lorsque la charge transactionnelle côté client est élevée, le pipelining est très utile : il réduit la latence et augmente le débit. C'est pourquoi nous recommandons son activation. De plus, la durée moyenne par opération de cache est désormais d'environ XNUMX à XNUMX microsecondes.
| Étape 2 – Fiche de données récapitulative | |
| Nombre total de serveurs de cache dans le cluster | 5 |
| Nombre total d'instances client connectées | 20 |
| Requêtes moyennes par seconde / nœud | 300,000 |
| Nombre total de requêtes - Cluster de cache | 1,500,000 |
| % Temps processeur (max.) | 30 % |
| Mémoire système | 6 GB |
| Latence (microseconde/opération de cache) | 3 à 4 microsecondes/opération |
Augmentez encore la charge en exécutant davantage d'instances d'application, ce qui entraînera une augmentation supplémentaire du nombre de requêtes par seconde. Nous allons maintenant connecter 30 instances client à l'ensemble NCache les serveurs.
Comme le montre la capture d'écran ci-dessous, vous pouvez maintenant voir que nous avons atteint avec succès 400,000 XNUMX requêtes par seconde que nous obtenons à chaque NCache serveur; nous en avons 5 NCache serveurs, ce qui porte le nombre à deux millions de transactions par seconde d'ici là NCache Cluster de cache. La durée moyenne par opération de cache est inférieure à 3 microsecondes. La mémoire système et le temps processeur sont également bien en dessous des limites, avec une utilisation de 40 à 50 % sur les deux fronts.
Nous obtenons maintenant une latence de 2 à 3 µs par opération, ce qui représente une amélioration par rapport au résultat précédent. On constate à nouveau un mélange de récupérations, de mises à jour et une utilisation efficace des ressources CPU et mémoire. Nous pouvons en conclure que NCache est linéairement évolutif. Examinons maintenant nos chiffres d'évolutivité.
| Étape 3 – Fiche de données récapitulative | |
| Nombre total de serveurs de cache dans le cluster | 5 |
| Nombre total d'instances client connectées | 30 |
| Requêtes moyennes par seconde / nœud | 400,000 |
| Nombre total de requêtes - Cluster de cache | 2,000,000 |
| % Temps processeur (max.) | 60 % |
| Mémoire système | 6 GB |
| Latence (microseconde/opération de cache) | 2 à 3 microsecondes/opération |
Nous avons pu démontrer que NCache est linéairement évolutif et nous avons pu obtenir les résultats suivants après avoir exécuté les tests de performance :
© Copyright Alachisoft 2002 - . Tous droits réservés. NCache est une marque déposée de Diyatech Corp.