Un super-calculateur de Nvidia avec 10000 carte graphiques H100 spécialisées pour les opérations sur les réseaux de neurones.
Ils ont pu entrainer un modèle GPT-3 en seulement 4 minutes alors qu'il a fallu plus de 30 jours pour l'entrainer il y a 3 ans (sur 1000 GPU)
Un site très complet pour apprendre à mieux utiliser sa DB et comprendre les problèmes de performances pour les régler.
Un benchmark de requêtage sur des vecteurs d'embeddings dans Postgres avec l'addon pgvector et dans le pure player Pinecone.
Sur un setup équivalent en coût chez Supabase, Postgres est 10x plus rapide avec la même précision.
Donc si on héberge sa propre base Postgres c'est encore moins cher!
A noter que Postgres est beaucoup plus qu'une base vectorielle et qu'on va pouvoir filtrer les résultats avec des WHERE, faire des jointures, etc
Une série d'articles pour améliorer la vitesse de chargement des pages web.
Un article qui parle des uuidv7 qui comportent une composante temporelle pour être triable par défaut tout étant utilisables dans des systèmes distribués car uniques.
Les performances sont bien supérieures et ça vient du fait qu'ils possèdent une partie aléatoire moins importante (en plus du fait qu'ils soient triable)
Un article très intéressant d'un big tech (Facebook) sur la manière dont ils ont scale leur cache basé sur Memcached à l'échelle de la planète.
Plusieurs article sur la manière de créer une timeline pour une application à fort trafic en utilisant Redis.
https://redis.io/docs/manual/patterns/twitter-clone/
https://livebook.manning.com/book/redis-in-action/chapter-8/
Un outil pour détecter les erreurs ou les problèmes de performances dans l'utilisation de modèles d'IA
Excellent article technique sur la manière dont Prisma à amélioré les performances au démarrage de son ORM.
La majorité du chemin a été achevé en simplifiant le protocol de communication interne en passant à du simple JSON.
Sinon on retrouve des choses assez classiques en terme d'optimisation, du lazy loading, pas de couche de chiffrement superflue et d'autres choses.
L'article décrit aussi le cycle de démarrage d'une lambda AWS.
Un article explicatif du besoin et du fonctionnement du load balancing.
Très bien expliqué et avec des schéma intéractifs!
Pour bien comprendre les besoins, il ne faut pas oublié que les requêtes ne sont pas égales, certaines sont plus longues ou plus consommatrices que d'autre à exécuter.
Au dela du "simple" round robin, d'autres stratégies existent:
- least connection: le load balancer envoie la requête au serveur en ayant le moins en cours
- peak exponentially weighted moving average: calcul de la latence moyenne des serveurs et tente d'utiliser uniquement les serveurs ayant la plus faible latence
Explications très détaillées sur le compilateur Just In Time (JIT) introduit dans PHP 8.
Concrètement ça améliore la vitesse d'exécution de votre code au fur et à mesure que celui-ci est executé en compilant spécifiquement en code machine (assembleur) certaines function qui sont appellés toujours avec les mêmes types.
C'est le même principe que le JIT dans la JVM ou v8.
je ne suis pas sûr que vous obteniez des améliorations aussi bonnes mais ça ouvre la porte à d'autres types d'applications boudés par souci de performances, comme l'IA, le jeu vidéo, les statistiques..
Par contre ça m'étonnerait qu'on se mette à faire de l'IA, du jeu vidéo ou n'importe quoi d'autre qui demande des performances avec PHP car le JIT reste quand même bien moins optimisé qu'une compilation Ahead Of Time (C++, Rust, Golang, etc)
Une histoire d'optimisation d'un cluster Elasticsearch.
Le problème chez Netflix venait d'une mauvaise allocation des shards des indices, tous les indices avaient le même nombre de shards et donc certains noeuds se retrouvent à héberger des shards contenant des millions de documents.
Leur stratégie a été de distribuer les documents non pas par type mais par date de création (time buckets) en utilisant des index template pour la création automatique et des alias pour la recherche (comme pour l'ingestion des logs donc).
Un retour d'expérience de Cloudflare sur la ré-écriture d'un module Nginx en Rust.
Un benchmark des librairies et bases de données (en RAM) pour traiter des données tabulaires dans le genre de Pandas.
Polars remporte haut la main le benchmark, c'est une lib écrite en Rust et qui utilise aussi le standard Arrow
Apache Arrow est un projet qui développe des SDK dans la plupart des langages afin de manipuler efficacement des données tabulaires (vecteurs, matrices) en RAM.
Ils ont notamment des optimisations des calculs spécialement conçues pour les CPU et les GPU.
Par exemple, les données sont regroupées pour éviter les "jump" CPU et tenter de les faire tenir dans les différents caches.
Pour les GPU, Arrow utilise CUDA afin de paralléliser les calculs.
C'est utilisé dans la nouvelle version 2.0 de Pandas, la lib de référence en Python pour manipuler les données.
Les performances peuvent être jusqu'à 25x supérieurs (!)
(Merci Ocav pour le partage)
Un retour d'expérience sur l'utilisation de Cassandra à un très haut niveau chez Discord.
Des problèmes de maintenance majoritairement liés à la manière dont ils utilisaient Cassandra car des ralentissements en lecture sur un noeud impactaient tout le cluster car la lecture/écriture se fait en quorum.
La "compaction" (réindexation) des tables par Cassandra et le GC de la JVM causaient aussi des problèmes de latence.
Ils ont décidé de migrer toutes leurs DB vers ScyllaDB qui est compatible Cassandra mais en C++ donc plus rapide et pas de GC!
Il n'ont pas réglé leur problème qu'avec une nouvelle base de données mais aussi avec des middleware de cache écrit en Rust pour la performance C++ et la sureté mémoire.
La migration fut aussi très compliqué et les premières prévisions étaient extrèmement longues (3 mois) mais la encore un rewrite du connecteur en Rust sauve la mise (9 jours!)
Conclusions:
- plus de stabilité
- 177 noeuds Cassandra à 72 ScyllaDB
- latence p99 40-125ms avec Cassandra et 15ms avec ScyllaDB
Un framework C++ pour construire des application server performantes.
Au menu:
- sharding
- network stack
- futur et promises (JS like <3)
- message passing pour le multithread (afin d'éviter les couteux lock)
ScyllaDB est écrit avec
Une belle performance algorithmique sur l'algorithme de chunking de Rollup avec 3.3s au lieu de 2 heures pour la génération du plus petit nombre de chunks.
L'auteur utilise un seul BigInt et manipule directement les bits au lieu de manipuler un Set.
Un broker MQTT écrit en Erlang avec de très hautes performances affichées:
- 100 millions de clients
- 1 million de message /seconde
- millisecond latency
- cluster masterless
En plus du broker, il y a aussi une super interface d'administration /dashboard !
Il intègre aussi un moteur de règle qui permet de faire du filtrage et de l'enrichissement avec un DSL basé sur le langage SQL.
Des présentation sur des concepts avancés de Postgres:
- Performance Tuning
- Explaining the Query Optimizer
- Joins and Indexes
- Database hardware
- Scaling opportunities
- Future of Sharding
(Merci Ocav pour le partage)