Accélérer les connecteurs PHP pour Tarantool avec Async, Swoole et Parallel

Dans l'écosystème PHP, il existe actuellement deux connecteurs pour travailler avec le serveur Tarantool ― c'est l'extension officielle PECL tarantool/tarantool-php, écrite en C, et tarantool-php/client, écrite en PHP. Je suis l'auteur de ce dernier.

Dans cet article, je voudrais partager les résultats des tests de performance des deux bibliothèques et montrer comment, avec des modifications minimes du code, on peut atteindre une augmentation de 3 à 5 % de performance (sur des tests synthétiques !).

Qu'allons-nous tester ?

Nous testerons les connecteurs mentionnés ci-dessus synchrones , lancés de manière asynchrone, parallèlement et de manière asynchrone-parallèle. 🙂 De plus, nous ne voulons pas toucher le code des connecteurs eux-mêmes. Actuellement, plusieurs extensions sont disponibles pour atteindre l'objectif souhaité :

• Swoole ― un framework asynchrone haute performance pour PHP. Utilisé par des géants d'internet comme Alibaba et Baidu. Depuis la version 4.1.0, la méthode magique SwooleRuntime::enableCoroutine(), permet « en une ligne de code de transformer les bibliothèques réseau synchrones PHP en asynchrones ».
• Async ― jusqu'à récemment, une extension très prometteuse pour le travail asynchrone en PHP. Pourquoi jusqu'à récemment ? Malheureusement, pour une raison qui m'est inconnue, l'auteur a supprimé le dépôt et l'avenir du projet est incertain. Il nous faudra utiliser un des forks. Comme Swoole, cette extension permet en un geste de remplacer l'implémentation standard des flux TCP et TLS par leurs versions asynchrones. Cela se fait via l'option «async.tcp = 1«.
• Parallel ― une extension assez récente de Joe Watkins, l'auteur de bibliothèques comme phpdbg, apcu, pthreads, pcov, uopz. L'extension fournit une API pour le travail multithreadé en PHP et se positionne comme un remplacement pour pthreads. Une limitation importante de la bibliothèque est qu'elle ne fonctionne qu'avec la version ZTS (Zend Thread Safe) de PHP.

Comment allons-nous tester ?

Nous allons lancer une instance de Tarantool sans journal d'écriture anticipée (wal_mode = none) et avec un tampon réseau agrandi (readahead = 1 * 1024 * 1024). La première option exclura les opérations d'écriture sur disque, la seconde permettra de lire plus de requêtes à partir du tampon du système d'exploitation, minimisant ainsi le nombre d'appels système.

Pour les benchmarks qui fonctionnent avec des données (insertion, suppression, lecture, etc.), un espace memtx sera (re)créé avant le début du benchmark, où les valeurs de l'index primaire sont générées par un générateur de valeurs entières séquentielles.
La DDL de l'espace est la suivante :

space = box.schema.space.create(config.space_name, {id = config.space_id, temporary = true})
space:create_index('primary', {type = 'tree', parts = {1, 'unsigned'}, sequence = true})
space:format({{name = 'id', type = 'unsigned'}, {name = 'name', type = 'string', is_nullable = false}})

Si nécessaire, avant de lancer le benchmark, l'espace est rempli avec 10 000 tuples de la forme

{id, "tuplе_"}

L'accès aux tuples se fait par une valeur de clé aléatoire.

Le benchmark lui-même est une seule requête au serveur qui est exécutée 10 000 fois (révolutions), qui, à leur tour, sont effectuées en itérations. Les itérations se répètent tant que toutes les déviations de temps entre 5 itérations ne se situent pas dans une marge d'erreur acceptable de 3 %*. Après cela, le résultat moyen est pris. Entre les itérations, il y a une pause d'1 seconde, afin de ne pas permettre au processeur de passer en throttling. Le collecteur de déchets Lua est désactivé avant chaque itération et est forcé de s'exécuter après sa terminaison. Le processus PHP est lancé uniquement avec les extensions nécessaires pour le benchmark, avec la mise en tampon de sortie activée et le collecteur de déchets désactivé.

