Módulo 6: Scaling And Performance Queue Mode

2. Dónde se va el tiempo de verdad

Siguiente →

Descripción

Al terminar esta lección vas a poder abrir una ejecución en n8n y leer, nodo por nodo, cuánto tardó cada uno, para saber con evidencia dónde se va el tiempo de un workflow antes de tocar una sola casilla. Vas a poder distinguir las tres clases de tiempo —cómputo, espera de red y cola— porque cada una se arregla de una forma distinta, y —lo más importante— vas a aprender a no caer en la trampa que engaña a casi todo el mundo: el nodo que aparece como el más lento muchas veces no es el culpable, es solo el que está esperando al culpable.

Esto importa porque es la base de todo el módulo, y sin ella lo demás es un juego de azar. Optimizar sin medir es adivinar, y adivinar en rendimiento sale caro dos veces: cuesta las horas que inviertes puliendo el nodo equivocado, y cuesta el problema real que sigue ahí porque nunca lo miraste. Medir primero no es la parte aburrida previa al trabajo interesante. Medir es el trabajo interesante: es lo que convierte "el workflow va lento" —una queja— en "el nodo que llama al erp se lleva el 95% del tiempo" —un plan—.

Conexión con el módulo: la lección 1 te dio la tesis (arregla el workflow antes de comprar máquina) y las tres cubetas donde se reparte el tiempo. Esta lección te da el instrumento para ver esas cubetas: cómo se lee una ejecución medida. Es la lección que habilita todas las demás —la 3, la 4, la 5 y la 6 son técnicas de optimización, y cuál de ellas aplicas depende por completo de lo que esta medición te diga—. Una frontera clara: el Módulo 4 de esta guía, el de observabilidad, mide cosas parecidas —duración, percentiles, métricas en el tiempo— pero desde el ángulo de qué se vigila en general para operar. Aquí medimos con un solo fin, mucho más acotado: encontrar el cuello de botella de un workflow concreto para optimizarlo. No vamos a montar dashboards; vamos a leer una ejecución.

Un recibo detallado, no el total de la cuenta

Piensa en la diferencia entre dos formas de recibir la cuenta en un restaurante.

La primera es un ticket que dice, y nada más: "Total: 1.180 pesos." Con eso sabes que gastaste mucho, pero no sabes en qué. ¿Fue el vino? ¿Fueron los postres? ¿Alguien pidió un plato carísimo que no notaste? No puedes hacer nada útil con ese número, salvo quejarte de que la cuenta salió cara.

La segunda es un recibo desglosado, línea por línea: la entrada 90, los tres platos fuertes 640, el vino 320, los postres 130. Con ese recibo, en cinco segundos ves que el vino y los platos fuertes se llevaron casi todo, y si quisieras gastar menos la próxima vez, sabes exactamente dónde recortar. El total es idéntico en los dos recibos; lo que cambia es que uno te deja actuar y el otro solo te deja sentir.

Cuando alguien dice "mi workflow tarda 11 minutos", está leyendo el primer ticket: el total. La lentitud es un sentimiento, no un plan. Lo que necesitas es el segundo recibo —cuánto tardó cada nodo— porque la lentitud casi nunca está repartida de forma pareja. Está concentrada, como el vino en la cuenta, en una o dos líneas que se llevan casi todo. Y una vez que ves cuáles son esas líneas, la optimización deja de ser un misterio y pasa a ser una decisión.

n8n te da ese recibo desglosado en cada ejecución, sin que tengas que configurar nada. Solo hay que aprender a leerlo.

Dónde vive el recibo: la ejecución y su desglose por nodo

Cada vez que un workflow corre, n8n guarda un registro de esa ejecución: qué nodos corrieron, en qué orden, qué datos pasaron por cada uno, y —lo que nos importa hoy— cuánto tardó cada nodo. Ese registro es tu recibo detallado.

Para llegar a él, en la barra lateral izquierda de n8n abres Executions (Ejecuciones). Ahí ves la lista de las últimas corridas de tus workflows, con su estado —verde si terminó bien, rojo si falló—, su modo, la hora y el tiempo total que tardó. Ese tiempo total es el "Total: 1.180 pesos": te dice que la corrida fue lenta, pero todavía no en qué. Para el desglose, abres una ejecución concreta.

