\u00bfPor qu\u00e9 la automatizaci\u00f3n masiva tumba un servidor com\u00fan?<\/h2>\n
El origen de casi todos los desastres es la latencia variable de las APIs de IA. Una llamada puede tardar dos segundos o dos minutos seg\u00fan la carga del proveedor, y esa impredecibilidad rompe el supuesto sobre el que funciona el Cron de Linux de toda la vida: que una tarea termina antes de que empiece la siguiente.<\/p>\n
El solapamiento y el efecto bola de nieve<\/h3>\n
Imagina un cronjob que se ejecuta cada 5 minutos. Un d\u00eda la API se satura y tarda 6 minutos en responder. Cuando el primer proceso a\u00fan no ha terminado, arranca el segundo. A los 10 minutos hay tres corriendo a la vez. Cada uno consume su RAM, su CPU y sus conexiones a la base de datos, y el crecimiento es exponencial: en poco rato el servidor se queda sin memoria y el sistema mata procesos (OOM) o se reinicia. Un fallo que empez\u00f3 siendo un retraso de un minuto acaba tirando la web entera.<\/p>\n
La soluci\u00f3n a nivel de sistema: flock<\/h3>\n
La forma limpia de resolverlo es la exclusi\u00f3n mutua: garantizar que nunca haya dos ejecuciones a la vez. En Linux la herramienta es Si el proceso anterior sigue vivo, el nuevo no arranca y punto. Sin bola de nieve.<\/p>\n \u00bfNo tienes acceso a consola? En hosting compartido puedes replicar la idea en la capa de aplicaci\u00f3n: una tabla de bloqueos con marcas de tiempo o PID. Guarda tambi\u00e9n el momento en que se tom\u00f3 el bloqueo, para poder liberar los “hu\u00e9rfanos” si un script muere por OOM y deja la cerradura echada.<\/p>\n<\/div>\n El segundo error cl\u00e1sico es usar MySQL como cola de tareas para miles de llamadas de IA. Funciona con cuatro tareas; con miles, se convierte en el cuello de botella de todo el sistema.<\/p>\n Para que varios workers no cojan la misma tarea, se suele recurrir a La diferencia de fondo es polling<\/strong> frente a push<\/strong>. En lugar de que el worker pregunte sin descanso (extracci\u00f3n activa), un br\u00f3ker as\u00edncrono como Redis o RabbitMQ le avisa solo cuando hay trabajo listo (notificaci\u00f3n reactiva). El worker duerme tranquilo hasta que le llega el aviso, y la base de datos relacional se queda para lo que sabe hacer bien: guardar datos, no gestionar colas.<\/p>\n Un paso m\u00e1s all\u00e1 est\u00e1 la ejecuci\u00f3n persistente (herramientas como Temporal, o encolado durable tipo BullMQ o Celery). La idea es no repetir pasos caros: si tu flujo genera el texto, luego crea una imagen y la sube a S3, y el worker muere justo al subir la imagen, quieres reanudar desde ah\u00ed, no volver a pagar la llamada de texto que ya funcion\u00f3.<\/p>\n Todo esto aterriza en el CMS m\u00e1s usado del mundo a trav\u00e9s de Action Scheduler<\/a>, la biblioteca de colas que usan WooCommerce y muchos plugins de edici\u00f3n y enlazado masivo. Viene con topes conservadores de f\u00e1brica para no reventar hostings malos, y ah\u00ed est\u00e1 el problema cuando t\u00fa s\u00ed tienes un buen servidor.<\/strong><\/em><\/p>\n Por defecto procesa en lotes de 25 acciones, con ejecuciones s\u00edncronas de 30 segundos y un solo hilo. Si tu hosting aguanta, puedes ampliarlo por c\u00f3digo:<\/p>\n Lotes de 100 y hasta 120 segundos de margen cambian por completo el rendimiento en un servidor preparado.<\/p>\n –> Ojo, subir esto en un hosting flojo es la receta perfecta para el colapso, as\u00ed que hazlo solo si tienes recursos que lo respalden.<\/strong><\/em><\/p>\n Las migraciones masivas llenan Haz una copia de seguridad antes de tocar nada y no truques la tabla de acciones sin extraer primero las pendientes, o perder\u00e1s trabajo en cola.<\/p>\n<\/div>\n Inserta el contenido de forma as\u00edncrona al guardar en el backend (en el gancho Y cuando manejes objetos pesados (taxonom\u00edas enormes, listas de usuarios), c\u00e1rgalos por fragmentos. El chunking<\/strong> (procesar en bloques de 100 a 500) evita desbordar la memoria RAM que PHP tiene asignada y te ahorra el cl\u00e1sico error de memoria agotada a mitad del proceso.<\/p>\n Los l\u00edmites de un proveedor como OpenAI no se miden solo en llamadas por minuto (RPM). Tambi\u00e9n cuentan los tokens por minuto (TPM) y las solicitudes diarias (RPD), y todo ello var\u00eda seg\u00fan tu historial de pagos: cuanto m\u00e1s llevas gastado, m\u00e1s alto es tu tier (del 1 al 5) y m\u00e1s margen tienes.<\/p>\n Cuando golpeas el l\u00edmite, la API responde con un error Si el art\u00edculo no tiene que publicarse al segundo, no llames a la API en tiempo real. Agrupa las peticiones en un archivo A esto puedes sumar el prompt caching<\/strong>: si repites siempre las mismas instrucciones al principio del prompt (contexto, formato, tono), col\u00f3calas primero para que el proveedor las reutilice. El ahorro en tokens de entrada repetidos puede llegar a ser enorme, y de paso baja la latencia.<\/p>\nflock<\/code>, que viene en el paquete est\u00e1ndar util-linux<\/code>. Envuelves tu script con un archivo de bloqueo f\u00edsico y el par\u00e1metro -n<\/code> (no bloqueante), que aborta en silencio cualquier ejecuci\u00f3n que intente solaparse:<\/p>\n*\/5 * * * * \/usr\/bin\/flock -n \/tmp\/generacion_contenido.lock \\\r\n \/usr\/bin\/php \/ruta\/al\/script_generacion.php<\/code><\/pre>\nTu base de datos no es una cola de mensajer\u00eda<\/h2>\n
Bloqueos de fila y sondeo constante<\/h3>\n
SELECT ... FOR UPDATE<\/code>. Ese bloqueo de fila congela \u00edndices que el resto de la web necesita, as\u00ed que el TTFB del frontend se dispara y los usuarios reales empiezan a ver timeouts. A eso se suma el desgaste por sondeo: workers preguntando a la base de datos cada pocos milisegundos “\u00bfhay algo para m\u00ed?”, reconstruyendo planes de consulta una y otra vez sobre tablas casi vac\u00edas y quemando CPU para nada.<\/p>\nLa alternativa: colas en memoria y eventos<\/h3>\n
![\"Hosting](\"https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2026\/08\/hosting-generacion-contenido-01.jpg\" "\\"\\"")
<\/a><\/h2>\nWordPress y Action Scheduler: publicar miles de art\u00edculos al d\u00eda<\/h2>\n
Sube los l\u00edmites de f\u00e1brica (con cabeza)<\/h3>\n
add_filter( 'action_scheduler_queue_runner_batch_size', fn() => 100 );\r\nadd_filter( 'action_scheduler_queue_runner_time_limit', fn() => 120 );<\/code><\/pre>\nCuando la tabla de logs explota<\/h3>\n
wp_actionscheduler_actions<\/code> con millones de registros, y llega un momento en que la propia tabla de tareas ralentiza MySQL. Cuando esto pasa (a veces con el temido MySQL server has gone away<\/code>), un DELETE<\/code> normal empeora las cosas: bloquea la tabla durante horas. El atajo de emergencia es guardar aparte lo que est\u00e9 en estado pendiente y hacer un TRUNCATE<\/code>, que vac\u00eda la tabla al instante:<\/p>\nTRUNCATE TABLE wp_actionscheduler_logs;<\/code><\/pre>\nLa regla de oro del SEO t\u00e9cnico<\/h3>\n
save_post<\/code>), nunca lo generes din\u00e1micamente en tiempo de carga con hooks en caliente como the_content<\/code>. Almacena el HTML ya calculado en la base de datos para servirlo en milisegundos. La diferencia para Google (y para el usuario) es abismal: una p\u00e1gina que se pinta al instante frente a una que llama a una IA cada vez que alguien la abre.<\/p>\nOptimizaci\u00f3n matem\u00e1tica de las APIs: l\u00edmites, jitter y batching<\/h2>\n
Anatom\u00eda de un rate limit<\/h3>\n
Retroceso exponencial con jitter<\/h3>\n
HTTP 429<\/code>. Si todos tus procesos reintentan exactamente al mismo tiempo, vuelves a chocar en el mismo milisegundo: es el efecto “estampida” (thundering herd). La soluci\u00f3n es el retroceso exponencial con jitter<\/strong>: esperar cada vez un poco m\u00e1s y a\u00f1adir una variaci\u00f3n aleatoria para desincronizar los reintentos. Librer\u00edas como Tenacity lo hacen por ti y, de paso, evitan que el proveedor interprete tu r\u00e1faga como un abuso.<\/p>\nBatch API: el gran ahorro de costes<\/h3>\n
.jsonl<\/code> y m\u00e1ndalas a la Batch API de OpenAI<\/a>. Las ventajas son claras:<\/p>\n\n