- Expédié
- 20 août 2026 à 23:34 UTC
- Auteur
- Kamo
- Commite
- 8b4f5a2
Le chargement/leads a pris 23,3 s à 1 427 têtes. 23,3 s en étaient les HIPAA piste d'audit: recordLeadList écrit une ligne phi-access-log par plomb a été retourné et chacun a effectué sa propre transaction. Mesurés sur production 16,36 ms/ligne, 5 708 rangées sur 93 s sur quatre charges. Le SELECT était de 29,6 ms et ix-leads-org-id était utilisé - le chemin de lecture n'a jamais été le problème. Deux causes indépendantes, toutes deux fixées ici. La piste d'audit a passé en revue une transaction par ligne. trois index secondaires, donc sur Yugabyte un insert à une rangée est quatre écrits à travers les comprimés et donc une transaction distribuée. PhiAccessLogÉrIER gains writeAll et JpaPhiAccessLogWriter l'implémente en tant que seul sauvegarderAll, que SimpleJpaRepository exécute en une seule opération: mesurée 0,49 ms/ligne, 33x. AsyncPhiAccessLogWriter prend alors les types d'ouverture en panne dans le fil de la demande entièrement. Types fermés (exporter, télécharger, divulguer, configurer) encore en écriture synchrone avec l'exception intacte, afin qu'ils puissent encore refuser la lecture; la file d'attente ne laisse jamais tomber un enregistrement - a La file d'attente saturée écrit en ligne à la place. La granulosité est inchangée: Le plomb montré obtient toujours sa propre ligne. Le point d'extrémité a renvoyé l'ensemble de l'organisation et a laissé le filtrer le navigateur. , donc le volume d'audit était proportionnel à la taille du locataire plutôt qu'à ce qui a été divulgué. LeadGridQuery et LeadGridSpecifications déplace toutes les filter dans la requête et LeadService.getLeadGridPage retourne une page de la DTO à la rangée pauvre, projetée à l'intérieur de la transaction, de sorte que le point d'extrémité est maintenu aucune entité par la suite. Une Spécification plutôt que JPQL null-guards on purpose:p IS NULL OU col ':p' arrête le planificateur en utilisant le nouveau indices composites. Subquesries au lieu de traiter()/type()() pour l'hypothèque sous-classe, parce que la bibliothèque s'appuie sur Hibernate 6.5 et SecurityService Le 6.2.13 est le 6.2.13. Le plomb gagne quatre indices composites, chacun menant avec ORG-ID donc Yugabyte encore en suspens sur le locataire: affectation, marché, statut et DateCréité. Sans eux, le filtrage côté serveur déplacerait le balayage plutôt que de l'enlever. Aussi: la recherche du téléphone arrière du téléphone souple ne s'hydrate plus l'ensemble organisation permettant de comparer les numéros en Java. Ajout également findBatchAfterUid: un balayage de jeu de clés pour les cartes d'appui qui doit consulter toutes les pistes. findAll(Pageable) ne peut pas être utilisé pour cela sur Yugabyte et Spring Data combine son contenu SELECT avec un COUNT en un seul transaction, et un laissez-passer qui écrit entre les pages puis voyage une lecture redémarrer la couche de requête ne peut pas réessayer.