Dentro de una ejecución abierta, n8n te muestra el lienzo con los nodos, y el desglose de tiempos vive en dos lugares que conviene conocer:

El panel de registros (Logs view), abajo del lienzo. En las versiones recientes de n8n hay una barra de Logs en la parte de abajo del lienzo. Al abrirla, ves la lista de los nodos en el orden en que se ejecutaron, y para cada uno cuánto tardó, además del tiempo total de la ejecución. Es la vista más cómoda para encontrar el cuello de botella, porque te pone todos los tiempos uno debajo del otro y el culpable salta a la vista: es la línea con el número grande.

El detalle de un nodo. Si haces clic en un nodo para ver su salida, junto al título de la salida (Output) hay un ícono de información que te da datos de esa corrida del nodo: cuándo empezó (Start Time) y cuánto tardó en devolver resultados (Execution Time). Es la lupa para un nodo específico, una vez que ya sabes cuál mirar.

Verifica en tu panel. Las etiquetas exactas y la ubicación del panel de registros cambian entre versiones de n8n, y la interfaz sigue evolucionando. Lo que no cambia es el concepto: cada ejecución registra el tiempo por nodo, y en algún lugar de la ejecución abierta puedes verlo. Si en tu versión no encuentras la barra de Logs, busca el tiempo en el detalle de cada nodo. El método de esta lección funciona igual sin importar dónde exactamente muestre tu versión el número.

Una nota práctica antes de seguir, porque afecta lo que mides: evita medir con ejecuciones manuales cuando el volumen es grande. Cuando disparas un workflow a mano desde el editor, n8n hace una copia extra de los datos para poder mostrártelos en pantalla, y eso agrega tiempo y memoria que la ejecución automática real no paga. Para medir de verdad, mira una ejecución automática —una que disparó el schedule o el webhook en producción— desde la lista de Executions. La ejecución manual sirve para depurar la lógica; la automática sirve para medir el rendimiento.

Ejemplo trabajado: leyendo la ejecución de inventory-update

Vamos a hacer justo lo que haría la persona de operaciones de Terra Market frente a los once minutos.

Abre Executions, filtra por inventory-update, y abre una corrida reciente —una automática, de las que dispara el schedule cada 15 minutos—. El tiempo total dice 11 min 4 s. Ese es el ticket sin desglosar. Ahora abre el panel de registros para ver el recibo detallado:

Ejecución de inventory-update — 14:30:00 — total 11 min 4 s

  Nodo                          Tiempo
  ─────────────────────────────────────
  Schedule Trigger              0.0 s
  ERP: get sku list             1.5 s
  Loop Over Items               ⟳
    └ HTTP: GET stock (×300)    630   s   ◄──────
  Code: transform stock         3.0 s
  Loop Over Items (2)           ⟳
    └ HTTP: POST storefront     25    s
  Postgres: log run             0.5 s

Léelo como leerías la cuenta del restaurante. De los 664 segundos totales, 630 se van en un solo lugar: el nodo HTTP: GET stock que corre dentro del bucle, una vez por cada sku. Todo lo demás junto —leer la lista de sku, transformar, empujar a storefront, registrar— suma unos 30 segundos. El vino de esta cuenta es clarísimo.

Con este recibo enfrente, la conversación cambia por completo. Ya nadie dice "n8n se quedó chico". Ahora se dice "el 95% del tiempo se va en llamar al erp trescientas veces". Y esa frase ya contiene su propia solución: si el problema es trescientas llamadas, la solución es hacer menos llamadas. Eso es la lección 5.

Qué esperar. Cuando midas un workflow tuyo por primera vez, espera encontrarte con lo mismo que Terra Market: el tiempo no está repartido parejo. Casi siempre uno o dos nodos se llevan la enorme mayoría, y el resto es ruido. Esto es una buena noticia disfrazada de problema: significa que no tienes que optimizar todo el workflow, solo esa una o dos líneas. La regla práctica que vas a comprobar una y otra vez: el 80% de la lentitud vive en el 20% de los nodos, y a menudo en uno solo. Tu trabajo al medir es encontrar ese uno.

La trampa: el nodo lento casi siempre está esperando, no trabajando

Aquí está la parte que separa a quien sabe leer un recibo de quien solo ve números grandes. Cuando encuentres el nodo que se lleva el tiempo, hay una pregunta que tienes que hacerte antes de intentar "optimizarlo", porque la respuesta cambia por completo qué haces:

