Sto usando memcacheper l'archiviazione della sessione e nelle pagine delle categorie ho notato in nuove transazioni reliquie in cui l'avvio della sessione varien può richiedere più di 30 secondi.
Potrebbe essere qualcosa a che fare con il blocco della sessione, ma ho pensato che questo non fosse davvero un problema quando si utilizza memcache.
Qualcuno l'ha mai affrontato o ha idee su cosa potrebbe causare questo.
Risposte:
L'ho visto parecchio anche su New Relic.
Da quello che ho visto ci sono alcune cause diverse, non ho una completa comprensione di questo problema, ma è qualcosa che ho esaminato di recente. Ecco i miei risultati.
Ogni azione del controller in Magento utilizza la sessione, sia che sia necessaria o meno. La sessione è avidamente istanziata in Mage_Core_Controller_Varien_Action :: preDispatch
Se il blocco della sessione è abilitato, ciò significa che per la durata della richiesta la sessione viene bloccata fino al completamento della richiesta. Non ho ancora trovato il codice che rilascia il blocco della sessione, ma sono abbastanza sicuro che sia lì da qualche parte.
In definitiva, ciò significa che se si eseguono più richieste simultanee alle azioni del controller Magento da un'unica posizione utilizzando la stessa sessione, sarà necessario attendere il completamento di alcune di tali richieste e procedere allo sblocco della sessione. Di solito vedo questo come una transazione lenta su una nuova reliquia bloccata a Mage_Core_Model_Session_Abstract_Varien::start~ 30 secondi (credo che il mio timeout di attesa per il blocco della sessione).
Questo rapporto su New Relic presenta diversi aspetti negativi a mio avviso
Ho visto alcune cause comuni per questo, non un elenco definitivo in alcun modo
I crawler come Baidu e Yandex sono un po 'maleducati e maltrattano il sito web. Vengono eseguiti da una posizione che genera numerose richieste, utilizza la stessa sessione e fa scattare il meccanismo di blocco della sessione, mostrando quindi transazioni lente in New Relic.
Con i siti Web verniciati, i dati specifici del cliente devono essere caricati con cura, alcuni siti Web lo gestiscono utilizzando le chiamate Ajax al backend Magento per ottenere i dati richiesti. Ho anche visto alcuni siti Web che utilizzavano chiamate Ajax al back-end per ottenere informazioni specifiche sul prodotto, come ad esempio l'importo lasciato disponibile quando un articolo è in vendita.
Se una singola pagina attiva più chiamate ajax al back-end al caricamento della pagina, può potenzialmente innescare il meccanismo di blocco della sessione. Più ajax richiama il backend Magento, più è probabile che si verifichi il blocco.
Lo stesso di quanto sopra in realtà, tranne che invece di utilizzare le chiamate Ajax utilizza Edge Side Includes che sembrano essere nuove chiamate al back-end.
Non l'ho ancora fatto, quindi è puramente teorico, ma è qualcosa che sto cercando di fare nei prossimi mesi.
Ho sollevato questo problema durante la conferenza Mage Titans UK 2016 e Fabrizio Branca mi ha indicato il seguente modulo: https://github.com/AOEpeople/Aoe_BlackHoleSession .
Basato su un'espressione regolare, il modulo impedirà ai robot di creare sessioni reali, questo dovrebbe avere il vantaggio che nessun blocco di sessione verrà colpito e che le risorse della sessione non saranno danneggiate da robot maleducati. I robot non dovrebbero più inquinare le letture della Nuova reliquia.
Per le chiamate ajax / ESI per ottenere i dati dei clienti lì sulle pagine memorizzate nella cache non c'è niente che tu possa fare che io possa vedere. È necessario accedere alla sessione per recuperare i dati specifici del cliente.
Tuttavia , per le chiamate ajax / ESI per ottenere dati specifici del catalogo (come scorte limitate), non vedo alcuna necessità che esista una sessione su quella richiesta. Il mio piano per il futuro è di Aoe_BlackHoleSessionprovare un'estensione del modulo in modo da poter eseguire il silo delle richieste a un URL specifico come senza sessioni.
Ho meno familiarità con gli interni di ESI, quindi purtroppo non ho molto da commentare lì.
Durante la conferenza Fabrizio Branca ha dichiarato di essere stato in grado di disabilitare completamente il blocco della sessione senza effetti negativi, testare a proprio rischio.