* Le nombre de révolutions, d'itérations et le seuil d'erreur peuvent être modifiés dans les paramètres du benchmark.

Environnement de test

Les résultats publiés ci-dessous ont été réalisés sur un MacBookPro (2015), système d'exploitation — Fedora 30 (version du noyau 5.3.8-200.fc30.x86_64). Tarantool a été exécuté dans Docker avec le paramètre--network host".

Versions des paquets :

Tarantool : 2.3.0-115-g5ba5ed37e
Docker : 19.03.3, build a872fc2f86
PHP : 7.3.11 (cli) (construit : 22 oct. 2019 08:11:04)
tarantool/client : 0.6.0
rybakit/msgpack : 0.6.1
ext-tarantool : 0.3.2 (+ patch pour 7.3)*
ext-msgpack : 2.0.3
ext-async : 0.3.0-8c1da46
ext-swoole : 4.4.12
ext-parallel : 1.1.3

* Malheureusement, le connecteur officiel ne fonctionne pas avec la version PHP > 7.2. Pour compiler et exécuter l'extension sur PHP 7.3, il a fallu utiliser patch.

Résultats

Mode synchrone

Le protocole de Tarantool utilise un format binaire MessagePack pour la sérialisation des messages. Dans le connecteur PECL, la sérialisation est profondément cachée au sein de la bibliothèque et il n'est pas possible d'influencer le processus d'encodage depuis le code userland .. Le connecteur en PHP pur, quant à lui, offre la possibilité de personnaliser le processus de codage en étendant le codeur standard ou en utilisant sa propre implémentation. Deux codeurs sont disponibles par défaut, l'un basé sur msgpack/msgpack-php (l'extension officielle MessagePack PECL), l'autre étant basé sur rybakit/msgpack (en PHP pur).

Avant de comparer les connecteurs, mesurons les performances des codeurs MessagePack pour le connecteur PHP, et lors des tests suivants, nous utiliserons celui qui montrera le meilleur résultat :

Bien que la version PHP (Pure) soit moins rapide que l'extension PECL, dans des projets réels, je recommanderais tout de même d'utiliser rybakit/msgpack, car dans l'extension officielle MessagePack, la spécification du format n'est mise en œuvre que partiellement (par exemple, il n'y a pas de support pour les types de données personnalisés, sans lesquels vous ne pourrez pas utiliser Decimal - un nouveau type de données introduit dans Tarantool 2.3) et présente plusieurs autres des problèmes (y compris des problèmes de compatibilité avec PHP 7.4). Dans l'ensemble, le projet semble abandonné.

Mesurons donc les performances des connecteurs en mode synchrone :

Comme le montre le graphique, le connecteur PECL (Tarantool) affiche de meilleures performances par rapport au connecteur en PHP (Client). Ce n'est pas surprenant, compte tenu du fait que ce dernier, en plus d'être implémenté dans un langage plus lent, effectue en réalité plus de travail : à chaque appel, un nouvel objet est créé Request et Response (dans le cas de Select — aussi Criteria, et dans le cas de Update/Upsert — Operations), des entités distinctes Connexion, Packer et Handler ajoutent également un surcoût. Il est évident que la flexibilité a un prix. Cependant, dans l'ensemble, l'interpréteur PHP montre de bonnes performances, même si la différence existe, elle est minime et sera probablement encore plus faible avec l'utilisation de preloading dans PHP 7.4, sans parler de JIT dans PHP 8.

Continuons. Dans Tarantool 2.0, le support de SQL a été ajouté. Essayons d'effectuer des opérations Select, Insert, Update et Delete en utilisant le protocole SQL et comparons les résultats avec leurs équivalents noSQL (binaires) :

Les résultats SQL ne sont pas très impressionnants (je rappelle que nous testons toujours le mode synchrone). Cependant, je ne voudrais pas me décourager à ce sujet trop tôt, car le support de SQL est encore en développement actif (récemment, par exemple, le support de prepared statements) a été ajouté, et d'après la liste issues, le moteur SQL attendra d'autres optimisations.

Async

Voyons maintenant comment l'extension Async peut nous aider à améliorer les résultats ci-dessus. Pour écrire des programmes asynchrones, l'extension fournit une API basée sur des coroutines, que nous allons utiliser. Par expérimentation, nous découvrons que le nombre optimal de coroutines pour notre environnement est de 25 :

Nous 'étalons' 10 000 opérations sur 25 coroutines et voyons ce que cela donne :

Le nombre d'opérations par seconde a plus que triplé pour tarantool-php/client!

Malheureusement, le connecteur PECL ne s'est pas lancé avec ext-async.

Qu'en est-il de SQL ?

Comme vous le voyez, en mode asynchrone, la différence entre le protocole binaire et SQL est dans les limites de l'erreur.

Swoole

Nous découvrons à nouveau le nombre optimal de coroutines, cette fois pour Swoole :

Nous nous limiterons à 25. Répétons la même astuce qu'avec l'extension Async : répartissons 10 000 opérations entre 25 coroutines. De plus, nous ajouterons un autre test, dans lequel nous diviserons tout le travail en 2 processus (c'est-à-dire que chaque processus effectuera 5 000 opérations dans 25 coroutines). Les processus seront créés à l'aide de SwooleProcess.

Résultats :

Swoole montre légèrement de moins bons résultats par rapport à Async lors de l'exécution dans un seul processus, mais avec 2 processus, la situation change radicalement (le nombre 2 n'est pas choisi au hasard, sur ma machine, 2 processus ont montré les meilleurs résultats).

D'ailleurs, l'extension Async a aussi une API pour travailler avec des processus, mais je n'ai pas remarqué de différences significatives lors de l'exécution des benchmarks dans un ou plusieurs processus (il est possible que j'aie fait une erreur quelque part).

SQL vs protocole binaire :

Tout comme avec Async, la différence entre les opérations binaires et SQL est atténuée en mode asynchrone.

Parallel

Puisque l'extension Parallel ne concerne pas les coroutines, mais les threads, mesurons le nombre optimal de threads parallèles :

Il est de 16 sur ma machine. Lançons des benchmarks de connecteurs sur 16 threads parallèles :

Comme vous le voyez, le résultat est même meilleur qu'avec les extensions asynchrones (à l'exception de Swoole exécuté sur 2 processus). Notez que pour le connecteur PECL, il n'y a rien sur les opérations Update et Upsert. Cela est dû au fait que ces opérations ont échoué avec une erreur - je ne sais pas si c'est à cause de ext-parallel, ext-tarantool ou des deux.

Comparons maintenant les performances de SQL :

Avez-vous remarqué la similitude avec le graphique des connecteurs exécutés de manière synchrone ?

Tout ensemble

Enfin, rassemblons tous les résultats dans un seul graphique pour voir la vue d'ensemble des extensions testées. Nous allons ajouter un nouveau test que nous n'avons pas encore effectué : exécuter des coroutines Async en parallèle avec Parallel*. L'idée d'intégrer les extensions mentionnées ci-dessus a déjà été discutée par les auteurs, mais aucun consensus n'a été atteint, il va donc falloir le faire soi-même.

* Lancer des coroutines Swoole avec Parallel n'a pas fonctionné, il semble que ces extensions soient incompatibles.

Voici donc les résultats finaux :

En conclusion

À mon avis, les résultats sont assez remarquables, et j'ai l'impression que ce n'est pas encore la limite ! Il vous revient de décider si cela vous est nécessaire dans un projet réel, je dirai seulement que pour moi, cela a été une expérience intéressante, permettant d'évaluer combien on peut « tirer » d'un connecteur TCP synchronisé avec un minimum d'efforts. Si vous avez des idées pour améliorer les benchmarks, je considérerai avec plaisir votre pull request. L'ensemble du code avec les instructions de lancement et les résultats a été publié dans un dépôts.

Source : habr.com