Pourquoi mon subgraph se synchronise-t-il si lentement ?
Mis à jour en août 2026
Très probablement parce que les subgraphs traitent l'historique de façon séquentielle — un bloc après l'autre — de sorte que le temps de synchronisation s'accroît avec la quantité d'historique de chaîne couverte. Les appels de contrat dans vos handlers et les écritures d'entités lourdes multiplient ensuite cette base.
La cause structurelle, c'est le modèle de traitement, pas votre configuration. Le réglage fin aide à la marge ; changer la façon dont l'historique est traité est ce qui résout réellement le problème.
Quelles sont les vraies causes ?
Le traitement séquentiel. Le subgraph parcourt l'historique bloc par bloc. Il n'y a aucun moyen de contourner cela par du réglage — c'est le fonctionnement même du modèle.
Les appels de contrat dans les handlers. Un eth_call dans un handler signifie un aller-retour réseau par événement. C'est la cause auto-infligée la plus courante, et elle peut dominer tout le reste. Si vous appelez symbol() ou decimals() à chaque transfert, c'est votre problème.
Les écritures d'entités lourdes. Chaque save() est une écriture en base de données. Charger, modifier et enregistrer plusieurs entités par événement s'accumule rapidement sur des millions d'événements.
Les plages de blocs trop larges. Un bloc de départ plus ancien que nécessaire signifie traiter de l'historique que vous n'interrogerez jamais.
La latence RPC. La source de données sous-jacente compte. Un endpoint lent ou soumis à des limites de débit ralentit tout ce qui en dépend.
Que puis-je corriger moi-même ?
À faire avant tout changement structurel :
| Problème | Correction |
|---|---|
eth_call dans les handlers | Mettre en cache les valeurs immuables ; les stocker une fois plutôt que de les récupérer à chaque événement |
| Bloc de départ trop tôt | Le régler au bloc de déploiement du contrat, ou au bloc le plus ancien dont vous avez réellement besoin |
| Écritures d'entités excessives | Regrouper les mises à jour ; éviter les boucles charger-modifier-enregistrer quand vous pouvez calculer directement |
| Indexation d'événements inutilisés | Ne traiter que les événements dont votre schéma a besoin |
Ces mesures aident — parfois considérablement, en particulier la première. Mais ce sont des optimisations à l'intérieur d'un modèle séquentiel. Si vous devez couvrir des années d'un contrat très actif, vous parcourez toujours chaque bloc.
Comment corriger la cause structurelle ?
Vous déplacez l'extraction et la transformation hors du modèle séquentiel des subgraphs, vers Substreams, qui traite les segments historiques en parallèle puis passe en streaming en direct.
Cela change aussi ce que coûte un changement de schéma. Sous un traitement séquentiel, une resynchronisation est un projet que l'on évite. Sous un traitement parallèle, c'est une opération que l'on peut répéter, ce qui en pratique amène les gens à réellement corriger leurs modèles de données plutôt qu'à les contourner.
Comment savoir de quel problème je souffre ?
Observez le taux de synchronisation. S'il est à peu près constant et faible, le goulot d'étranglement est structurel — traitement séquentiel sur une large plage. S'il est erratique ou chute brutalement à certains blocs, vous avez probablement des appels de contrat ou des écritures lourdes déclenchés par une activité spécifique.
Constant et faible signifie changer de modèle. Erratique signifie corriger d'abord le handler.
Questions fréquentes
Un endpoint RPC plus rapide résoudra-t-il le problème ? Cela aide si le RPC est votre goulot d'étranglement, mais cela ne change rien au traitement séquentiel.
Dois-je réécrire mon subgraph ? Vous conservez votre schéma et votre interface de requête ; c'est la couche d'extraction sous-jacente qui change.
Cela affecte-t-il aussi l'indexation en direct ? L'indexation en direct est bornée par le temps de bloc, donc la douleur se situe presque toujours dans la synchronisation historique.
Obtenez une clé API sur thegraph.market — aucune information personnelle requise.
Voir aussi : Subgraph vs API — laquelle choisir ? · Puis-je obtenir l'historique complet et des données en temps réel depuis une seule source ?