Pourquoi Rust est à la tête de la référence du framework TechEmpower

En fait, je n'avais pas l'intention de voir de quelle couleur étaient les tripes de Rust. J'ai choisi un projet de passe-temps sur Go, je suis allé sur GitHub pour voir l'état de fasthttp: est-ce qu'il se développe? Eh bien, au moins pris en charge? A grandi. Je suis allé, j'ai regardé où se situe fasthttp dans les benchmarks TechEmpower . Je regarde: et là, fasthttp montre à peine la moitié de ce que le leader réussit - à certains actix sur certains Rust. Quelle douleur.

Ici, je croisais les bras, me cognais la tête au sol (trois fois) et criais: "Alléluia, en vérité, Rust est un vrai dieu, comme j'étais aveugle avant!". Mais soit les poignées n'ont pas fonctionné, soit le front a regretté ... Au lieu de cela, je suis entré dans le code des tests écrits en Go et des tests actix-web en Rust. Pour le trier.

Après quelques heures, j'ai découvert:

1. pourquoi le framework rouille actix-web occupe la première place dans tous les tests TechEmpower,
2. comment Java démarre Script.

Maintenant, je vais tout vous dire dans l'ordre.

Qu'est-ce que TechEmpower Framework Benchmark?

Si un framework Web démontre s'il va ou, par exemple, pense parfois à chuchoter à des amis "je suis rapide", alors il tombera sûrement dans le référentiel du framework TechEmpower. Un endroit populaire pour mesurer les performances.

Le site a un design particulier: les onglets des filtres, des tours, des conditions et des résultats pour différents types de tests sont dispersés sur la page avec une main généreuse. Si généreux et si généreux que vous ne les remarquez tout simplement pas. Mais cela vaut la peine de cliquer sur les onglets, les informations derrière eux sont utiles.

Le moyen le plus simple consiste à obtenir les résultats du test en clair, "Bonjour tout le monde!" pour les serveurs Web. Les auteurs du cadre lui donnent généralement un lien: nous sommes censés rester dans les cent premiers. Le cas est correct et utile. En général, donner du texte en clair est bon pour beaucoup, et les dirigeants vont en groupe serré.

À proximité, dans ces mêmes onglets, se trouvent les résultats de tests d'autres types (scénarios). Il y en a sept, plus de détails peuvent être trouvés ici . Ces scripts testent non seulement la façon dont le framework / la plateforme gère le traitement d'une simple requête http, mais également une combinaison avec un client de base de données, un moteur de modèle ou un sérialiseur JSON.

Il existe des données de test dans un environnement virtuel, sur un matériel physique. En plus des graphiques, il existe des données tabulaires. En général, beaucoup de choses intéressantes, il vaut la peine de creuser, pas seulement de regarder la position de "votre" plate-forme.

La première chose qui m'est venue à l'esprit après avoir parcouru les résultats du test: "Pourquoi tout est-il SI SI différent du texte en clair?!". En texte clair, les dirigeants forment un groupe restreint, mais lorsqu'il s'agit de travailler avec la base de données, actix-web mène avec une marge importante. Dans le même temps, il affiche un temps de traitement des demandes stable. Shaitan.

Autre anomalie: une solution JavaScript incroyablement puissante. Il s'appelle ex4x. Il s'est avéré que son code était légèrement moins que complètement écrit en Java. Utilisé par le runtime Java, JDBC. Le code JavaScript est traduit en bytecode et colle les bibliothèques Java. Ils l'ont littéralement pris - et ont attaché Script à Java. Les astuces des visages pâles n'ont pas de limites.

Comment regarder le code et ce qu'il contient

Le code pour tous les tests est sur GitHub. Tout est dans un seul référentiel, ce qui est très pratique. Vous pouvez cloner et regarder, vous pouvez regarder directement sur GitHub. Les tests impliquent plus de 300 combinaisons différentes de l'infrastructure avec des sérialiseurs, des moteurs de modèle et le client de base de données. Dans différents langages de programmation, avec une approche différente du développement. Les implémentations dans une langue sont proches, cela peut être comparé à l'implémentation dans d'autres langues. Le code est maintenu par la communauté, ce n'est pas le travail d'une seule personne ou équipe.