Ese nodo, ¿está trabajando o está esperando?

Son dos cosas totalmente distintas que el recibo muestra con el mismo número, y confundirlas es la trampa número uno del rendimiento.

Un nodo que trabaja está usando el procesador de n8n: recorre una lista larga, transforma textos, calcula, ordena, deduplica. El tiempo que ves es tiempo de cómputo. Los nodos que trabajan son, sobre todo, los nodos Code con lógica pesada sobre muchos items, y algunas operaciones de nodos que procesan datos en memoria. Para un nodo que trabaja, "optimizarlo" sí significa hacerlo más eficiente: mejor algoritmo, menos vueltas, menos datos que recorrer.

Un nodo que espera mandó una petición a otro sistema y está parado hasta que le respondan. El tiempo que ves es tiempo de espera de red, y durante todo ese tiempo el procesador de n8n está de brazos cruzados. Los nodos que esperan son casi todos los que hablan con el mundo exterior: HTTP Request, los nodos de bases de datos como Postgres, los nodos de servicios (Slack, correo, el carrier), los nodos de modelos de IA. Para un nodo que espera, "optimizarlo" haciéndolo más eficiente no sirve de nada, porque el tiempo no está en n8n, está en el otro lado de la línea. La única palanca es hacerlo esperar menos veces o esperar algo más rápido.

Vuelve al recibo de inventory-update. El nodo que se lleva los 630 segundos es un HTTP: GET stock. ¿Trabaja o espera? Espera. Está mandando trescientas peticiones al erp, una tras otra, y cada una lo deja parado dos segundos aguardando respuesta. Si alguien intentara "optimizar" ese nodo revisando su configuración, cambiándole opciones o simplificando su expresión, no ganaría ni un segundo, porque los dos segundos por llamada los pone el erp, no n8n. La única forma de bajar los 630 segundos es llamar menos veces.

Ahora viene la segunda cara de la trampa, y es más sutil: el nodo que aparece lento a veces solo está esperando a otro que sí es el culpable. Esto pasa de dos formas típicas:

El nodo que acumula un bucle. Un Loop Over Items que aparece con un tiempo enorme no es "un nodo lento": es un nodo que da vueltas, y el tiempo que ves es la suma de todas sus iteraciones. El culpable no es el bucle en sí, es lo que hay dentro de cada vuelta —en nuestro caso, la llamada al erp—. Si te quedas mirando el Loop Over Items intentando acelerarlo, estás mirando el envase; el contenido —la llamada repetida— es el problema.

El nodo que junta ramas. Un nodo que espera a que terminen varias ramas —un Merge, o cualquier nodo que va después de un camino largo— puede reportar que la ejecución llegó a él tarde, sin que él haya tardado nada. Su "tiempo" en el reloj de pared es el de la rama lenta que lo precede, no el suyo. Antes de acusar a un nodo, mira si el tiempo es suyo —lo que él tardó en correr— o heredado —lo que tardó en llegarle el turno—.

La regla, para que no la olvides:

Encontrar el nodo con el número grande es solo la mitad del trabajo. La otra mitad es preguntar si ese nodo trabaja o espera, y si el tiempo es suyo o de quien lo antecede. Optimizar sin responder eso es como cambiarle el motor al carro para saltarte una fila que no se mueve.

Las tres cubetas, ahora que sabes leerlas

En la lección 1 nombramos las tres clases de tiempo. Ahora que sabes abrir el recibo, puedes reconocer cada una en el panel, que es lo que de verdad importa.

Tiempo de cómputo — n8n está trabajando. Cómo se ve: un nodo Code (u otro que procesa datos en memoria) con un tiempo notable, sin llamadas a sistemas externos dentro. Cómo confirmarlo: el nodo no habla con nadie afuera; solo transforma lo que ya tiene. Con qué se arregla: mejor lógica, menos datos que recorrer, o —si de verdad es mucho cómputo— mover el trabajo pesado a donde pertenece (una base de datos que ordena y filtra mucho mejor que un bucle en Code). Es la única cubeta donde un procesador más rápido ayuda algo, y casi siempre es la más pequeña.

