Ajustando errores 429 de sitio de alto volumen en message bus--¿debería preocuparme?

Estoy trabajando en un sitio de volumen bastante alto (>150K visualizaciones de página/día). Estoy recibiendo algunos errores 429, al menos principalmente en el bus de mensajes. Antes tuve algunos problemas debido a una mala configuración de set_real_ip_from, pero eso ya está resuelto. También eliminé (¿quizás temporalmente?) la plantilla de limitación de velocidad.

Sigo viendo alrededor de 0,5 errores 429 por segundo.

Tengo 5 workers de unicornio con una CPU de 2 núcleos/4 hilos. 16 GB de RAM. Postgres está en un host separado. Las CPUs permanecen con >50% de inactividad.

Eliminé la plantilla de limitación de velocidad y aumenté los workers de unicornio a 5 alrededor de las 8:20.

Eso es completamente normal: el bus de mensajes esperará con código 429 ya que tus unicornios están bajo una carga pesada y hay una pequeña cola.

4 núcleos con 16 GB de RAM es una proporción bastante extraña si el nodo no está ejecutando la base de datos. Por ejemplo, 8/8 sería mejor.

¡Genial! Gracias. La CPU sigue siendo muy exigida con el procesamiento de imágenes, lo cual debería resolverse en un día o dos, espero.

Es cierto. Pero el hardware físico tiene 2 núcleos/4 hilos. Es fácil añadir RAM, no núcleos (¡tengo otro en casa con 32 GB!). Separé la base de datos y la web en dos máquinas para obtener más CPU. Tengo media docena de otras bases de datos de sitios con poco tráfico en el mismo servidor de base de datos (la web en un host diferente). ¿Crees que sería mejor ejecutar la BD y la web en la misma máquina? Perdería algo de CPU pero mejoraría la latencia, supongo.

Si tienes capacidad de equilibrado de carga, entonces podrías intentar poner trabajadores web en ambas máquinas para tu sitio de alta carga, con menos en la que tiene la base de datos, tal vez 5+2.

Si resolver el problema con dinero es una opción, simplemente consigue otro host con una mejor relación CPU:RAM.

Bueno, estas máquinas, que obtuve gratis, ya están empezando a mostrar su edad, así que estoy empezando a aceptarlo: el rendimiento de un solo CPU sigue pareciendo mejor que el de un droplet de DO. Si resolver el problema con dinero a corto plazo fuera una opción, probablemente no tendría este cliente en particular que quiere rendimiento empresarial a precios de negocio. :wink:

Pero también veo que tenía el número de unicornios codificado en otro lugar de la cadena, así que todavía solo tengo 3 en ejecución.

Lamentablemente, mi configuración actual solo se comunica con Docker en un solo host. Debería dedicar un poco más de tiempo a ver si puedo añadir un par de unicornios en la otra máquina también. Probablemente sea hora de volver a mirar HAProxy, pero tengo otro proyecto que realmente quiero lanzar primero.

Muchas gracias por tus comentarios.

EDIT: Y cuando finalmente pasé de 3 a 5 unicornios, los gráficos de rendimiento se ven casi iguales (pero quizás un poco más lentos), aunque los errores 429 disminuyeron significativamente. Parece que una vez que se complete el procesamiento de imágenes, esto funcionará perfectamente. :relieved:

Y, apenas un día después, los errores 429 han bajado a casi cero, ¡así que el consejo de Rafael de «simplemente no te preocupes» fue brillante! Gracias de nuevo, Kane y Rafael. No puedo exagerar lo mucho que aprecio su ayuda.