Esta es la inmersión profunda en formato largo. Para obtener una versión más rápida y de lectura rápida, consulte el publicación de blog complementaria.
1. Introducción: acumulaciones de hábitos versus cargas de trabajo reales
Las opciones tecnológicas en organizaciones maduras rara vez fallan porque nadie lee una publicación de blog de referencia. Fallan porque el proceso porque elegir es débil: la preferencia de un ingeniero senior ruidoso, un proceso de contratación lleno de un idioma o una única demostración impresionante en una conferencia. Mientras tanto, el producto combina API sensibles a la latencia, conciliación por lotes, autenticación perimetral en NGINX, CLI internas y un pico ocasional sin servidor. Un tiempo de ejecución no puede ser óptimo para todas esas formas.
Este artículo explica Puntos de referencia políglotas — un panel de comparación en vivo y el abierto ejemplos de flujo de trabajo/puntos de referencia arnés detrás de él, como un marco de decisión, no una tabla de clasificación de fanáticos. El objetivo es evidencia que pueda adjuntar a un registro de decisión de arquitectura (ADR): mismos puntos finales, mismo generador de carga, mismo diseño de contenedor, múltiples idiomas.
No inventaré cifras de rendimiento en prosa. Cuando ejecuta el arnés, el panel muestra las solicitudes medidas y los percentiles de latencia para ese hardware y la configuración de Docker. Trate aquí cualquier clasificación estática como patrones cualitativos alineados con las familias de pruebas del arnés y la copia del veredicto integrado en el panel.
2. ¿Qué son los puntos de referencia Polyglot?
Puntos de referencia políglotas está alojado en políglota-benchmarks.fictionally.org (Infraestructura de marca ficticia en el ecosistema de ejemplos de flujo de trabajo). El titular del aterrizaje compara:
- NGINX Nueva Jersey — Módulos JavaScript dentro del stock NGINX
- OpenResty Lua — Lua en el borde de OpenResty
- Python FastAPI — Aplicación Uvicorn ASGI
- Ir a red/http — servidor de biblioteca estándar
- Rust Actix-web — HTTP asíncrono en Actix
- Bollo — Tiempo de ejecución de JavaScript con servidor HTTP nativo
- Java (Javalin/Jetty) — JVM HTTP ligero en Jetty
- Kotlin (Ktor / Netty) — JVM HTTP compatible con rutinas en Netty
El titular en vivo es un 8 idiomas comparación: njs frente a Lua frente a Python frente a Go frente a Rust frente a Bun frente a Java frente a Kotlin. El subtítulo enmarca la intención: actuación para cargas de trabajo largas de sondeo/chat/cola/API — rutas con muchas conexiones, JSON y rutas en lugar de una única carrera de carros de "hola mundo". Las tiendas JVM finalmente obtienen la misma superficie ferial que Go/Rust/Bun en lugar de una anécdota “empresarial” separada.
2.1 Qué muestra el panel
Mientras avanza una ejecución, la interfaz de usuario sondea /data/results.json cada dos segundos y renderiza:
- Solicitudes/seg (rendimiento) - agregado de
wrkpor idioma por prueba - Latencia media y Latencia de cola P99 — en milisegundos del modelo de latencia de wrk
- TTFB (tiempo hasta el primer byte) - de curl timing JSON junto con wrk
- tabla resumen — ganadores por prueba con ★ marcadores en las mejores celdas
- Tarjetas de prueba detalladas — gráficos de barras y tablas métricas (P50, P90, P99.9, errores)
- Distribución percentil de latencia — promediado entre pruebas
- Veredicto: lo mejor para su caso de uso - narrativa una vez que el estado es
complete
Esa estructura es deliberadamente compatible con los ARB: gráficos para diapositivas, tablas para hojas de cálculo, narrativa para la sección de riesgo de un ADR.
3. El conjunto de ejemplos de flujo de trabajo
Todo lo reproducible vive bajo benchmarks/ en el ejemplos de flujo de trabajo repositorio. Diseño de nivel superior:
benchmarks/
bench.sh # orchestrates tests, writes results.json
wrk_json.lua # wrk done() → JSON summary (RPS, percentiles)
docker-compose.yml # eight app services + dashboard + bench runner
njs/ # NGINX + njs module
lua/ # OpenResty nginx.conf
python/ # FastAPI + Dockerfile
golang/ # net/http main.go
rust/ # Actix-web + Cargo
bun/ # Bun server.ts
java/ # Javalin on Jetty
kotlin/ # Ktor on Netty
dashboard/ # static index.html + nginx.conf3.1 Topología de composición de Docker
docker-compose.yml define servicios aislados en una red compartida:
nginx-njs— puerto 8081, configuraciones de./njsopenresty-lua— puerto 8082python-fastapi— puerto 8084, construido a partir de./pythongo-server— puerto 8085rust-actix— puerto 8086bun-server— puerto 8087java-server— puerto 8088, Javalin / Jetty desde./javakotlin-server— puerto 8089, Ktor / Netty de./kotlindashboard— puerto 8083, sirve HTML y monta elresultsvolumen en/databench— Contenedor alpino que se instalacurl,wrk,jq, espera dependencias, ejecutabench.sh
El corredor de banca comparte el results Volumen con el panel para que los resultados aparezcan en vivo sin copia manual.
3.2 metodología bench.sh
El controlador de shell codifica explícitamente las reglas de equidad:
- Duración:
10spor punto final por idioma - Trapos: 4
- Conexiones: 100 concurrentes
- Calentamiento: 50 balas golpeando
/helloen cada servidor antes de las pruebas cronometradas - Por servidor: curl timing JSON (dns, connect, ttfb, total) más wrk con
wrk_json.lua
Siete pruebas están delimitadas por barras verticales en el script:
| IDENTIFICACIÓN | Nombre | Intención | Punto final |
|---|---|---|---|
| 1 | Texto sin formato | Línea de base: respuesta mínima, sobrecarga del marco | /hello |
| 2 | Serialización JSON | Cree y serialice una matriz JSON de 100 elementos | /json |
| 3 | CPU-con destino (fibra 30) | Fibonacci recursivo(30) — CPU puro | /cpu?n=30 |
| 4 | Manipulación de cuerdas | Construir, dividir, poner en mayúsculas y volver a unir 1000 segmentos | /string |
| 5 | Solicitar inspección | Encabezados, método, argumentos → JSON | /request_info?foo=bar&baz=123 |
| 6 | Subsolicitud + Transformar | Subsolicitud interna, analizar JSON, transformar | /subrequest |
| 7 | Lógica de enrutamiento | Enrutamiento condicional en parámetros de consulta | /route?action=greet&name=bench |
Cada idioma implementa la misma superficie de ruta (ver golang/main.go, python/main.py, java/, kotlin/, configuraciones de NGINX, etc.), por lo que las diferencias reflejan el tiempo de ejecución y el marco, no especificaciones que no coinciden.
4. Por qué es importante lo “políglota” (sin fanatismo)
La arquitectura políglota no significa que cada ingeniero aprenda ocho idiomas. significa contextos acotados obtenga un tiempo de ejecución que se ajuste a:
- Plano de borde — autenticación, límites de velocidad, enrutamiento: Lua o njs dentro de NGINX que ya opera
- Plano central API — lógica empresarial con SLO: Go or Rust
- plano JVM — propiedades existentes de Spring/Jakarta, bibliotecas compartidas, profundidad de contratación: Java (Javalin) o Kotlin (Ktor)
- Plano de datos - ETL, cuadernos, pegamento ML: Python
- Plano JS en tiempo real — WebSockets, tipos compartidos con frontend: Bun o Node donde gana la velocidad
Las pilas uniformes optimizan los recursos humanos y las adquisiciones. Los puntos de referencia de Polyglot optimizan ajuste por carga de trabajo con compensaciones mensurables sobre la mesa.
5. Dimensiones que importan
Las solicitudes sin procesar son la métrica que viaja más rápido en Slack. También es el más fácil de malinterpretar. Utilice una rúbrica de varias columnas:
| Criterio | Domina cuando... | Señal del arnés |
|---|---|---|
| latencia p50 / p99 | API orientados al usuario, chat, encuesta larga | percentiles de latencia laboral; tabla P99 del tablero |
| Rendimiento (RPS) | Puertas de enlace de alta distribución, agregadores por lotes | trabajo RPS; columna resumen del ganador |
| Memoria por conexión | Miles de WebSockets inactivos | Perfiles cualitativos + de producción (no totalmente aprovechados) |
| TTFB | Fallo de CDN, caminos fríos, redes móviles | rizo time_starttransfer en resultados JSON |
| LOC / complejidad | Startups, control de cambios regulado | Comparar implementaciones entre carpetas |
| Tiempo de construcción y CI | Implementaciones frecuentes, muchos servicios | Docker crea perfiles por idioma |
| carga de operaciones | Pequeño equipo de plataforma | Habilidades NGINX existentes → Lua/njs; otros contenedores |
| Costo de alojamiento | Siempre activo versus escalado a cero | Derivado de memoria + CPU bajo carga (producción) |
6. Matriz de decisión
El siguiente diagrama es el mapa cualitativo que utilizamos en las revisiones: líderes ilustrativos, no un sustituto del uso del arnés en su kit.
Léalo primero en la fila: elija la forma de su carga de trabajo y luego pondere las columnas. Si dos criterios entran en conflicto (por ejemplo, el mejor RPS versus el LOC más bajo), esa tensión es el tema que vale la pena tener en la discusión sobre ADR.
7. Patrones de casos (etiquetado de ejemplo)
Los siguientes mapas aprovechan las familias de pruebas para las opciones arquitectónicas. Los líderes de su máquina aparecen en el panel después de una ejecución; no trate esta sección como puntuaciones fijas.
7.1 API sensible a la latencia (Pruebas 1–2, 5–7)
Los JSON API y los controladores de enrutamiento intensivo reflejan las pruebas 2, 5 y 7. Los tiempos de ejecución asíncronos compilados (Rust Actix, Go) generalmente lideran el rendimiento y la latencia de cola en esta clase de puntos de referencia HTTP sintéticos; Bun a menudo se ubica cerca de caminos con mucho JSON con ergonomía JS. Java (Javalin) y Kotlin (Ktor) brinde a los equipos de JVM una lectura justa de los líderes en las mismas rutas, lo que resulta útil cuando la pregunta es "permanecer en la JVM con una pila más liviana" versus "reescribir en Go/Rust". Python FastAPI intercambia RPS sin procesar por velocidad de desarrollo; el veredicto del panel lo indica explícitamente.
7.2 Microtrabajo vinculado a CPU (Prueba 3)
Fibonacci(30) aísla CPU sin E/S. Espere que Rust y Go brillen; las pilas interpretadas pagan gastos generales; JVM JIT puede parecer más fuerte después del calentamiento de lo que implica una ventana fría de 10 segundos; extienda la duración si ese es su perfil real. Si su servicio real está vinculado a E/S, no le dé demasiada importancia a esta fila: es una prueba de esfuerzo para middleware con gran capacidad informática, no un CRUD típico.
7.3 Transformación de borde (Pruebas 6 a 7, variantes de NGINX)
Las pruebas de subsolicitud y enrutamiento son donde OpenResty Lua y NGINX Nueva Jersey Pertenecen: cero saltos adicionales, memoria de trabajo compartida, los equipos de operaciones ya administran NGINX. El veredicto del arnés recomienda Go/Rust para los backends centrales de chat/cola y Lua/njs en el borde, una división sensata que muchas empresas ya administran de manera informal.
7.4 ETL por lotes y canalización de datos
El arnés HTTP no emula las cargas de Spark ni del almacén. Para el procesamiento por lotes, los equipos suelen priorizar el ecosistema y la orquestación de Python (Airflow, Dagster) o los trabajadores de Go para el rendimiento. Utilice puntos de referencia políglotas para Superficies y planos de control API esos trabajos exponen, no para el motor por lotes en sí.
7.5 Herramienta interna rápida
API de administrador interno con QPS bajo y alta tasa de cambio: Python o Bun/Node a menudo ganan en velocidad y contratación. Ejecute la Prueba 2 (JSON) y la Prueba 5 (inspección) para garantizar que la sobrecarga sea aceptable; Si p99 aumenta por debajo de 100 conexiones, reconsidere antes de promocionar a niveles de atención al cliente.
7.6 Estado JVM (Java y Kotlin)
Muchas empresas ya ejecutan Java o Kotlin para bibliotecas compartidas, herramientas de cumplimiento y profundidad de contratación. El arnés java-server (Javalin en Jetty, puerto 8088) y kotlin-server (Ktor en Netty, puerto 8089) implementan los mismos siete puntos finales que Go y Rust, por lo que puede cuantificar si una pila HTTP JVM más liviana es "lo suficientemente buena" para un SLO determinado antes de una reescritura. Prefiera Kotlin cuando la concurrencia de estilo de rutina y los primeros equipos Kotlin sean importantes; prefiera Java cuando el estado circundante y el gráfico de la biblioteca ya están centrados en Java. Utilice las filas del panel en vivo; no asuma que los números de Spring Boot son iguales a los números Javalin/Ktor.
8. Diagrama de flujo de trabajo
El bucle reproducible: especifique la carga de trabajo → ejecute el arnés Compose → publique los resultados en el panel de Fictionally (o su clon interno) → registre un ADR con metadatos de configuración → vuelva a ejecutar cuando cambien los tiempos de ejecución o el hardware.
9. Cómo realizar tu propia comparación
- Clon:
git clone https://github.com/bwalia/workflow-examples.git && cd workflow-examples/benchmarks - Pila inicial:
docker compose up --build— crea imágenes en todos los idiomas, inicia el panel en el puerto 8083, ejecuta el banco automáticamente. - Mirar: abierto
http://localhost:8083(o el sitio público cuando una ejecución alojada está activa). - Extender: agregar una carpeta
myruntime/, reflejar rutas de puntos finales, registrar un servicio endocker-compose.yml, agregue el servidor aSERVERSenbench.sh. - Personalizar carga: editar
DURATION,THREADS,CONNECTIONSen la cima debench.sh— documentar los cambios en su ADR. - Agregue pruebas en forma de producción: p.ej. middleware de autenticación, consulta ORM, carga útil de 50 KB: mantenga la paridad entre idiomas.
Para CI, ejecute Compose en un flujo de trabajo nocturno, archive results.json como un artefacto y falla solo en los umbrales de regresión que usted defina (por ejemplo, p99 +20% semana tras semana en la Prueba 2).
10. Antipatrones
- Elegir al ganador de la Prueba 1 únicamente – el texto plano favorece pilas mínimas; ignora JSON, CPU y los problemas de enrutamiento.
- Ignorar las habilidades del equipo — La oxidación en producción sin mentores es costosa en tiempo de incidentes.
- Ignorando el costo de alojamiento — 2× RPS es inútil si la memoria por módulo duplica tu factura.
- Exigir un idioma en toda la organización — destruye las divisiones legítimas entre la ventaja y el núcleo.
- Reemplazo de perfiles de producción. — HTTP sintético ≠ su ORM, caché o latencia regional.
- Comparando hardware diferente — Docker para computadora portátil ≠ metal desnudo ≠ límites de K8s; tenga en cuenta la clase en el ADR.
11. Beneficios para el liderazgo en ingeniería
- paquetes de BRA — exportar capturas de pantalla del panel +
results.json+ Componer hash. - Evidencia neutral respecto del proveedor – no hay plataforma de ventas de un único proveedor de nube o marco.
- Claridad de incorporación — los nuevos empleados ven *por qué* el servicio A es Go y el servicio B es Python.
- Reducción de riesgos – pilotear el subcampeón en un servicio paralelo antes de las reescrituras.
- Conversaciones sobre FinOps – vincular la latencia de cola con el escalado automático y el margen de memoria.
- Hoja de ruta de la plataforma – justificar la inversión en habilidades de NGINX frente a otro microservicio K8.
12. Limitaciones
- Cargas de trabajo sintéticas — siete pruebas HTTP no pueden representar consumidores de Kafka, trabajos GPU o gráficos ORM complejos.
- redes acoplables — añade gastos generales; Los números absolutos difieren del metal desnudo.
- Clase de máquina única — los resultados alojados reflejan cualquier hardware que se utilice ficticiamente; tus números serán diferentes.
- Sin capa de persistencia — Los efectos de base de datos y caché están ausentes por diseño.
- Duración de tirada corta — Es posible que 10 segundos por prueba no expongan pausas en la general o acantilados de calentamiento; ampliar para campañas de estrés.
Mantenga la creación de perfiles continuos (eBPF, APM, pruebas de carga contra puesta en escena) como fuente de verdad para la producción. Polyglot Benchmarks reduce el alcance lenguaje y marco debate con líneas de base reproducibles.
13. Conclusión
El sesgo de pila predeterminada es cómodo; También es la forma en que los equipos envían el tiempo de ejecución incorrecto para el trabajo. Puntos de referencia políglotas y el ejemplos de flujo de trabajo aprovechar el turno "¿qué idioma gana?" en "¿qué idioma gana?" para esta fila de carga de trabajo?” – con gráficos que su ARB puede citar.
Bifurque el repositorio, agregue los puntos finales que se parezcan a sus rutas activas, ejecute Compose y adjunte los resultados a la siguiente decisión de arquitectura. el compañero publicación de blog es la versión de cinco minutos para compartir; este artículo es la referencia.
Publicado por Workstation (estación de trabajo.co.uk). Panel de referencia alojado en políglota-benchmarks.fictionally.org en el ecosistema de ejemplos ficticios.
Instantánea de SEO para este artículo
- Título SEO: Puntos de referencia políglotas: la herramienta adecuada para el trabajo
- Meta descripción: Compare njs, Lua, Python, Go, Rust, Bun, Java y Kotlin en las mismas cargas de trabajo HTTP. Arnés reproducible, panel en vivo, matriz de decisiones para arquitectos.
- Palabras clave principales: puntos de referencia políglotas, comparación de lenguajes, decisiones de arquitectura, ejemplos de flujo de trabajo, puntos de referencia de rendimiento, Rust vs Go, Java vs Kotlin, FastAPI, Javalin, Ktor
- Twitter / X (menos de 280 caracteres): Puntos de referencia políglotas: las mismas 7 pruebas HTTP en njs, Lua, Python, Go, Rust, Bun, Java, Kotlin: panel en vivo + arnés de ejemplos de flujo de trabajo. Ningún ganador; un marco de decisión. #Rust #GoLang #Java #Kotlin #Bunjs #polyglot
- Publicación de LinkedIn: Publicamos un análisis profundo sobre Polyglot Benchmarks: cómo dejar de elegir por costumbre una pila para toda la organización y comenzar a hacer coincidir los tiempos de ejecución con las cargas de trabajo. Ocho lenguajes (incluidos Java/Javalin y Kotlin/Ktor), siete pruebas comparables, Docker Compose + wrk, resultados en vivo en polyglot-benchmarks.fictionally.org, fuente en github.com/bwalia/workflow-examples/tree/main/benchmarks. Incluye matriz de decisión, antipatrones y orientación ADR. De la ingeniería Workstation. #Rust #GoLang #Java #Kotlin #Bunjs #Lua #Python #njs #FastAPI #Javalin #Ktor #OpenResty #polyglot #benchmarks