Tiempo de espera de red — n8n está esperando a otro. Cómo se ve: un nodo HTTP Request, de base de datos o de servicio con un tiempo grande, sobre todo si está dentro de un bucle y se repite muchas veces. Cómo confirmarlo: el tiempo del nodo es proporcional a cuántas veces llama, no a cuántos datos procesa n8n. Con qué se arregla: menos llamadas (lección 5), lotes (lección 3), o encontrar el ritmo que la otra API tolera (lección 6). Un servidor más grande no toca esta cubeta, y es —en workflows de integración como los de Terra Market— la cubeta más grande con diferencia.

Tiempo de cola — la ejecución ni siquiera empezó. Cómo se ve: no lo ves dentro de la ejecución, porque no es tiempo de ningún nodo. Se ve en la diferencia entre la hora en que el evento debió disparar el workflow y la hora en que la ejecución de verdad arrancó. Si order-sync debía dispararse a las 21:00:03 y su ejecución empezó a las 21:01:10, ese minuto y pico es cola: estuvo formada esperando turno. Cómo confirmarlo: pasa cuando hay muchas ejecuciones simultáneas compitiendo por la instancia. Con qué se arregla: esta es la única de las tres que no se arregla en el workflow. Es infraestructura, y es la señal de la lección 7 —la frontera hacia la guía de self-hosting—.

La utilidad de las tres cubetas es que cada una manda tu esfuerzo a un lugar distinto, y el panel te dice en cuál estás. Si el tiempo se va en espera de red, ni sueñes con comprar máquina: baja las llamadas. Si se va en cola, entonces sí puede tocar escalar —pero primero confirma que cada ejecución ya está optimizada, o vas a escalar para correr más rápido un desperdicio—.

El total y la suma no siempre coinciden

Hay un detalle de lectura que vale la pena aprender temprano, porque cuando aparece confunde. A veces sumas los tiempos de todos los nodos y te da menos que el tiempo total de la ejecución. ¿A dónde se fue la diferencia?

Piénsalo con la cuenta del restaurante otra vez: el total de tu recibo puede incluir una propina o un cubierto que no está en ninguna de las líneas de comida. En una ejecución, la diferencia entre el total y la suma de los nodos es el tiempo que no le pertenece a ningún nodo en particular: sobre todo el rato que la ejecución pasó esperando turno antes de empezar (cola), más algo de trabajo interno del propio motor. Un nodo no puede tardar tiempo mientras no está corriendo, así que ese hueco no aparece en ninguna línea.

Por eso, cuando el total es bastante más grande que la suma de los nodos, es una pista fuerte de que estás en la cubeta de cola: la ejecución tardó no porque sus nodos fueran lentos, sino porque tardó en arrancar. Y esa es, de nuevo, la señal que apunta a la infraestructura, no al workflow. En inventory-update no pasa esto —su total (664 s) y su suma (660 s) casi coinciden, señal de que el problema es de verdad lo que hacen los nodos, no la cola—. Pero en un order-sync de las 21:00 sí podrías ver un total muy por encima de la suma, y ahí la conversación es otra: la de la lección 7.

Quédate con la lectura: suma ≈ total significa "el tiempo está en los nodos, arréglalo aquí"; total ≫ suma significa "el tiempo está en esperar turno, esto huele a infraestructura".

Cómo hacer una medición honesta, paso a paso

Reunamos todo en un procedimiento que puedas repetir con cualquier workflow lento tuyo. La palabra clave es honesta: una medición que no puedas confiar es peor que ninguna, porque te da falsa seguridad.

Paso 1 — Mide una ejecución automática, no una manual. Ve a Executions y abre una corrida real de producción, no una que dispares tú desde el editor. Recuerda: la manual paga una copia extra de datos que la real no paga, y te va a mostrar tiempos y memoria inflados. Qué esperar: si comparas una manual y una automática del mismo workflow con los mismos datos, la manual suele salir peor. Usa la automática.

Paso 2 — Lee el recibo completo antes de reaccionar. Abre el panel de registros y mira todos los tiempos, no solo el primero que te llame la atención. El objetivo es ver cómo se reparte el total. Casi siempre vas a encontrar uno o dos nodos que se llevan casi todo; anótalos.

Paso 3 — Para el nodo culpable, pregunta si trabaja o espera. Es la pregunta de la trampa. ¿Es un nodo que procesa datos en memoria (trabaja) o uno que llama afuera (espera)? ¿Está dentro de un bucle que lo repite? ¿El tiempo es suyo o heredado de una rama lenta?