Le code de référence est un endroit idéal pour élargir vos horizons. Il est intéressant d'analyser comment différentes personnes résolvent les mêmes problèmes. Il n'y a pas beaucoup de code, les bibliothèques et les solutions utilisées sont faciles à distinguer. Je ne regrette pas du tout d’être arrivé là-bas. J'ai beaucoup appris. Tout d'abord à propos de Rust.

Avant Rust, j'avais une idée très vague. Tout article sur C, C ++, D, et surtout Go est sûr d'avoir quelques commentateurs qui expliquent en détail et avec angoisse que la vanité, le non-sens et la stupidité sont écrits dans autre chose, tant qu'il y a Gascogne Rouille. Parfois, ils s'emballent tellement qu'ils donnent des exemples de code qu'une personne non préparée ou peu d'accepter conduit dans une stupeur: "Pourquoi, pourquoi, pourquoi tous ces symboles?!"

Par conséquent, l'ouverture du code était effrayante.

J'ai regardé. Il s'est avéré que les programmes de Rust peuvent être lus. De plus, le code est si bien lu que j'ai même installé Rust, j'ai essayé de compiler le test et de le bricoler un peu.

Ici j'ai failli abandonner cette affaire, car la compilation dure longtemps. Un temps très long. Si j'étais d'Artagnan, ou même simplement colérique, je me serais précipité en Gascogne, et mille démons traîneraient avec découragement. Mais je l'ai fait. J'ai encore bu du thé. Il semble que même pas une tasse: sur mon ordinateur portable, la première compilation a pris environ 20 minutes, puis, tout va plus amusant. Peut-être jusqu'à la prochaine grande mise à jour des caisses.

Mais n'est-ce pas Rust lui-même?

Non. Pas un langage de programmation.

Bien sûr, Rust est une langue merveilleuse. Puissant, flexible, mais par habitude et verbeux. Mais le langage lui-même n'écrira pas de code rapide. La langue est l'un des outils, l'une des décisions prises par le programmeur.

Comme je l'ai dit - donner du texte en clair est rapidement obtenu par beaucoup. Les performances des frameworks actix-web, fasthttp et une douzaine d'autres lors du traitement d'une simple demande sont assez comparables, c'est-à-dire que d'autres langages ont la capacité technique de rivaliser avec Rust.

Actix-web lui-même, bien sûr, est «à blâmer»: un produit rapide, pragmatique et excellent. La sérialisation est pratique, le moteur de modèle est bon - cela aide aussi beaucoup.

Plus particulièrement, les résultats des tests effectués avec la base de données diffèrent.

Après avoir creusé un peu dans le code, j'ai mis en évidence trois différences principales qui (il me semble) ont aidé les tests actix à se démarquer des concurrents dans les tests synthétiques:

1. Mode de fonctionnement pipelined pipelined tokio-postgres;
2. Utiliser une seule connexion avec un test Rust au lieu d'un pool de connexions avec un test écrit en Go;
3. Mise à jour des benchmarks actix avec une seule commande envoyée via une simple requête au lieu d'envoyer plusieurs commandes UPDATE.

Quel type de mode convoyeur?

Voici un extrait de la documentation tokio-postgres (utilisé dans le cas-test de la bibliothèque cliente PostgreSQL) expliquant ce que ses développeurs veulent dire:

Sequential Pipelined | Client | PostgreSQL | | Client | PostgreSQL | |----------------|-----------------| |----------------|-----------------| | send query 1 | | | send query 1 | | | | process query 1 | | send query 2 | process query 1 | | receive rows 1 | | | send query 3 | process query 2 | | send query 2 | | | receive rows 1 | process query 3 | | | process query 2 | | receive rows 2 | | | receive rows 2 | | | receive rows 3 | | | send query 3 | | | | process query 3 | | receive rows 3 | | 

Le client en mode pipelined (pipelined) n'attend pas de réponse PostgreSQL, mais envoie la requête suivante pendant que PostgreSQL traite la précédente. On peut voir que de cette façon, vous pouvez traiter la même séquence de requêtes de base de données beaucoup plus rapidement.

