Quel est le but de la construction de page lockLoadData / uncached prend environ une minute, passé en mode usep


11

Je pense que depuis la mise à jour de Magento 2.3.1, j'ai des problèmes avec les chargements de page non mis en cache (pendant le développement).

J'ai fait une trace blackfire.io et il s'avère que 42 secondes sont passées en sommeil ici .

Maintenant, je me demande quel est le but de cela. Je suppose que je cours dans une sorte de condition de course?

Est-ce que quelqu'un a déjà vécu quelque chose comme ça?

EDIT: La pile d'appels semble impliquer commercebug.

Réponses:


8

Eh bien, c'est un - choix? - les ingénieurs de Magento l'ont fait.

Ce n'est pas une réponse, mais il semble que cette fonction accepte un rappel destiné à charger les données mises en cache. Le rappel vérifie s'il y a actuellement un verrou en place. Sinon, il met un verrou en place, charge les données, puis libère le verrou. S'il y a un bloc en place, il se met en veille pendant quelques 100,000microsecondes (0,1 seconde), puis appelle à nouveau le chargeur.

Donc, en pensant à haute voix, je suppose que

  1. Peut-être un nombre plus que normal de demandes à cette fonction
  2. Temps de lecture supérieurs à la normale depuis votre cache.


7

Le mécanisme lockLoadData doit diminuer la charge sur le serveur.

Auparavant, lorsque le cache de configuration était nettoyé sur des sites très chargés, tous les clients généraient les mêmes informations, ce qui augmentait considérablement la charge du processeur / io.

Avec LockLoadData, un seul client générera un cache et d'autres l'attendront.

Plus de détails sur son fonctionnement.

La première fonction appelle le rappel "get data" et s'il obtient les données, il suffit de les renvoyer (donc si les données dans le cache, le code fonctionne comme précédemment et n'utilise pas de verrous).

Si les données ne sont pas disponibles et que le verrou est verrouillé, alors dans la boucle, nous essayons de charger les données jusqu'à ce que les données soient récupérées ou que le verrou soit supprimé.

S'il n'y a pas de verrou, nous créons un verrou et générons des données dans l'enregistrer dans le cache et supprimer le verrou et retourner les données

PS: Nous avons envoyé ces modifications comme un patch pour l'un des clients avec une charge jusqu'à 20 kRPM et cela fonctionne au moins 3 mois, sans aucun problème. Alors peut-être le problème dans votre personnalisation / modules (par exemple s'ils ont cassé le mécanisme de cache)


Intéressant ... Quoi qu'il en soit, dans mon cas, cela devient fou. Je débogue cela avec Alan, PulseStorm
Alex

semble être une solution vraiment médiocre, signifie que tous les utilisateurs en attente garderont leur processus en vie .. pourquoi ne peuvent-ils pas simplement utiliser des verrous de table
OZZIE

@OZZIE préférez-vous que tous les utilisateurs génèrent des données, au lieu de dormir jusqu'à ce que l'un soit fait? Nous n'avons pas de ressources CPU libres de maths
KAndy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.