Paso 4 — Mide más de una vez. Una sola ejecución puede engañarte: el erp pudo estar teniendo un mal momento justo entonces. Mira dos o tres corridas de horas distintas. Si el nodo culpable es el mismo en todas, tienes un cuello estable. Si cambia de una a otra, tu problema puede ser de variabilidad del sistema externo, que es otra conversación.

Paso 5 — Escribe el número antes de tocar nada. Antes de optimizar, deja por escrito "hoy tarda X, el nodo Y se lleva Z". Ese número es tu línea base, y es lo que te va a permitir demostrar, después, que tu cambio sirvió. Optimizar sin línea base es como ponerte a dieta sin haberte pesado nunca: no vas a poder decir si funcionó. El proyecto de la lección 8 se construye entero sobre esta línea base.

Ese es el método completo, y es deliberadamente aburrido. El glamour de la optimización está en el arreglo ingenioso de la lección 5; pero el arreglo ingenioso solo funciona porque estos cinco pasos aburridos te apuntaron al lugar correcto.

Errores comunes

Optimizar por intuición sin abrir una ejecución (conceptual). Qué pasa: alguien "sabe" cuál es el nodo lento —el que a él le parece complicado, o el último que tocó— y se pone a optimizarlo sin medir. A veces acierta por suerte; casi siempre gasta horas en un nodo que aportaba el 2% del tiempo mientras el verdadero culpable sigue intacto. Por qué pasa: medir se siente como perder tiempo antes del trabajo "real", y la intuición sobre rendimiento es notoriamente mala —hasta los ingenieros con experiencia se equivocan seguido al adivinar dónde está el cuello—. Cómo detectarlo: si no puedes decir "el nodo X se lleva el Y% del tiempo" con un número que leíste, estás optimizando a ciegas. Cómo corregirlo: abre una ejecución antes de cambiar nada. Son dos minutos, y te ahorran una tarde en el nodo equivocado. Es literalmente la regla del módulo: optimizar sin medir es adivinar.

Confundir el tiempo de espera con tiempo de cómputo y "optimizar" un nodo que solo espera (práctico). Qué pasa: se ve un HTTP Request con diez minutos y se intenta acelerarlo revisando su configuración, cambiándole opciones, simplificando la expresión que arma la URL. No mejora nada. Por qué pasa: el número grande hace pensar que el nodo "hace mucho", cuando lo que hace es esperar mucho a un sistema externo. Los diez minutos los pone el erp, no n8n. Cómo detectarlo: pregunta si el nodo habla con el mundo exterior. Si sí, su tiempo es espera, y ninguna optimización de su configuración lo baja. Cómo corregirlo: la palanca de un nodo que espera es cuántas veces espera —reducir llamadas (lección 5) o agruparlas en lotes (lección 3)—, nunca "afinarlo".

Culpar al bucle en vez de a lo que hay dentro (práctico). Qué pasa: se ve un Loop Over Items con un tiempo enorme y se concluye "el bucle es lento, hay que quitarlo o cambiarlo". Pero el bucle no tarda; tarda lo que se hace dentro de cada vuelta. Por qué pasa: el tiempo aparece asociado al nodo del bucle porque es la suma de sus iteraciones, y es fácil leer eso como "el bucle es el problema". Cómo detectarlo: mira qué corre dentro del bucle. Si es una llamada externa que se repite N veces, el problema son las N llamadas, no el mecanismo del bucle. Cómo corregirlo: no elimines el bucle; reduce lo que hace cada vuelta o —mejor— reemplaza N llamadas de a una por pocas llamadas de a lote (lecciones 3 y 5).

Medir con una ejecución manual y sacar conclusiones de rendimiento (práctico). Qué pasa: se dispara el workflow a mano desde el editor para "ver cuánto tarda", sale un número, y se toman decisiones con él. El número está inflado, porque la ejecución manual paga una copia extra de datos para la pantalla. Por qué pasa: es lo más cómodo —le das a "ejecutar" y ves el tiempo— y no todo el mundo sabe que la manual y la automática no cuestan lo mismo. Cómo detectarlo: si tu medición viene de darle "ejecutar" en el editor, sospéchala, sobre todo si hay muchos datos. Cómo corregirlo: mide sobre una ejecución automática desde la lista de Executions. Guarda la manual para depurar la lógica, no para medir la velocidad.