Si la connexion en mode pipeline est duplex (offrant la possibilité d'obtenir des résultats en parallèle avec l'envoi), ce temps peut être légèrement réduit. Il semble qu'il existe déjà une version expérimentale de tokio-postgres où une connexion duplex est ouverte.

Étant donné que le client PostgreSQL envoie plusieurs messages (Parse, Bind, Execute et Sync) à chaque requête SQL envoyée pour exécution et reçoit une réponse à ceux-ci, le mode pipeline sera plus efficace même lors du traitement de requêtes uniques.

Et pourquoi n'est-ce pas dans Go?

Parce que Go utilise généralement des pools de connexions de base de données. Les connexions ne sont pas destinées à être utilisées en parallèle.

Si vous exécutez les mêmes requêtes SQL via un pool, plutôt qu'une seule connexion, vous pouvez théoriquement obtenir un temps d'exécution encore plus court avec un client série ordinaire que lorsque vous travaillez via une seule connexion, que ce soit trois fois en pipeline:

 | Connection | Connection 2 | Connection 3 | PostgreSQL | |----------------|----------------|----------------|-----------------| | send query 1 | | | | | | send query 2 | | process query 1 | | receive rows 1 | | send query 3 | process query 2 | | | receive rows 2 | | process query 3 | | | receive rows 3 | | 

On dirait que la peau de mouton (mode convoyeur) ne vaut pas la chandelle.

Ce n'est que sous une charge élevée que le nombre de connexions au serveur PostgreSQL peut poser problème.

Et qu'est-ce que le nombre de connexions a à voir avec ça?

Le point ici est de savoir comment le serveur PostgreSQL répond à une augmentation du nombre de connexions.

Le groupe de colonnes de gauche montre l'augmentation et la baisse des performances de PostgreSQL en fonction du nombre de connexions ouvertes:

( Adapté du post Percona )

On peut voir qu'avec une augmentation du nombre de connexions ouvertes, les performances du serveur PostgreSQL chutent rapidement.

De plus, l'ouverture d'une connexion directe n'est pas «gratuite». Immédiatement après l'ouverture, le client envoie des informations de service, "est d'accord" avec le serveur PostgreSQL sur la façon dont les demandes seront traitées.

Par conséquent, dans la pratique, vous devez limiter le nombre de connexions actives à PostgreSQL, en les passant souvent en plus via pgbouncer ou une autre odyssée.

Alors pourquoi Actix-Web a-t-il été plus rapide?

Tout d'abord, actix-web lui-même est sacrément rapide. C'est lui qui fixe le «plafond», et il est légèrement supérieur à celui des autres. Les autres bibliothèques utilisées (serde, yarde) sont également très, très productives. Mais il me semble que dans les tests fonctionnant avec PostgreSQL, il a été possible de se détacher car le serveur actix-web démarre un thread sur le cœur du processeur. Chaque thread ouvre une seule connexion à PostgreSQL.

Moins il y a de connexions actives, plus PostgreSQL fonctionne rapidement (voir les graphiques ci-dessus).

Le client fonctionnant en mode pipeline (tokio-postgres) vous permet d'utiliser efficacement une connexion avec PostgreSQL pour le traitement parallèle des requêtes des utilisateurs. Les gestionnaires de requêtes HTTP déchargent leurs commandes SQL dans une file d'attente et s'alignent dans une autre pour recevoir les résultats. Les résultats sont amusants, les retards sont minimes, tout le monde est content. Les performances globales sont supérieures à celles d'un système avec un pool de connexions.

Vous devez donc abandonner le pool, écrire un client de pipeline PostgreSQL, et le bonheur et la vitesse incroyable viendront tout de suite?

C'est possible. Mais pas tout d'un coup.

Lorsque le mode convoyeur est peu susceptible de sauver et ne sauvera certainement pas

Le schéma utilisé dans le code de référence ne fonctionnera pas avec les transactions PostgreSQL.

Dans le benchmark, les transactions ne sont pas nécessaires et le code est écrit en tenant compte du fait qu'il n'y aura pas de transactions. En pratique, cela arrive.

Si le code backend ouvre une transaction PostgreSQL (par exemple, pour effectuer une modification dans deux tables atomiques différentes), toutes les commandes envoyées via cette connexion seront exécutées à l'intérieur de cette transaction.

