Probamos Chatwoot en Hetzner y Netcup: CPU, RAM y respuesta con 60 agentes simulados

Volver al Laboratorio · Laboratorio SuperPyme / Aplicaciones / Chatwoot

En las dos instancias ARM64 probadas, Hetzner respondió más rápido y empleó menos CPU en el control adicional. La RAM máxima muestreada fue muy parecida. Aumentar los trabajadores ayudó a las colas de Netcup, pero no mejoró todas las operaciones por igual.

Ensayo: 21 de octubre de 2026 · Chatwoot Community 4.18.0 · Datos sintéticos

¿Basta mirar cuántas vCPU y cuánta memoria anuncia un servidor para elegir dónde alojar Chatwoot? La pregunta tiene una consecuencia concreta: una instalación compartida combina procesos web, trabajos de fondo, PostgreSQL y Redis. Más memoria disponible no implica que esa aplicación responda antes, y dar más CPU a un proceso tampoco equivale a iniciar más procesos.

En nuestra comparación de servidores del 19 de octubre publicamos compresión y hashing con un máximo de dos hilos. Aquellas muestras se conservan. No medían Chatwoot y no permiten convertir sus resultados en una cantidad de empresas alojadas. Esta nueva serie añade evidencia de aplicación, con solicitudes HTTP, notificaciones, recursos y colas.

El aporte de esta comparación es mostrar qué cambió al variar los trabajadores y después ampliar conjuntamente los límites de PostgreSQL y Redis. Publicamos las dos repeticiones de cada ajuste, el timeout registrado y el alcance de las notificaciones observadas.

El resultado del control adicional

El control mantuvo cuatro procesos Sidekiq y seis procesos Puma. Se amplió el tope de PostgreSQL a 2 vCPU y el de Redis a 1 vCPU, en ambos servidores. Cada instancia ejecutó dos rondas de 60 segundos nominales de carga y 20 segundos de observación de la cola. Esta tabla combina las respuestas HTTP satisfactorias de ambas rondas.

En ese control, Hetzner empleó 38,6 % menos CPU media muestreada que Netcup. Los p95 de listar, leer y escribir fueron entre 61,2 % y 67,7 % menores. Es una reducción de esos tiempos y de ese consumo, no un porcentaje de capacidad total ni una velocidad universal del servidor.

Ampliar gráfico · PNG · SVG editable, en el ZIP

El p95 es un punto de una distribución: aproximadamente el 95 % de las respuestas satisfactorias quedan en ese tiempo o por debajo. No describe la respuesta más lenta. Tampoco incluye el timeout como si hubiera sido una respuesta rápida: los errores se contabilizan aparte.

Ampliar gráfico · PNG · SVG editable, en el ZIP

Dos ARM64 de 16 vCPU, con diferente capacidad de memoria

Ambos invitados reportaban Neoverse-N1. Esto acredita el modelo virtual expuesto al sistema invitado, no la identidad o disponibilidad exclusiva del procesador físico. No es una comparación de ARM frente a AMD. Netcup tenía servicios productivos con poca carga de fondo; Hetzner estaba vacío. Los kernels diferían en revisión. Estas condiciones impiden atribuir toda la diferencia a una sola característica del hardware.

Usamos las mismas imágenes ARM64 de Chatwoot Community 4.18.0, PostgreSQL 16 con pgvector y Redis, fijadas por digest. Las referencias exactas están en el protocolo y datos descargables, ZIP. La CPU y la RAM publicadas pertenecen a los contenedores sintéticos; no suman todas las aplicaciones productivas del host.

Los topes del control sumaban 13 vCPU y 11,75 GiB. Son límites configurados, no una reserva de núcleos físicos ni el consumo observado. El conjunto consumió aproximadamente 4,4 GiB de RAM como máximo muestreado en ambos equipos. La documentación de cgroup v2 define los contadores de CPU y memoria usados para esta lectura.

La RAM adicional de Netcup seguía siendo capacidad disponible para otras cargas o crecimiento. En este perfil, esa capacidad no se tradujo en una ventaja de respuesta. Esto tampoco demuestra que 32 GB basten para cualquier instalación de Chatwoot.

Qué hicieron los 60 agentes simulados

La base inicial equivalente contenía 10 cuentas sintéticas, 60 agentes, 10.000 conversaciones y 50.000 mensajes históricos. Cada ronda comenzó desde una restauración de esa base y un Redis de ensayo limpio, después del calentamiento previsto. No se utilizaron conversaciones ni datos de clientes.