Medir una sola vez y tomarlo como verdad eterna (conceptual). Qué pasa: se abre una ejecución, se ve que tardó mucho, y se asume que ese es "el tiempo del workflow". Pero esa corrida pudo caer justo cuando el erp estaba en su peor momento del día. Por qué pasa: una sola medición se siente como un hecho, y es apenas una muestra. Cómo detectarlo: ¿miraste una corrida o varias de horas distintas? Con una sola no sabes si es el cuello estable o un mal día del sistema externo. Cómo corregirlo: mira dos o tres ejecuciones de momentos distintos. Si el culpable es siempre el mismo nodo, es estructural y vale la pena arreglarlo; si varía mucho, tu problema puede ser la inestabilidad del otro sistema, y eso se trata distinto.

Ejercicios

Ejercicio 1 — Lee el recibo. Te dan el desglose de una ejecución de un workflow de Terra Market que arma un reporte diario. Di dónde está el cuello de botella, si ese nodo trabaja o espera, y qué NO harías.

Total: 4 min 12 s
  Schedule Trigger .............. 0.0 s
  Postgres: read yesterday ....... 2.1 s
  Code: build report rows ........ 6.0 s
  Loop Over Items ⟳
    └ HTTP: enrich each row (×140) 235 s
  Code: format ................... 1.5 s
  Email: send report ............. 3.0 s
Ver solución

El cuello está clarísimo: el HTTP: enrich each row, dentro del bucle, se lleva 235 de los 252 segundos de la ejecución (más del 93%). Todo lo demás es ruido.

Ese nodo espera: es un HTTP Request que llama a un servicio externo una vez por fila, 140 veces. Su tiempo es espera de red multiplicada por 140 llamadas.

Lo que NO haría: perder un solo minuto en el Code: build report rows, aunque tenga 6 segundos y sea el segundo número más grande. Seis segundos no son el problema cuando el vecino tiene 235. Tampoco intentaría "afinar" el HTTP Request en sí, porque su tiempo no está en su configuración, está en las 140 llamadas. La dirección correcta es reducir esas 140 llamadas a unas pocas de a lote —si el servicio ofrece enriquecer varias filas de una— o, si no la ofrece, ver si algo de ese enriquecimiento se puede resolver sin llamar (lección 5).

Por qué funciona: el recibo hace obvio lo que sin él sería una discusión. Nadie propondría comprar servidor viendo esto: se ve que n8n pasó cuatro minutos esperando a un tercero 140 veces.

Ejercicio 2 — Trabaja o espera. Para cada nodo, di si su tiempo es cómputo (trabaja) o espera de red (espera), y por lo tanto si "hacerlo más eficiente" tiene sentido o no.

(a) Un nodo Code en modo All Items que recorre 80.000 registros para agruparlos por store_id, y tarda 9 segundos. (b) Un nodo Postgres que hace un INSERT por cada uno de 500 items, dentro de un bucle, y tarda 40 segundos. (c) Un nodo HTTP Request que llama al carrier una sola vez y tarda 6 segundos porque el carrier está lento hoy. (d) Un nodo Code en modo Each Item que le da formato a una fecha, corre 500 veces, y suma 0,3 segundos.

Ver solución

(a) Cómputo. n8n está de verdad trabajando: ochenta mil registros recorridos en memoria. Aquí "hacerlo más eficiente" sí tiene sentido —mejor lógica, o mover el agrupamiento a la base de datos, que agrupa muchísimo mejor que un bucle—. Es cómputo real, aunque 9 segundos rara vez sea el mayor problema de un workflow.

(b) Espera. Son 500 idas y vueltas a la base de datos, una por item. El tiempo no está en n8n, está en las 500 conexiones. "Afinar" el nodo no ayuda; lo que ayuda es hacer un INSERT con los 500 valores de una vez (muchas bases lo permiten), que es exactamente reducir llamadas.

(c) Espera. Los 6 segundos los pone el carrier, no n8n. Y ojo: es una llamada, así que no hay "reducir llamadas" que hacer. Si el carrier está lento hoy, no hay optimización de workflow que lo arregle; es variabilidad del sistema externo. Lo único a tu alcance sería un timeout razonable para que no te cuelgue si un día tarda demasiado.