Puisque la connexion avec PostgreSQL est utilisée en parallèle, tout y est mélangé. Les commandes qui doivent être exécutées dans une transaction telle que conçue par le développeur sont mélangées avec des commandes sql lancées par des gestionnaires de requêtes http parallèles. Nous recevrons des pertes de données aléatoires et des problèmes d'intégrité.

Alors bonjour transaction - au revoir utilisation parallèle d'une connexion. Vous devrez vous assurer que la connexion n'est pas utilisée par d'autres gestionnaires de requêtes http. Vous devrez soit arrêter le traitement des requêtes http entrantes avant de fermer la transaction, soit utiliser un pool pour les transactions, en ouvrant plusieurs connexions au serveur de base de données. Il existe plusieurs implémentations de pool pour Rust, et aucune. De plus, ils existent dans Rust séparément de l'implémentation du client de base de données. Vous pouvez choisir selon le goût, la couleur, l'odeur ou au hasard. Go ne fonctionne pas de cette façon. Le pouvoir des génériques, oui.

Un point important: dans le test, dont j'ai regardé le code, les transactions ne s'ouvrent pas. Cette question n'en vaut tout simplement pas la peine. Le code de référence est optimisé pour une tâche spécifique et des conditions de fonctionnement d'application très spécifiques. La décision d'utiliser une connexion par flux de serveur a probablement été prise consciemment et s'est avérée très efficace.

Y a-t-il autre chose d'intéressant dans le code de référence?

Oui

Le scénario de mesure des performances est décrit en détail. Ainsi que les critères que le code participant aux tests doit satisfaire. L'un d'eux est que toutes les requêtes adressées au serveur de base de données doivent être exécutées séquentiellement.

Le fragment de code suivant (légèrement abrégé) semble ne pas répondre aux critères:

  let mut worlds = Vec::with_capacity(num); //  num    PostgreSQL for _ in 0..num { let w_id: i32 = self.rng.gen_range(1, 10_001); worlds.push( self.cl .query(&self.world, &[&w_id]) .into_future() .map(move |(row, _)| { // ... }), ); } //     stream::futures_unordered(worlds) .collect() .and_then(move |worlds| { // ... }) 

Tout ressemble à un lancement typique de processus parallèles. Mais comme une connexion à PostgreSQL est utilisée, les requêtes vers le serveur de base de données sont envoyées séquentiellement. Un par un. Au besoin. Pas de crime.

Pourquoi Eh bien, tout d'abord, dans le code (il a été donné à la rédaction, qui a travaillé au 18e tour), async / attente n'est pas encore utilisé, il est apparu plus tard dans Rust. Et grâce à futures num il est plus facile d'envoyer des requêtes SQL "en parallèle" - comme dans le code ci-dessus. Cela vous permet d'obtenir une amélioration supplémentaire des performances: alors que PostgreSQL accepte et traite la première requête SQL, les autres y sont alimentées. Le serveur Web n'attend pas le résultat de chacun, mais passe à d'autres tâches et ne revient au traitement de la requête http que lorsque toutes les requêtes SQL sont terminées.

Pour PostgreSQL, le bonus est que le même type de requête dans le même contexte (connexion) va de suite. La probabilité que le plan de requête ne soit pas reconstruit augmente.

Il s'avère que les avantages du mode pipeline (voir le schéma de la documentation tokio-postgres) sont pleinement exploités même lors du traitement d'une seule requête http.

Quoi d'autre?

Utilisation du protocole de requête simple pour les mises à jour par lots

Le protocole de communication entre le client et le serveur PostgreSQL permet des méthodes alternatives pour exécuter des commandes SQL. Le protocole habituel (Extended Query) consiste à envoyer plusieurs messages à un client: Parse, Bind, Execute et Sync. Une alternative est le protocole Simple Query, selon lequel un seul message suffit pour exécuter une commande et obtenir des résultats - Query.

La principale différence entre le protocole habituel est le transfert des paramètres de requête: ils sont transmis séparément de la commande elle-même. C’est plus sûr. Le protocole simplifié suppose que tous les paramètres de la requête SQL seront convertis en chaîne et inclus dans le corps de la requête.

