Come trovare l'unica riga che rende lento un checkout.

I reclami su un negozio lento sono del tipo vago, reputazionale. Nessuno stack trace, nessun numero di riga, solo un commerciante che riferisce che un acquirente l'ha detto, e l'aritmetica sotto: un checkout lento è un carrello abbandonato, e un carrello abbandonato è fatturato che esce dalla porta a metà acquisto. Quindi il primo compito non è sistemare nulla. È trasformare una sensazione in una posizione.

Il reclamo arriva come una sensazione

La formulazione è reputazionale, non tecnica: un acquirente ha detto al commerciante che il sito sembrava lento, e il commerciante lo riferisce. Per un negozio, «checkout lento» non è una pignoleria: sono carrelli abbandonati al passo del pagamento, il posto più costoso di tutto il sito in cui perdere qualcuno. Questo inquadra l'urgenza, ma non indica alcuna direzione. Lento è una sensazione, non una posizione.

Misurate prima la piattaforma sotto il carico che fallisce

Partite dalla piattaforma, misurata sotto l'esatto carico che sta fallendo: CPU, load average, memoria libera, utilizzo del disco, sul livello web e sul database. Leggeteli mentre la lentezza sta accadendo, non da un dashboard mediato su una settimana tranquilla. Se ogni livello è inattivo, l'attesa vive nell'applicazione o in qualcosa che essa chiama, e il resto del metodo serve a trovare cosa.

È lì che molte diagnosi si fermano. «È l'app» è vero e inutile per un commerciante: scagiona l'host e lascia il negozio esattamente bloccato come prima. Il proprietario di un negozio non vuole sapere che è l'app. Vuole sapere quale riga, e perché. Quindi il metodo prosegue dentro codice che non è nostro da sistemare, perché trovare la riga è il vero deliverable.

La homepage cercherà di nasconderlo

La prima cosa che un controllo a campione mostra sembra rassicurante, ed è questa la trappola. La homepage, in cache sul CDN, torna veloce. Se controllate un negozio caricando la sua pagina iniziale, concludete che va tutto bene e chiudete il ticket. Ma una homepage in cache non dimostra nulla sul checkout, perché il dolore vive solo sui percorsi che non possono essere messi in cache: il carrello dinamico e il checkout, dove il negozio esegue il suo vero codice a ogni richiesta.

Raggruppate per dove si blocca, non per dove parte

La mossa che spacca il caso trasforma il rumore in una confessione. Invece di indovinare, catturate ogni richiesta più lenta di una soglia su tutti i nodi web, poi raggruppate gli stack trace per l'unica cosa che conta. Non dove ogni richiesta è partita (partono tutte da un URL), ma la riga esatta in cui ogni richiesta è bloccata, ferma ad aspettare. Raggruppate migliaia di richieste lente per il loro punto di blocco e le congetture finiscono. Un gruppo torreggia sugli altri, e in un negozio è di solito una chiamata in uscita dal vivo verso un sistema che il negozio non gestisce: un controllo di giacenza, una ricerca di prezzo, un punteggio antifrode, un ERP, seduto dentro la validazione dell'ordine. Una chiamata al database che alimenta la stessa integrazione è di solito il gruppo subito sotto.

Leggete una richiesta bloccata dall'inizio alla fine

Lo stack di una richiesta bloccata mostra l'intera catena dal punto di ingresso fino alla chiamata esterna su cui sta aspettando: il pulsante di pagamento in cima, la validazione dell'ordine nel mezzo, e in fondo una chiamata verso una macchina su un'altra rete, dove la richiesta resta finché quella macchina non risponde. Quella è l'immagine da mostrare al commerciante, perché non ha bisogno di interpretazione: una persona che sta cercando di dare soldi al negozio sta aspettando un sistema che il negozio non gestisce prima ancora che l'ordine venga validato.

Poi leggete la configurazione del client per quella chiamata. Il tetto dell'attesa è una singola riga: il suo timeout. Un timeout del client impostato in minuti, dove il percorso di pagamento ha bisogno di secondi, significa che un acquirente può essere trattenuto al pulsante di pagamento per tutto il tempo che il partner impiega a rispondere, e la giornata lenta del partner diventa quella del negozio.

“Un acquirente che cerca di pagare sta aspettando una macchina che il negozio non gestisce, su una rete che il negozio non gestisce, prima ancora che l'ordine venga validato.”

Controllate le query sottostanti

Il log delle query lente del database di solito punta alla stessa integrazione: le query che la alimentano scansionano invece di cercare, e stanno nello stesso percorso. La chiamata esterna è lenta, le query sotto di essa sono lente, ed entrambe stanno tra l'acquirente e l'ordine. Sistemare la chiamata senza le query lascia il secondo collo di bottiglia al suo posto.

Non riscriviamo il vostro checkout. Vi consegniamo la riga.

Non riscriviamo il checkout di un cliente: è il suo codice, la sua logica di business, il suo rischio. Ciò che consegniamo è più utile e più difficile da ottenere: il file esatto, la riga esatta e la correzione specifica. Tre mosse, in ordine.

La lezione

Un server sano e inattivo non è quasi mai il posto in cui vive la lentezza. Quando la piattaforma è calma e l'acquirente aspetta, l'attesa è nel livello applicativo o in qualcosa che esso chiama, e il metodo qui sopra trova quale riga.

La disciplina qui è la stessa dietro altre due letture: come dimensionare un server, dove la maggior parte delle persone ha bisogno di meno di quanto pensi, e perché un server nuovo fa benchmark più lenti del vecchio quando non lo è.