--- title: "Cómo afinamos nuestro RPC para velocidad y confiabilidad" description: "Movimos la compresión de respuestas grandes de RPC a una mejor capa en nuestro serving path, reduciendo la latencia P95 en llamadas pesadas y disminuyendo el churn de conexiones." --- # Cómo afinamos nuestro RPC para velocidad y confiabilidad Nos obsesiona el [rendimiento](https://www.alchemy.com/benchmarks) y ajustamos constantemente nuestra plataforma para seguir optimizándola. Recientemente cambiamos la forma en que nuestra plataforma comprime las respuestas grandes de RPC, y una parte de ese cambio tuvo un efecto desproporcionado para Worldchain. Las respuestas comprimidas en llamadas grandes ahora regresan aproximadamente un 33% más rápido, lo que significa lecturas de bloques completos y otras llamadas pesadas más rápidas, un rendimiento más estable, y más margen para acomodar el crecimiento del tráfico. ## ¿Qué es un frame GOAWAY? Si ejecutas una carga de trabajo de alto rendimiento sobre HTTP/2, conoces los frames GOAWAY aunque nunca los hayas buscado. Un GOAWAY es la señal que un servidor envía para indicarle a un cliente que deje de abrir nuevos streams en una conexión, generalmente porque el servidor está descartando carga. Para el cliente, una ráfaga de GOAWAYs se manifiesta como inestabilidad de conexión: se cortan streams, las solicitudes se reintentan en conexiones nuevas, y la latencia de cola aumenta. Menos GOAWAYs significa [conexiones más estables](https://www.alchemy.com/blog/how-alchemys-node-infrastructure-keeps-defi-fast-at-scale), menos reintentos, y un servicio más rápido. Entonces, cuando el conteo de GOAWAYs de un cliente cae drásticamente, algo en capas superiores acaba de obtener mucho más margen. En este caso, ese algo fue la CPU. ## Dónde solía ejecutarse la compresión Cada respuesta RPC que retornamos puede comprimirse antes de salir de nuestra red. La mayoría de los clientes HTTP solicitan esto enviando un encabezado `Accept-Encoding: gzip`, y la mayoría de los servidores web, incluyendo nuestro propio [node-gateway](https://www.alchemy.com/blog/migrate-self-hosted-nodes-dedicated-infrastructure), respetan ese encabezado automáticamente. No es una característica especial que hayamos construido. Es comportamiento estándar. Para payloads grandes, como lecturas de bloques completos o conjuntos de resultados grandes de [`eth_getLogs`](https://www.alchemy.com/overviews/rpc-node), la compresión reduce significativamente la cantidad de bytes enviados por la red, lo cual importa porque el ancho de banda de internet es limitado. Comprimir en el node-gateway tuvo sentido durante mucho tiempo. Node-gateway es un servicio limitado por IO: pasa la mayor parte de su tiempo esperando llamadas de red, ya sea de clientes o de nuestros propios nodos, por lo que históricamente tenía CPU disponible. La compresión es [trabajo limitado por CPU](https://www.alchemy.com/overviews/how-dedicated-blockchain-infrastructure-works), y su costo crece con el tamaño de la respuesta. A escala, se convirtió en uno de los trabajos más ocupados y más sensibles a la latencia que realizaba el gateway, compitiendo por la misma CPU que necesita para enrutar y atender cada solicitud. Cuando el gateway se sobrecarga, todo lo que hace se ralentiza al mismo tiempo. Y la presión de CPU en el gateway bajo carga es exactamente la condición que activa el descarte de conexiones y los frames GOAWAY. ## ¿Qué cambiamos? Movimos el lugar donde ocurre la compresión de datos, sacándolo de nuestro node-gateway y llevándolo a un proxy Istio en nuestro service mesh. El node-gateway ya no comprime respuestas. Ese trabajo ahora ocurre durante un paso diferente en un proxy Istio, en infraestructura más adecuada para ello. Así, el node-gateway de Alchemy queda libre para optimizar velocidad y confiabilidad, e Istio maneja el paso de compresión. El resultado es la misma respuesta comprimida para nuestros clientes, producida en algún lugar que puede hacerlo de forma más eficiente, sin competir por ciclos en el hop que determina el rendimiento. Mismo stack, misma salida, solo que hecho en un mejor lugar. ## ¿Qué significa esto para ti? Las respuestas comprimidas en llamadas grandes ahora regresan aproximadamente un 33% más rápido (la latencia P95 mejoró aproximadamente un 35%). Esto se descompone en tres aspectos. **Conexiones más estables.** Cuando el hop que atiende tus solicitudes no está luchando por CPU, deja de descartar carga, por lo que obtienes menos GOAWAYs, menos streams cortados, y menos reintentos forzados. Eso fue lo que vio Worldchain: los errores de conexión cayeron de aproximadamente 1,500 por hora a aproximadamente 100. **Respuestas más rápidas en tus llamadas pesadas.** Manejar la compresión en el proxy Istio permite que el primer byte de una respuesta grande salga antes. Para payloads grandes como lecturas de bloques completos o conjuntos de resultados grandes de `eth_getLogs`, eso significa menos tiempo antes de que llegue el primer fragmento de una respuesta. **Más margen debajo de ti.** Liberamos una capacidad de CPU significativa exactamente en el hop que determina tu rendimiento. La mejora se mantiene por solicitud, por lo que sigue manteniéndose a medida que crece tu tráfico. No tienes que cambiar nada para beneficiarte. Ya está operando bajo cada solicitud que envías. ## Por qué importa La mayor parte de lo que hace que un proveedor de RPC sea rápido y confiable ocurre donde nunca lo ves, en hops como este. Un solo servicio haciendo menos del trabajo equivocado, en el lugar correcto, se tradujo en conexiones más estables y respuestas más rápidas de la noche a la mañana, sin que los clientes tuvieran que cambiar nada de su lado. Este es un cambio dentro de un esfuerzo continuo por mejorar nuestra ruta de servicio. [Comienza a construir en Alchemy](https://www.alchemy.com/contact-sales).