Je reprends InceptionDB après deux mois à consacrer le peu de temps libre qu'il me reste à faire avancer flowtest.io (je veux croire que ce sera le service qui va révolutionner la façon de tester les API).

Malgré le temps écoulé, je me souviens très clairement que je travaillais à optimiser les performances, j'avais l'objectif psychologique de dépasser le million d'insertions par seconde (sur un seul nœud). Le million n'a pas été difficile à dépasser, mais avec l'IA, j'étais déterminé à dépasser le million confortablement. En réalité, j'étais déterminé à le pousser un peu au-delà de l'absurde et du nécessaire en explorant plusieurs alternatives et en attaquant les différentes couches d'abstraction d'Inception.

J'ai refait les derniers tests et le résultat est si fou qu'on dirait que quelque chose ne va pas. Je sélectionne le premier benchmark : INSERT, je l'exécute et il se termine presque instantanément. Ça doit être faux ! Le journal est clair, il a inséré 1 million en moins de 200 ms mais je n'y crois pas, je pense que j'ai dû désactiver la persistance et qu'il travaille uniquement en mémoire, ou qu'il n'y a pas de contrôle de concurrence et que les données se chevauchent, ou qu'il a compté les données envoyées mais le serveur les a jetées dans /dev/null.

sent: 1000000 took: 182.928406ms Throughput: 5466619.55 rows/sec Closing 'col-1779494946505865611'... http: Server closed

Je me méfie, je peux imaginer mille autres raisons mais je place un point d'arrêt juste avant de supprimer la base de données et je réexécute. Résultat presque identique malgré le débogage mais maintenant j'ai ceci : /tmp/inceptiondb_bench_811457574/col-1779494946505865611 et il n'est pas vide mais ne fait que 41 MiB. Sans trop réfléchir, je le déplace dans le répertoire de données de mon Inception local, je le démarre, je charge la page et le voilà, 1M. Et il semble même que les données soient correctes.

Collection du benchmark avec 1M de documents
Collection du benchmark avec 1M de documents

Je n'y crois toujours pas, je crée un index, je lance une requête par ordre croissant et je trouve le premier document, le 0. Je change l'ordre et le dernier document est aussi là, le 999999. Tout semble en ordre. Je cesse de regarder l'écran pour vérifier que je respire encore.

L'idée m'effleure d'écrire un article de blog mais avant je répète le test. Cette fois avec 10 millions.

sent: 10000000 took: 1.078983549s Throughput: 9267981.90 rows/sec Closing 'col-1779498339775263815'... http: Server closed

Près de 10 millions par seconde, ce qui selon moi représente 410 MiB. Clairement, c'est encore très loin d'atteindre le goulot d'étranglement du disque qui atteint 9,4 GiB/s dans les vrais tests, cela ne représente même pas 5%.

Le benchmark comporte plusieurs tests pour mesurer les performances de scénarios spécifiques : INSERT, PATCH, REMOVE mais il y en a d'autres dont je ne me souvenais pas : INSERTPK, INSERTBTREE, RETRIEVEBTREE, RETRIEVEFS.

Je vais tous les exécuter et noter les performances de chacun.

INSERT Throughput: 8785855.31 rows/sec Throughput Open: 8780487.73 rows/sec INSERTPK Throughput: 5890949.19 rows/sec Throughput Open: 2374067.17 rows/sec INSERTBTREE Throughput: 1766108.26 rows/sec Throughput Open: 3165092.19 rows/sec RETRIEVEBTREE Throughput: 5412335.80 docs/sec RETRIEVEFS Throughput insert: 9249222.80 rows/sec Throughput Full scan (no filter): 13145243.10 docs/sec Throughput Full scan with filter: 4265889.26 docs/sec PATCH Throughput: 2735628.98 rows/sec Throughput Open: 9973488.60 rows/sec REMOVE Throughput: 1622765.40 rows/sec Throughput Open: 14321483.85 rows/sec

En général, on dépasse le million par seconde dans toutes les opérations. Au fait, laisse-moi te rappeler que le Throughput Open est la même opération mais au démarrage de la base de données. C'est pertinent car Inception repose uniquement sur un journal pour persister les données, donc pour retrouver l'état, il doit lire l'intégralité du journal avant d'être à nouveau opérationnel.