El generador se ejecutó dentro de cada host. Los 60 agentes iniciaban su actividad repartidos en los primeros diez segundos y seguían ciclos de diez segundos. Cada uno rotaba sobre seis conversaciones de la base, leía mensajes y escribía en los ciclos previstos. El listado consultaba la primera página con una fase distribuida; no se recorría uniformemente todo el histórico. Parte de las escrituras incorporaba un archivo sintético de 2 MiB; la mitad de los agentes que recibían el mensaje de prueba esperaba 200 ms y respondía por API como un bot determinista.

Registramos 600 solicitudes del perfil por ronda: 60 listados, 360 lecturas, 168 escrituras sin archivo y 12 adjuntos. En ocho rondas por host sumaron 4.800 solicitudes por servidor y 9.600 entre ambos. El conteo no incluye las comprobaciones de salud, la preparación de datos o los intercambios de conexión de ActionCable.

La duración es nominal. El generador dejaba de iniciar ciclos a los 60 segundos, pero completaba la secuencia que ya había comenzado. Por eso algunas solicitudes terminaron después: el último cierre HTTP registrado fue aproximadamente a los 61,25 segundos. Conservamos todas esas solicitudes; CPU y RAM usan las muestras dentro de la ventana nominal, con su cobertura indicada. El detalle por ronda incluye su último final HTTP.

El agente espera la respuesta antes de continuar su secuencia. Es un perfil interactivo temporizado, no una llegada abierta independiente de la latencia. El número de agentes virtuales no equivale al número de empresas que puede atender un servidor. El bot tampoco representa inferencia de IA, Meta, correo o entrega de webhooks externos.

Más trabajadores mejoraron las colas, pero no todo el HTTP

La serie inicial recorrió 1, 2, 4, 4, 2 y 1 procesos Sidekiq por host. Cada proceso tuvo cinco hilos y un tope de 1 vCPU. Web permaneció en seis procesos Puma, cinco hilos y un límite de 6 vCPU. PostgreSQL se limitó a 0,75 vCPU y Redis a 0,25 vCPU.

En Netcup, el p95 combinado de listado subió de 2,836 s con un trabajador a 7,250 s con cuatro bajo esos límites de base de datos y Redis. A la vez, las notificaciones mejoraron y la cola se redujo: una de las rondas con un trabajador conservó 447 trabajos pendientes después del drenaje; con cuatro no quedaron trabajos pendientes al terminar esa observación.

Ese contraste es parte del resultado. Añadir procesos no produjo una mejora uniforme. La documentación de configuración de Chatwoot describe cómo procesos web, concurrencia de Sidekiq y conexiones a la base de datos deben ajustarse conjuntamente. Dar cuatro vCPU a un único proceso no es la misma configuración que ejecutar cuatro procesos con un tope de una vCPU cada uno.

Ampliar gráfico · PNG · SVG editable, en el ZIP

Después hicimos el control de cuatro trabajadores ampliando PostgreSQL de 0,75 a 2 vCPU y Redis de 0,25 a 1 vCPU. El p95 de listado de Netcup bajó a 2,496 s. Cambiaron dos límites a la vez, en una serie posterior: no aislamos cuánto del efecto corresponde a PostgreSQL, a Redis o a las condiciones de esa ronda.

En Hetzner, el listado ya se mantenía por debajo de un segundo de p95 combinado en las configuraciones iniciales. El control no mejoró todas sus métricas respecto a la configuración anterior. Tampoco debe presentarse como un ajuste óptimo definitivo para cualquier base de datos o instalación.

Las repeticiones y las notificaciones cambian la interpretación

En las dos rondas del control, el p95 de listado de Netcup fue 4,090 s y 1,631 s; en Hetzner, 0,783 s y 0,841 s. El combinado fue 2,496 s y 0,805 s respectivamente. El p95 combinado no es la media de esos p95: lo recalculamos desde las respuestas individuales de ambas rondas, con rango más próximo ceil(0,95 × n).

Ampliar gráfico · PNG · SVG editable, en el ZIP

Hubo un timeout de listado en Netcup, en la segunda ronda de cuatro trabajadores de la serie inicial. El control adicional registró cero errores HTTP en ambos hosts. La ausencia de errores HTTP en ese control no certifica entrega perfecta de eventos ni corrección completa de todos los canales reales.

