Cómo encontrar la única línea que hace lento un checkout.
Cuando una tienda online parece lenta y los servidores están inactivos, la espera suele ser una llamada síncrona al sistema de otro dentro de la ruta de la petición. El método que convierte «parece lenta» en archivo y línea.
En este artículo 8 secciones
Las quejas de que una tienda online va lenta son de las vagas, de reputación. Sin stack trace, sin número de línea, solo un comerciante que transmite que lo dijo un comprador, y la aritmética que hay debajo: un checkout lento es un carrito abandonado, y un carrito abandonado son ingresos que se marchan a mitad de la compra. Así que el primer trabajo no es arreglar nada. Es convertir una sensación en una ubicación.
- Mida la plataforma bajo la carga que está fallando, no en un momento tranquilo: CPU, load, memoria, disco, en cada nivel. Si todos los niveles están inactivos, la espera vive en la aplicación o en algo a lo que llama.
- No confíe en la portada cacheada. La sirve la CDN y no demuestra nada sobre el carrito y el checkout, que ejecutan código de aplicación en vivo en cada petición.
- Capture cada petición más lenta que un umbral y agrupe los stack traces por dónde está bloqueada cada petición, no por dónde empezó. Un grupo destaca sobre los demás, y suele ser una llamada síncrona a un sistema que la tienda no opera.
- Entregue el archivo exacto, la línea exacta y la solución: un timeout corto con fallback, la llamada externa movida a un job en segundo plano, y las consultas que hay debajo indexadas para que busquen en lugar de escanear.
La queja llega como una sensación
La formulación es de reputación, no técnica: un comprador le dijo al comerciante que el sitio parecía lento, y el comerciante lo transmite. Para una tienda, «checkout lento» no es un detalle menor: son carritos abandonados en el paso del pago, el lugar más caro de todo el sitio para perder a alguien. Eso enmarca la urgencia, pero no señala a ninguna parte. Lento es una sensación, no una ubicación.
Una alarma de recursos le dice dónde mirar. «El sitio va lento» no le dice nada: puede ser la red, el host, la base de datos, la aplicación o un tercero que la tienda ni siquiera opera. Antes de poder arreglarlo tiene que convertir una sensación en un número de línea. El resto de este texto es el cómo.
Mida primero la plataforma bajo la carga que falla
Empiece por la plataforma, medida bajo la carga exacta que está fallando: CPU, load average, memoria libre, utilización de disco, en el nivel web y en la base de datos. Léalos mientras ocurre la lentitud, no desde un dashboard que promedia una semana tranquila. Si todos los niveles están inactivos, la espera vive en la aplicación o en algo a lo que llama, y el resto del método consiste en encontrar qué.
Ahí es donde se detienen muchos diagnósticos. «Es la aplicación» es cierto e inútil para un comerciante: exculpa al host y deja la tienda exactamente tan atascada como antes. El propietario de una tienda no quiere saber que es la aplicación. Quiere saber qué línea, y por qué. Así que el método sigue adentrándose en código que no nos corresponde arreglar, porque encontrar la línea es el verdadero entregable.
La portada intentará ocultarlo
Lo primero que muestra una comprobación rápida parece tranquilizador, y esa es la trampa. La portada, cacheada en la CDN, vuelve rápida. Si comprueba una tienda cargando su primera página, concluye que todo está bien y cierra el ticket. Pero una portada cacheada no demuestra nada sobre el checkout, porque el dolor vive solo en las rutas que no se pueden cachear: el carrito dinámico y el checkout, donde la tienda ejecuta su código real en cada petición.
| La portada cacheada | La ruta del checkout |
|---|---|
| Servida desde el edge de la CDN | Ejecuta código de aplicación en vivo cada vez |
| WHERE THE PAIN LIVESRápida en cada comprobación rápida | Donde vive realmente cada segundo de la espera |
| Parece perfectamente sana | Nunca la toca una comprobación rápida de la portada |
Agrupe por dónde se bloquea, no por dónde empieza
El movimiento que lo abre convierte el ruido en una confesión. En lugar de adivinar, capture cada petición más lenta que un umbral en todos los nodos web, y después agrupe los stack traces por lo único que importa. No por dónde empezó cada petición (todas empiezan en una URL), sino por la línea exacta en la que cada petición está bloqueada, sentada y esperando. Agrupe miles de peticiones lentas por su punto de bloqueo y se acaban las conjeturas. Un grupo destaca sobre los demás, y en una tienda suele ser una llamada saliente en vivo a un sistema que la tienda no opera: una comprobación de stock, una consulta de precio, una puntuación de fraude, un ERP, dentro de la validación del pedido. Una llamada a la base de datos que alimenta la misma integración suele ser el siguiente grupo.
Lea una petición bloqueada de arriba abajo
El stack de una petición bloqueada muestra toda la cadena desde el punto de entrada hasta la llamada externa a la que espera: el botón de pago arriba, la validación del pedido en medio, y al fondo una llamada hacia una máquina en otra red, donde la petición se queda hasta que esa máquina responde. Esa es la imagen que hay que enseñar al comerciante, porque no necesita interpretación: una persona que intenta darle dinero a la tienda está esperando a un sistema que la tienda no opera antes incluso de que el pedido se valide.
Después lea la configuración del cliente para esa llamada. El techo de la espera es una sola línea: su timeout. Un timeout de cliente fijado en minutos, donde la ruta del pago necesita segundos, significa que un comprador puede quedarse retenido en el botón de pago todo el tiempo que tarde el partner en responder, y el mal día del partner se convierte en el de la tienda.
“Un comprador que intenta pagar está esperando a una máquina que la tienda no opera, en una red que la tienda no opera, antes incluso de que el pedido se valide.”
Compruebe las consultas que hay debajo
El slow log de la base de datos suele señalar la misma integración: las consultas que la alimentan escanean en lugar de buscar, y están en la misma ruta. La llamada externa es lenta, las consultas que hay debajo son lentas, y las dos se interponen entre el comprador y el pedido. Arreglar la llamada sin las consultas deja el segundo cuello de botella en su sitio.
No reescribimos su checkout. Le entregamos la línea.
No reescribimos el checkout de un cliente: es su código, su lógica de negocio, su riesgo. Lo que entregamos es más útil y más difícil de conseguir: el archivo exacto, la línea exacta y la solución concreta. Tres movimientos, en orden.
Limite el timeout
: Recorte el timeout a unos pocos segundos con un fallback elegante, para que un partner lento degrade una cifra de stock en lugar de congelar todo el pago.
Sáquela de la ruta de la petición
: Mueva la llamada externa fuera de la petición en vivo, a un job en segundo plano. El pago de un comprador no debería esperar, en vivo, la respuesta de un tercero.
Arregle las consultas que hay debajo
: Indexe y reescriba las consultas que alimentan la integración, para que los datos que hay detrás dejen de ser un segundo cuello de botella.
- Una llamada en vivo a un sistema externo dentro de la validación del pedido
- Un timeout medido en minutos en el paso del pago
- El comprador esperando en el botón de pago
- Full-table scans ejecutándose en línea con el checkout
- La llamada externa movida a un job en segundo plano
- Un timeout de unos pocos segundos con un fallback elegante
- El botón de pago responde con el presupuesto de tiempo de la propia plataforma
- Las consultas indexadas y reescritas
La lección
Un servidor sano e inactivo casi nunca es donde vive la lentitud. Cuando la plataforma está tranquila y el comprador espera, la espera está en el nivel de la aplicación o en algo a lo que llama, y el método anterior encuentra qué línea.
Mantenga las llamadas síncronas a terceros fuera de la ruta de la petición. Dé a los sistemas externos un timeout corto y un fallback, y haga el trabajo real en un job en segundo plano. La ruta de la petición pertenece al comprador.
Respuestas directas
¿Por qué mi checkout es lento cuando el resto del sitio es rápido?+
Normalmente porque la parte rápida está cacheada y la lenta no. Una portada servida desde una CDN responde rápido y no le dice nada sobre el checkout, que ejecuta su código de aplicación en vivo en cada petición, incluida cualquier llamada a terceros que esté en la ruta del pago. Compruebe el carrito dinámico y el checkout, no la primera página.
¿Un checkout lento es un problema de hosting o de aplicación?+
Merece la pena demostrarlo, no suponerlo. Mida el nivel web y la base de datos bajo la misma carga en vivo: CPU, load, memoria, disco. Si nada está escaso de recursos, la espera está en la aplicación o en algo a lo que llama, y el siguiente paso es capturar las peticiones lentas y leer dónde se bloquean.
¿Qué es una llamada síncrona a un tercero en la ruta del checkout?+
Es cuando su checkout se bloquea y espera, en vivo, a un sistema externo antes de dejar que el pedido avance: un ERP, un servicio de stock, una puntuación de fraude, comprobados dentro de la validación del pedido. Si ese partner es lento, su comprador espera exactamente lo mismo que él, hasta el timeout configurado, y un timeout fijado en minutos es un techo medido en minutos.
¿Cómo encuentran qué línea hace lenta una página?+
Capturamos cada petición más lenta que un umbral en todos los nodos web, y después agrupamos los stack traces por la línea exacta en la que se bloquea cada petición, no por dónde empezó. El grupo más grande es su respuesta.
¿Me arreglarán el código?+
No reescribimos su checkout: es su lógica de negocio. Le entregamos el archivo exacto, la línea exacta y la solución concreta: acorte el timeout con un fallback, mueva la llamada al tercero a un job en segundo plano, y nosotros indexaremos y reescribiremos las consultas lentas que hay debajo. El diagnóstico, entregado con precisión, es el producto.
¿Debería un botón de pago llamar directamente a un ERP u otro tercero?+
Manténgalo fuera de la ruta de la petición. Un sistema en una infraestructura que usted no controla no debería interponerse entre el comprador y el pago. Dele un timeout corto y un fallback elegante para que pueda fallar sin tumbar el checkout, y mueva la llamada real a un job en segundo plano.
Algo en su checkout va lento. Encontraremos la línea.
Hable con un ingeniero que leerá su ruta lenta hasta el archivo y la línea, y lo dirá con claridad cuando la respuesta viva en su propio código.
Hable con un ingenieroLa disciplina aquí es la misma que hay detrás de otras dos lecturas: cómo dimensionar un servidor, donde la mayoría necesita menos de lo que cree, y por qué un servidor nuevo da peores benchmarks que el antiguo sin ser más lento.
Ha llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero