Qual è lo scopo del blocco di pagine LockLoadData / non memorizzato nella pagina richiede circa un minuto, passato in modalità sleep


11

Penso che dall'aggiornamento a Magento 2.3.1 ho problemi con i caricamenti di pagine non memorizzati (durante lo sviluppo).

Ho fatto una traccia blackfire.io e si scopre che qui sono trascorsi 42 secondi nel sonno .

Ora mi chiedo quale sia lo scopo di questo. Immagino di correre in una specie di condizione di gara?

Qualcuno ha mai provato qualcosa del genere prima?

EDIT: lo stack di chiamate sembra coinvolgere commercebug.

Risposte:


8

Bene, questa è una scelta? - gli ingegneri Magento realizzati.

Questa non è una risposta, ma sembra che quella funzione accetti un callback che ha lo scopo di caricare i dati memorizzati nella cache. La richiamata controlla se al momento è presente un blocco. In caso contrario, inserisce un blocco, carica i dati e quindi rilascia il blocco. Se è presente un blocco, viene sospeso per 100,000microsecondi (0,1 secondi), quindi chiama nuovamente il caricatore.

Quindi, pensando ad alta voce, la mia ipotesi sarebbe

  1. Forse un numero più che normale di richieste a questa funzione
  2. Tempi di lettura più alti del normale dalla cache.


7

Il meccanismo bloccatoLoadData deve ridurre il carico sul server.

In precedenza, quando la cache di configurazione veniva ripulita su siti ad alto carico, tutti i client avevano generato le stesse informazioni che aumentano significativamente il carico della CPU / io.

Con bloccatoLoadData solo un client genererà cache e gli altri aspetteranno.

Maggiori dettagli su come funziona.

La prima chiamata di funzione "richiama dati" richiama e se ottiene i dati, basta restituirli (quindi se i dati nella cache, il codice funziona come il precedente e non utilizza alcun blocco).

Se i dati non sono disponibili e il blocco è bloccato, nel ciclo proviamo a caricare i dati fino a quando i dati non vengono ricevuti o il blocco è stato rimosso.

Se non è presente alcun blocco, creiamo un blocco e generiamo dati per salvarlo nella cache e rimuovere il blocco e restituire i dati

PS: abbiamo inviato queste modifiche come una patch per uno dei client con un carico fino a 20kRPM e funziona almeno 3 mesi, senza alcun problema. Quindi forse il problema nella personalizzazione / nei moduli (ad esempio se hanno rotto il meccanismo della cache)


Interessante ... Comunque nel mio caso va fuori di testa. Sto eseguendo il debug di questo con Alan, PulseStorm
Alex

sembra una soluzione davvero scadente, significa che tutti gli utenti in attesa manterranno vivo il loro processo .. perché non possono semplicemente usare i blocchi di tabella
OZZIE

@OZZIE preferisci che tutti gli utenti generino dati, invece di dormire fino a quando uno è finito? Non abbiamo risorse CPU così matematiche libere
KAndy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.