(d) Cómputo, pero irrelevante. Trabaja, sí, pero 0,3 segundos entre 500 corridas es nada. La lección del inciso: no todo lo que "trabaja" vale la pena optimizar. El tamaño manda. Un nodo que trabaja mucho y tarda poco no es un cuello.

Por qué funciona: la pregunta "trabaja o espera" te dice qué tipo de palanca aplicar, y el tamaño del número te dice si vale la pena aplicarla. Necesitas las dos: dirección y magnitud.

Ejercicio 3 — La trampa del tiempo heredado. Un compañero abre una ejecución y te dice: "el nodo Merge es el más lento, tarda 3 minutos, hay que optimizar el Merge". Miras el workflow: el Merge junta dos ramas; una rama es un Set instantáneo y la otra es un HTTP Request al erp que tarda 3 minutos. ¿Tiene razón tu compañero? ¿Qué le explicarías y qué mirarías?

Ver solución

Tu compañero está leyendo mal el recibo. El Merge no tarda 3 minutos trabajando: tarda 3 minutos porque no puede juntar las dos ramas hasta que la rama lenta —el HTTP Request al erp— termine. Ese tiempo es heredado, no propio. El Merge está esperando a que le llegue el turno, igual que tú "tardas" media hora en un restaurante aunque tu plato se cocine en diez minutos, porque estuviste esperando a que llegara.

Lo que le explicaría: un nodo que junta ramas hereda el tiempo de la rama más lenta que lo alimenta. Optimizar el Merge es imposible porque el Merge no hace nada lento; el trabajo lento está aguas arriba, en el HTTP Request.

Lo que miraría: el nodo real de los 3 minutos es el HTTP Request al erp. Ahí aplico las preguntas de siempre: ¿es una llamada o muchas? Si es una, ¿el erp está lento (variabilidad, poco a mi alcance) o estoy pidiendo demasiados datos de una vez? Si son muchas, reducir llamadas.

Por qué funciona: distinguir el tiempo propio del heredado te evita el error clásico de "optimizar el último nodo antes del resultado", que suele ser inocente y solo estaba esperando. El culpable casi nunca está al final; está aguas arriba, en quien de verdad se tomó el tiempo.

Resumen y siguiente paso

En esta lección aprendiste a leer el recibo detallado de un workflow en vez de mirar solo el total. Viste dónde vive: en la lista de Executions, abriendo una ejecución y mirando el panel de registros o el detalle de cada nodo, donde n8n te dice cuánto tardó cada uno. Aplicaste la lectura al caso de Terra Market y encontraste que de los once minutos de inventory-update, 630 segundos se van en un solo nodo: la llamada al erp repetida trescientas veces. Y aprendiste la trampa que engaña a casi todo el mundo: el número grande no basta, hay que preguntar si ese nodo trabaja o espera —porque a un nodo que espera no lo aceleras afinándolo, solo haciéndolo esperar menos veces— y si su tiempo es suyo o heredado de una rama lenta que lo antecede. Reconociste las tres cubetas en el panel —cómputo, espera de red, cola— y con qué se arregla cada una. Y te quedaste con el método honesto de cinco pasos: mide una ejecución automática, lee el recibo completo, pregunta trabaja-o-espera, mide varias veces, y escribe la línea base antes de tocar nada.

Antes de avanzar deberías poder: abrir una ejecución y decir qué nodo se lleva el tiempo con un número; explicar por qué un HTTP Request lento no se arregla afinándolo; y nombrar las tres cubetas y cuál de ellas no se arregla en el workflow.

Ahora que sabes dónde se va el tiempo, empieza la parte de arreglarlo, y la primera técnica ataca uno de los problemas que la medición saca a la luz con más frecuencia: qué haces cuando por un nodo entran, no trescientos, sino diez mil items de golpe. La lección 3 es sobre procesar por lotes: dividir un volumen grande en partes manejables con Loop Over Items, y —lo más interesante— por qué elegir el tamaño de esas partes es una decisión con dos costos que tiran en direcciones opuestas.

Recursos

← Anterior1. Presentación del módulo: cuando el workflow es el cuello de botellaSiguiente →3. Procesar por lotes sin morir en el intento