Quelle est la latence DANS un centre de données? Je pose cette question en supposant qu'il existe des ordres de grandeur de différence

J'essaie de comprendre quelque chose auquel je ne trouve tout simplement pas de bonne réponse.

Si je dis un cache REDIS (ou un cache externe en mémoire) assis dans un centre de données et un serveur d'applications assis dans le même centre de données, quelle sera la vitesse de la connexion réseau (latence, débit) pour lire les données entre ces deux machines?

La «vitesse» du réseau, par exemple, sera-t-elle toujours au moins d'un ordre de grandeur supérieure à la vitesse de la RAM qui recherche mes données dans le cache sur REDIS?

Ma question ultime est - le fait d'avoir tout cela en mémoire sur REDIS fournit-il réellement une utilité? Contrairement à si REDIS mettait tout cela en cache sur un SSD à la place? La mémoire coûte cher. Si le réseau n'est en effet pas un goulot d'étranglement DANS le centre de données, alors la mémoire a de la valeur. Sinon, ce n'est pas le cas.

Je suppose que ma question générale est malgré les vastes inconnues dans les centres de données et l'impossibilité de généraliser ainsi que les variances, parlons-nous d'ordres de grandeur suffisants entre la latence de la mémoire dans un système informatique et même les meilleurs réseaux internes à un DC que la mémoire est des latences réduites n'apportent pas une amélioration significative des performances? Je comprends qu'il existe de nombreuses variables, mais est-il proche? Est-il si proche que ces variables comptent? Par exemple, prenez une position hyperbolique dessus, un lecteur de bande est bien plus lent que le réseau, donc la bande n'est pas idéale pour un cache.

cache

— Neeraj Murarka
source

Cela dépend également du nombre d'aller-retour par transaction, c'est souvent le vrai problème que vous sérialisez dans une séquence de requêtes. Une interface de requête plus complexe, une procédure côté serveur ou un cache denormalizwd peut réduire l'impact.

— Eckes

Réponses:

Il existe plusieurs versions des «tableaux de latence que tout le monde devrait connaître», telles que:

En réalité, il y a plus que de la latence. C'est une combinaison de facteurs.

Alors, quelle est la latence du réseau dans un centre de données? Latence, eh bien je dirais que c'est "toujours" en dessous de 1ms. Est-ce plus rapide que la RAM? Non. Est-il proche de la RAM? Je ne pense pas.

Mais la question demeure, est-elle pertinente. Est-ce la donnée que vous devez connaître? Votre question est logique pour moi. Comme tout a un coût, si vous obtenez plus de RAM pour que toutes les données puissent rester dans la RAM ou que vous puissiez lire de temps en temps sur le disque.

Votre "hypothèse" est que si la latence du réseau est plus élevée (plus lente) que la vitesse du SSD, vous ne gagnerez pas en ayant toutes les données dans la RAM car vous aurez le ralentissement sur le réseau.

Et il semblerait que oui. Mais, vous devez également prendre en compte la simultanéité. Si vous recevez 1 000 demandes de données à la fois, le disque peut-il effectuer 1 000 demandes simultanées? Bien sûr que non, alors combien de temps cela prendra-t-il pour répondre à ces 1 000 demandes? Par rapport à la RAM?

Il est difficile de le résumer à un seul facteur tel que des charges lourdes. Mais oui, si vous n'aviez qu'une seule opération en cours, la latence du réseau est telle que vous ne remarqueriez probablement pas la différence entre SSD et RAM.

Tout comme jusqu'à ce qu'un disque 12 Gbit / s apparaisse sur le marché, une liaison réseau 10 Gbit / s ne serait pas surchargée par un seul flux car le disque était le goulot d'étranglement.

Mais rappelez-vous que votre disque fait beaucoup d'autres choses, votre processus n'est pas le seul processus sur la machine, votre réseau peut transporter différentes choses, etc.

En outre, toutes les activités du disque ne signifient pas le trafic réseau. La requête de base de données provenant d'une application vers le serveur de base de données n'est qu'un trafic réseau très minime. La réponse du serveur de base de données peut être très petite (un seul numéro) ou très grande (milliers de lignes avec plusieurs champs). Pour effectuer l'opération, un serveur (serveur de base de données ou non) peut avoir besoin d'effectuer plusieurs recherches, lectures et écritures sur disque mais n'envoyer qu'un très petit bit sur le réseau. Ce n'est certainement pas une RAM de disque réseau un pour un.

Jusqu'à présent, j'ai évité certains détails de votre question - en particulier, la partie Redis.

Redis est un magasin de structure de données en source ouverte (sous licence BSD), utilisé comme base de données, cache et courtier de messages. - https://redis.io/

OK, cela signifie donc que tout est en mémoire. Désolé, ce disque SSD rapide ne vous aidera pas ici. Redis peut conserver les données sur le disque, elles peuvent donc être chargées dans la RAM après un redémarrage. C'est seulement pour ne pas "perdre" de données ou avoir à repeupler un cache froid après un redémarrage. Dans ce cas, vous devrez donc utiliser la RAM, quoi qu'il arrive. Vous devrez avoir suffisamment de RAM pour contenir votre ensemble de données. Pas assez de RAM et je suppose que votre système d'exploitation utilisera swap- probablement pas une bonne idée.

— ETL
source