Une solution intéressante utilisée dans les benchmarks actix-web était de mettre à jour plusieurs entrées de table avec une seule commande envoyée via le protocole Simple Query.

Selon le benchmark, lors du traitement d'une demande utilisateur, le serveur web doit mettre à jour plusieurs enregistrements de la table, écrire des nombres aléatoires. De toute évidence, la mise à jour des enregistrements successivement avec des requêtes séquentielles prend plus de temps qu'une seule requête mettant à jour tous les enregistrements à la fois.

La demande générée dans le code de test ressemble à ceci:

 UPDATE world SET randomnumber = temp.randomnumber FROM (VALUES (1, 2), (2, 3) ORDER BY 1) AS temp(id, randomnumber) WHERE temp.id = world.id 

Où (1, 2), (2, 3) sont les paires d'identificateurs de ligne / nouvelle valeur du champ de numéro aléatoire.

Le nombre d'enregistrements mis à jour est variable, préparer la demande (PREPARE) à l'avance n'a pas de sens. Étant donné que les données à mettre à jour sont numériques et que la source peut être fiable (le code de test lui-même), il n'y a aucun risque d'injection SQL, les données sont simplement incluses dans le corps SQL et tout est envoyé à l'aide du protocole Simple Query.

Une rumeur simple circule. J'ai rencontré une recommandation: "Ne travaillez que sur le protocole Simple Query, et tout sera rapide et correct." Je la perçois avec beaucoup de scepticisme. Simple Query vous permet de réduire le nombre de messages envoyés au serveur PostgreSQL en déplaçant le traitement des paramètres de requête côté client. Vous pouvez voir le gain pour les requêtes générées dynamiquement avec un nombre variable de paramètres. Pour le même type de requêtes SQL (qui sont plus courantes), le gain n'est pas évident. Eh bien et à quel point le traitement des paramètres de requête se révélera sûr, dans le cas de Simple Query, il détermine la mise en œuvre de la bibliothèque cliente.

Comme je l'ai écrit ci-dessus, dans ce cas, le corps de la requête SQL est généré dynamiquement, les données sont numériques et générées par le serveur lui-même. La combinaison parfaite pour Simple Query. Mais même dans ce cas, il vaut la peine de tester d'autres options. Les alternatives dépendent de la plateforme et du client PostgreSQL: pgx (client for Go) permet d'envoyer un paquet de commandes, JDBC - pour exécuter une commande plusieurs fois de suite avec des paramètres différents. Les deux solutions peuvent fonctionner à la même vitesse ou même être plus rapides.

Alors, pourquoi Rust est-il en tête?

Le chef, bien sûr, n'est pas Rust. Les tests basés sur actix-web mènent - c'est lui qui fixe le "plafond" de la performance. Il y a, par exemple, la fusée et le fer, qui occupent des positions modestes. Mais pour le moment, c'est actix-web qui détermine le potentiel d'utilisation de Rust dans le développement web. Quant à moi, le potentiel est très élevé.

Un autre serveur "secret" non évident mais important basé sur actix-web, qui a permis de prendre la première place dans tous les benchmarks TechEmpower - dans la façon dont il fonctionne avec PostgreSQL:

1. Une seule connexion avec PostgreSQL par flux de serveur Web s'ouvre. Cette connexion utilise le mode pipeline, ce qui lui permet d'être efficacement utilisé pour le traitement parallèle des demandes des utilisateurs.
2. Moins il y a de connexions actives, plus PostgreSQL répond rapidement. La vitesse de traitement des demandes des utilisateurs augmente. Dans le même temps, sous charge, l'ensemble du système fonctionne de manière plus stable (les délais de traitement des demandes entrantes sont plus faibles, ils augmentent plus lentement).

Lorsque la vitesse est importante, cette option sera probablement plus rapide que l'utilisation de multiplexeurs (tels que pgbouncer et odyssey). Et il était certainement plus rapide dans les repères.

Il est très intéressant de voir comment async / wait, qui est apparu dans Rust, et le récent drame avec actix-web affectera la popularité de Rust dans le développement Web. Il est également intéressant de voir comment les résultats des tests changeront après les avoir traités en asynchronisation / attente.