Durante el control se observaron 238 de 240 eventos previstos en Netcup y 239 de 240 en Hetzner dentro de las ventanas registradas. El p95 de ActionCable varió entre 0,319 y 2,105 s en Netcup, frente a 0,142 y 0,144 s en Hetzner. Estos percentiles se conservan por ronda: no disponemos de sus duraciones individuales para combinarlos. Un evento previsto no observado en ventana no prueba por sí solo la pérdida de un mensaje persistido.

Los adjuntos del control tienen solo 24 muestras por host. Su p95 combinado fue 5,269 s en Netcup y 0,310 s en Hetzner. Los incluimos para conservar el resultado completo, pero esa cola de pocos archivos no será un titular universal sobre almacenamiento, subidas desde clientes o rendimiento de red.

Qué podemos concluir y qué sigue sin medirse

En estas dos instancias, con este perfil sintético de Chatwoot, Hetzner respondió más rápido y utilizó menos CPU en el control adicional. Netcup mejoró sus colas al ampliar trabajadores y mejoró la respuesta HTTP al ampliar conjuntamente el margen de PostgreSQL y Redis. La RAM máxima muestreada fue muy similar. Estos datos respaldaron nuestra decisión concreta de migración; no acreditan que la migración esté completada ni validan otras aplicaciones.

Se observó más tiempo steal en Netcup y variación entre rondas. El kernel define este contador como tiempo de CPU sustraído en un entorno virtualizado; la definición primaria de Linux permite interpretar el dato. No hemos aislado toda la causa física de la diferencia y el contador no prueba por sí solo una condición comercial o una política del proveedor.

• Son muestras breves de dos instancias, con dos repeticiones por ajuste. No certifican estabilidad durante días ni representan a todos los servidores de Hetzner o Netcup.
• No agotamos los 16 vCPU ni medimos el máximo de cuentas, agentes humanos o empresas. No hay una conversión válida de “38,6 % menos CPU media” a “38,6 % más clientes”.
• El generador compite por recursos dentro de cada host y la carga de fondo no era idéntica. No se midió la experiencia desde Santiago, la red pública, Meta, correo ni IA.
• El consumo de la pila sintética no es el de todas las aplicaciones del servidor. Los topes de recursos tampoco equivalen a recursos físicos reservados.
• Los ensayos usaron un Redis efímero. Esa configuración de laboratorio no es una recomendación de persistencia o recuperación para producción.
• No comparamos costes actuales en este artículo. Las tarifas históricas del Laboratorio conservan su fecha y no se reutilizan como precios vigentes.

Para repetir una decisión operativa, primero hay que fijar el perfil, los objetivos de respuesta y error, los límites y la recuperación del entorno aislado. Después se valida con los datos y medios reales del proyecto, con los canales y emisores productivos controlados. La capacidad nominal de RAM aporta margen; la elección final necesita saber cómo responde la aplicación.

Datos saneados y método para revisar los resultados

El paquete conserva las 9.600 solicitudes con su operación, duración, estado y tiempo relativo; las muestras de recursos y colas; y los resúmenes originales de eventos por ronda. Los hosts tienen alias públicos. Los originales con accesos e identificadores operativos se mantienen privados.

• Descargar datos, métricas, protocolo, cálculo offline y figuras, ZIP

La descarga contiene las 9.600 solicitudes saneadas en JSON, los resúmenes por ronda, el protocolo, los scripts de cálculo y las figuras PNG/SVG. No contiene credenciales, datos de clientes ni planes editoriales internos.

La CPU de cada ronda se obtiene de la diferencia de contadores cgroup entre la primera y la última muestra de la ventana, dividida por el tiempo cubierto. Para el resumen se promedian las dos medias. La RAM se calcula como el máximo de la suma simultánea, no como la suma de máximos individuales de procesos. Los tiempos y la cobertura del muestreo están en la descarga.

La generación de gráficos y el análisis offline no ejecutan tráfico. Una repetición del ensayo necesita recrear un entorno sintético aislado y revisar su autorización, versiones y perfil. El protocolo no convierte estos resultados en un tamaño máximo de servidor o en un nivel de servicio contratado.

El aprendizaje amplía el método de CPU publicado y el método propuesto para WooCommerce. Los resultados de aquellas entradas permanecen intactos; la evidencia de Chatwoot pertenece a esta nueva serie.