Merci. C'est en effet utile. Il existe en effet de nombreuses différences contextuelles qui ont une incidence sur ce point. Si nous ignorons les charges lourdes pendant un moment, il semble d'après votre réponse qu'en effet, la latence du réseau est le goulot d'étranglement, de sorte que la latence supplémentaire du SSD par rapport à la RAM n'est tout simplement pas assez importante pour avoir de l'importance. Mais maintenant, si nous prenons en compte les charges lourdes, les différences de latence du SSD par rapport à la RAM commencent à s'aggraver, et maintenant, la RAM brillera. Est-ce à cela qu'il se résume alors?

— Neeraj Murarka

Il est difficile de le résumer à un seul facteur de charges lourdes. Mais oui, si vous n'aviez qu'une seule opération en cours, la latence du réseau est telle que vous ne remarqueriez probablement pas la différence entre SSD et RAM. Tout comme jusqu'à ce qu'un disque 12 Gbit / s apparaisse sur le marché, une liaison réseau 10 Gbit / s ne serait pas surchargée par un seul flux car le disque était le goulot d'étranglement. Mais rappelez-vous que votre disque fait beaucoup d'autres choses, votre processus n'est pas le seul processus sur la machine, etc.

— ETL

Notez également qu'il existe de nombreux autres facteurs à prendre en compte en plus de la latence, en particulier que la plupart des services réels doivent exécuter plusieurs instances du programme serveur sur différentes machines, donc "tout en RAM localement" n'est normalement pas une option pratique du tout.

— chrylis -on strike-

Mais une liaison réseau 10g est bas de gamme. Mes serveurs sont connectés à mon backbone avec 200gigabit (oui, 2x100g liens).

— TomTom

Il existe de nombreuses couches de cache dans les systèmes informatiques. L'insertion d'une couche dans la couche application peut être bénéfique, en mettant en cache l'API et les requêtes de base de données. Et éventuellement des données temporaires comme des sessions utilisateur.

Les magasins de données comme Redis fournissent un tel service sur un réseau (rapide) ou un socket UNIX (encore plus rapide), tout comme vous utiliseriez une base de données.

Vous devez mesurer les performances réelles de votre application, mais inventons un exemple. Supposons qu'une requête utilisateur commune effectue 5 requêtes API qui prennent chacune 50 ms. 250 ms est une latence détectable par l'utilisateur. Contrairement à la mise en cache des résultats. Même si le cache se trouve dans une zone de disponibilité différente à travers la ville (pas optimale), les hits sont probablement de 10 ms au maximum. Ce serait une accélération 5x.

En réalité, la base de données et les systèmes de stockage ont également leurs propres caches. Cependant, il est généralement plus rapide d'obtenir un résultat pré-extrait que de parcourir à nouveau le moteur de base de données et les couches du système de stockage. De plus, la couche de mise en cache peut réduire considérablement la charge de la base de données située derrière.

Pour un exemple d'un tel cache en production, ne cherchez pas plus loin que le blog de l'infrastructure Stack Overflow sur l'architecture . Des centaines de milliers de requêtes HTTP générant des milliards de hits Redis sont assez importantes.

La mémoire coûte cher.

La DRAM à des temps d'accès de 100 ns est environ 100 fois plus rapide que le stockage permanent à semi-conducteurs. Il est relativement peu coûteux pour cette performance. Pour de nombreuses applications, un peu plus de RAM achète une vitesse et un temps de réponse précieux.

— John Mahowald
source

Pouvez-vous préciser comment vous avez calculé que chacune de ces 5 requêtes API prend 50 ms chacune? Est-ce sous le prétexte que l'application accède à la base de données et effectue la requête et calcule le jeu de résultats, par rapport à un cache dans la ville qui se trouve avoir mis en cache la chaîne de requête elle-même comme clé et avoir une copie en cache de ce résultat ensemble?

— Neeraj Murarka

J'ai inventé ces chiffres, mais oui. Faire une requête et calculer à nouveau un résultat sera probablement plus lent que d'obtenir ce résultat pré-calculé. Les implémentations comme Redis ont tendance à être en mémoire pour plus de simplicité et de rapidité. La traversée d'un réseau IP ou d'un transport de socket UNIX peut également être assez rapide. Cela dit, cette mise en cache n'est pas requise pour chaque conception.

— John Mahowald

Compris. Je pense que je comprends plus ou moins. Il semble que dans de nombreux cas, mais pas tout le temps, même en sortant du centre de données vers un cache proche qui se trouve peut-être dans le même état américain (ou province canadienne, etc.) (la région est peut-être une bonne sémantique) peut souvent être un grand avantage par rapport au processus essayant de recalculer la valeur de manière algorithmique à partir de sa propre base de données locale, si cela aboutit en fait à un accès au cache. Mais alors, le cache qui pourrait être assis à distance n'offre pas beaucoup de valeur en étant en mémoire. Il peut tout aussi bien être basé sur SSD.

— Neeraj Murarka

Le centre de données distant est le pire des cas, idéalement le niveau de cache est à moins de 1 ms de ses clients. Peut-être même zone de disponibilité, ou même sur le même hôte. Vous pouvez mettre en cache sur un stockage persistant si vous le souhaitez. Vous pouvez également utiliser ce stockage à semi-conducteurs pour la base de données principale, accélérer toutes les requêtes et éventuellement ne pas avoir besoin d'un niveau de mise en cache. Il existe plusieurs modèles possibles.

— John Mahowald