Actualités du développement Safe 🇫🇷 1 septembre 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 01 September, 2022

Au cours de ce qui a été une bonne semaine tout au long de la recherche d’anomalies et de bogues insignifiants, nous demandons à @joshuef d’expliquer comment nous abordons les problèmes dus à la sérialisation des messages et au stress que cela impose au réseau. Quelque chose d’un :bulb: celui-ci…

Progrès général

@davidrusu a réglé un problème où les adultes sautaient les sondes anti-entropie avant les scissions, ils n’avaient donc pas toujours la mise à jour nécessaire informations de date sur les sections.

Pendant ce temps, @bochaco travaille sur une liste d’améliorations concernant la manière dont nous stockons les registres (données modifiables - CRDT), y compris la modification de certaines API internes du magasin pour éviter de cloner certains objets, d’écrire des opérations individuelles (au lieu d’un fichier qui pourrait être écrasé par un autre CRDT incomplet), de supprimer certains types d’erreurs de stockage inutilisés et d’ajouter plus d’informations contextuelles à d’autres, et de permettre le stockage des commandes d’édition de registre pour tous les cas (maintenant l’ordre des commandes entrantes devrait être moins important, c’est-à-dire qu’il n’y a pas de condition de concurrence pour avoir un CreateRegister Cmd avant un EditRegister, qui se trouve sur main).

Et @chriso a amélioré la gestion des erreurs dans sn_node, y compris le type de messages d’erreur envoyés au client, pour faciliter la tâche des utilisateurs pour voir ce qui se passe.

Sérialisation des messages

Nous avons vu de @southside’s probing que le réseau semble être soumis à des contraintes avec des PUT de données plus volumineux. Ses tests de téléchargements de plus de 2 Go ont mis en lumière un problème là-bas qui peut-être fait partie de la raison… et cela pourrait simplement être trop de messages.

Cela ne signifie pas que nous en envoyons trop (bien que nous puissions en envoyer moins). Mais il semble que la pression exercée par la formation de messages, et la vitesse à laquelle nous le faisons, est sacrément trop élevée.

Cela a été quelque chose que nous avons vu dans les heaptraces de l’utilisation de la mémoire du nœud pendant un certain temps, mais la voie à suivre pour corriger n’était pas vraiment claire.

Nous " sérialisons " chaque message en octets, et étant donné que nous devons créer un " MsgHeader " différent pour chaque nœud, il n’y avait pas grand-chose à faire.

Et si nous ne le faisions pas ?

Cependant, le coup de poing de @southside a remis la question au premier plan, et @joshuef, qui était ennuyé par la quantité de mémoire utilisée par la sérialisation depuis un moment maintenant, a décidé de se cogner à nouveau la tête contre elle.

Et cette fois une autre idée a surgi. Nous avions essayé de supprimer le besoin de Dst (destination, information sur l’endroit où le message est destiné à aller) auparavant… mais nous ne pouvons pas le faire et garder nos flux Anti-Entropy en vie. C’était donc un non-partant.

Mais après quelques tentatives de hacky pour mettre à jour le Dst Bytes dans un message pré-sérialisé, pour éviter de refaire tout ce travail, nous avons réalisé que nous forcions une cheville carrée dans un trou rond. À savoir, la limitation consistant à ne fournir qu’un seul « octet » d’un message n’avait en fait aucun sens pour nous.

SOooOooooo…

Donc, après un peu de refactorisation dans qp2p, notre wrapper réseau, nous pouvons maintenant envoyer trois ensembles différents de Bytes sur nos connexions, et parmi ceux-ci, un seul (notre Dst) doit réellement changer si nous ’ envoie le même message à différents nœuds !

Cela signifie qu’au lieu de 7x le travail lors de l’envoi d’un message aux anciens de la section, c’est 1x - et nous réutilisons les Bytes pour notre MsgHeader et Payload ! Il suffit de ré-encoder Dst à chaque fois.

Soigné.

Mais attendez… il y a plus !

Maintenant, c’est déjà une réduction décente du coût de calcul de l’envoi d’un message. Mais il a aussi un autre avantage en termes de mémoire. Auparavant, lors de la sérialisation de MsgHeader, nous formions notre one ensemble de Bytes en copiant la charge utile (le message réel que nous envoyons … donc ~ 1 Mo par bloc), il s’agit donc d’un travail d’allocation de mémoire, et cela signifie chaque message avait son propre ensemble unique d’« octets » représentant la même « charge utile ». Donc, envoyer un morceau à quatre adultes aurait cinq copies de ce morceau en mémoire. :frowning:

Mais maintenant nous utilisons une copie bon marché de Bytes (qui est un type de pointeur vers les données sous-jacentes …) donc aucune duplication de mémoire n’est nécessaire ! Donc, envoyer un morceau à quatre adultes ne devrait nécessiter qu’une seule copie des données maintenant :tada:

En fin

Voici à quoi ressemble main. Ici, nous voyons trois exécutions des 250 tests clients (un PUT de 5 Mo et 250 clients essayant simultanément d’obtenir ces données), puis 10 exécutions de la suite de tests standard complète sn_client.

Et c’est sur le PR en attente:

Vous pouvez voir que les pics de ces tests semblent dépasser plus rapidement et avec moins de mémoire globale (~ 900 Mo contre 1 800 Mo). Et avec cela, notre nouveau débit de mesure de référence consiste à envoyer un WireMsg à 1 000 Dsts différents.

  • débit principal : 7,5792 Mio/s
  • Débit PR : 265,25 Mio/s

Ce qui est assez plaisant aussi.

La branche n’est pas encore fusionnée, il reste quelques derniers réglages à faire avant de l’intégrer, mais cela ressemble à un changement prometteur qui pourrait aider les nœuds à fonctionner sur du matériel plus léger (ou, espérons-le, laisser @southside en télécharger plus sur ses réseaux de test locaux !? :doigts croisés: )


Liens utiles

N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.

En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!