Analizando Millones de URLs por Segundo

Hola. Hoy voy a hablar sobre el análisis de millones de URLs por segundo. Mi nombre es Elzen Zipli y soy un ingeniero de software senior en Sentry. Soy miembro del comité directivo técnico de OGS. Soy miembro del consejo de proyectos cruzados de la Fundación OpenJS. Puedes contactarme a través de mi cuenta de GitHub, github.com, y a través de X, anteriormente conocido como Twitter, en X.com. El rendimiento del software en la última década ha cambiado drásticamente. El objetivo principal era reducir costos en entornos de nube como AWS, Azure o Google Cloud. La latencia ha sido un problema y, para mejorarla, necesitamos optimizar nuestro código más que nunca. Reducir la complejidad, el paralelismo, la caché y el rendimiento trae ese tipo de cosas. Y lo más importante, el cambio climático. Las computadoras más rápidas han dado lugar a un mejor futuro y un mejor clima. Entonces, el estado del rendimiento de Node.js en 2023. Esta es una cita de eso. Desde Node.js 18, se agregó una nueva dependencia de análisis de URLs a Node.js 8. Esta adición eleva el rendimiento de Node.js en el análisis de URLs a un nuevo nivel. Algunos resultados pueden alcanzar una mejora del 400%. Estado del rendimiento de Node.js en 2023 y esto está escrito por Rafael Gonzaga, que es miembro del comité directivo técnico de Node.js. Esta charla trata sobre cómo logramos una mejora del 400% en el análisis de URLs. Otra cita de James Snell de Cloudflare y también del TSC de Node.js. Simplemente establece un punto de referencia para un cambio de código, pasa de tardar 11 segundos en completarse a aproximadamente medio segundo en completarse, esto me hace muy feliz. Esto se refiere a la adición de Ada URL a Cloudflare. Entonces, comencemos con la estructura de una URL. Por ejemplo, tenemos HTTPS usuario contraseña en example.com, 1 2 3 4, que es el número de puerto, luego tenemos Foo, Bar, Buzz y QUU. Comienza con el protocolo, HTTPS es el protocolo, termina con la barra. Luego tenemos el nombre de usuario y la contraseña. Este es un campo opcional en todas las URLs. Luego tenemos el nombre de host, que es example.com. Luego tenemos el puerto, que es 1 2 3 4. Y luego

tenemos el nombre de ruta, que es barra diagonal Foo barra diagonal. Y luego vemos la búsqueda, que comienza con un signo de interrogación Buzz. Y luego tenemos el hash, que es QUU. Entonces, el número de puerto, nombre de ruta, búsqueda, hash, nombre de usuario, contraseña, todos son opcionales. Incluso el nombre de host es opcional si tienes una URL de archivo. Pero esto es solo un ejemplo de cómo es esta estructura de una URL. También hay, a pesar de la estructura de la URL, también hay diferentes codificaciones que la especificación de URL admite, como el formato no ASCII, que es el primero. Luego admitimos URL basadas en archivos, que es lo que ves en sistemas basados en Unix, archivo, barra, barra, barra, Foo, Bar, Buzz, Foo, Bar, Test, Node.js. Luego tenemos URL de JavaScript, que es JavaScript dos puntos alerta. Luego tenemos la codificación porcentual que comienza con una URL que tiene subsecciones, subcadenas que tienen un carácter de porcentaje en guion. Y luego tenemos nombres de ruta con puntos, que es como ejemplo.org barra punto A barra A punto punto barra B, que básicamente se resuelve en una URL diferente según la especificación de URL. Luego tenemos direcciones IPv4 con dígitos hexadecimales y octales, 127.0.0.0.0.0.0.0.1, que es 127.0.0.0.1. Y también tenemos IPv6 y así sucesivamente. Según lo que hacemos con la URL, si ingresamos esta cadena de entrada, HTTPS711home punto punto barra Montreal. PHP en PHP, no cambia. En Python, no cambia. En lo que hacemos con la URL, que es implementado por Chrome, Safari y todos los navegadores, incluido Ada, es xn-guion-guion-711 y así sucesivamente. En curl, es muy diferente. Y como puedes ver, en Go runtime, también es muy diferente. Esto se debe principalmente a diferentes implementaciones y también a todos los demás subsistemas, todos los demás lenguajes que no siguen estrictamente lo que hacemos con la URL. Para PHP y Python, básicamente analizan la URL desde el principio y la cadena sin hacer ninguna asignación. Y para curl y Go, implementan una especificación diferente llamada RFC 3787. O similar, no estoy muy seguro. Entonces tenemos estas suposiciones antiguas como ¿realmente importa el análisis de URL? ¿Es el cuello de botella de alguna métrica de rendimiento? Las URL son gratuitas, no ganas nada superponiéndolas.

Estas fueron las suposiciones que rompimos con nuestro trabajo. Y verás por qué. Así que creemos, entendamos si estas suposiciones son verdaderas. Creemos la prueba de referencia HTTP utilizando Festify. Y hay dos puntos finales que obtienes al usar un post, que es slash simple. Básicamente tiene una URL en el cuerpo JSON y lo mismo para el otro. Pero en el primero, no estamos devolviendo, estamos devolviendo la URL sin hacer nada. En el segundo, la estamos analizando con la nueva URL. Y luego estamos devolviendo el href, que es la cadena que le corresponde. Y luego, en la parte inferior, verás el ejemplo de entrada que enviamos y la comparación entre

En slash simple, casi tenemos 60,000 solicitudes por segundo. Pero si lo analizamos, tenemos alrededor de 50,000, 50, 52, tal vez 52,000. Por lo tanto, el análisis de URL era un cuello de botella en el nodo 18.50. Así que esto se ejecuta en el nodo 18.50, antes de ADA, antes de cualquier optimización que se haga en el análisis de URL. Así que anunciamos el analizador de URL ADA, que lleva el nombre de mi hija, Ada Nisiply. Es un analizador de URL completo compatible con what-vg. No tiene dependencias, es completamente portátil. Esto significa que no incluye ICU. Tiene más de 20,000 líneas de code. Es el trabajo de seis meses de 25 colaboradores. Tiene licencia Apache 2.0 y MIT. Está disponible en github.com. Actualmente es utilizado por Node.js y CloudFlare workers. En general, puede analizar 6 millones de URL por segundo. Esta prueba de referencia que estoy compartiendo con ustedes se ejecuta en Apple M2, LLVM 14. Tiene una amplia gama de fuentes de datos realistas. Y es más rápido que las alternativas en C, C++ y ROS. Y para las bibliotecas que implementan what-vg URL, también es mucho más rápido. En el lado derecho, verán Wikipedia 100k, que es 100,000 URL analizadas y analizadas del dominio de Wikipedia. Top 100 son los sitios web con más tráfico del mundo. Y el tercero son los archivos de Linux. Básicamente, rastreamos el sistema operativo Linux y almacenamos cada ruta. Luego tenemos la base de usuarios y el HTTP que encontramos en Internet. Como pueden ver, Ada es casi el doble de rápido que la segunda alternativa. Es alrededor de un 6 a 7% más rápido que curl en este momento. Para lograr eso, tenemos algunos trucos que en general te darán un

La idea de cómo logramos estos resultados asombrosos. El primer truco es la perfect hashing. Esto significa que hemos reducido el número de ramificaciones. Y si puedes ver, tenemos nombres de una matriz de vista de cadena, HTTP, HTTPS, W, FTP, WSS file. Luego tenemos estos contextos llamados HTTP, no URLs especiales, HTTPS, WS, que corresponden a los web sockets, FTP, WSS y file. Estos tipos corresponden al esquema de URL what-vg. Y para obtener el tipo de esquema a partir de aquí, utilizamos un algoritmo para encontrar perfectamente la posición correcta dentro de la matriz de nombres de la entrada que tenemos. Y este es uno de los ejemplos. El segundo truco es, por supuesto, las tablas de memoización. Para reducir el número de ramificaciones y reducir las declaraciones condicionales, lo que hicimos fue utilizar operaciones a nivel de bits y obtener los valores ya analizados de una tabla en sí. Al hacer eso, tenemos una tabla de carga que contiene 255 caracteres y almacena cero o uno según si es un carácter malo o no. Este es un gran ejemplo de cómo mejorar el rendimiento de una función y, al mismo tiempo, aumentar el tamaño del binario. El tercero es utilizar la vectorización. Por lo tanto, no proceses byte por byte cuando puedes procesar 16 por 16. Los nuevos procesadores en el mundo actualmente admiten la iteración de vectorización de 16 por 16 a través de la matriz, por lo que no necesitamos iterar uno por uno. Y, por ejemplo, este ejemplo tiene tabulaciones o una nueva línea. Para entender si una cadena en particular tiene un carácter de tabulación o una nueva línea, utilizamos el siguiente ejemplo. No voy a profundizar en esto por el bien de hoy, pero la información está disponible y hay optimizaciones disponibles para aumentar la iteración y el tiempo de ejecución de un bucle for básico con ciertos trucos. Además de estas eficientes bibliotecas de C++ y JavaScript, estas optimizaciones, proporcionamos un puente eficiente entre JavaScript y la implementación de C++. Esto se hace especialmente para la integración con Node.js para que el costo de serialización de la conversión de cadena a cadena de C++ a JavaScript se reduzca lo máximo posible. Pasar múltiples cadenas es costoso, y pasar una cadena con un desplazamiento. Básicamente, tenemos un href y devolvemos ocho enteros diferentes que corresponden al final del protocolo, final del nombre de usuario, inicio del host, final del host, etc. Entonces, si conocemos el final del protocolo, puedes tomar la subcadena del href tomando de cero al final del protocolo, por ejemplo, y si tienes un nombre de usuario, etc. Estas son optimizaciones que mejoran la base de código en un 60, 70, 80 por ciento. Aquí tienes un ejemplo de benchmark de JavaScript. Básicamente, toma líneas y trata de analizarlas y agrega la longitud del href a un valor y luego cuenta las URL buenas y las URL malas. Esto se hace para eliminar las optimizaciones del compilador JIT para deshabilitar esa eliminación de código en V8. El benchmark está disponible en github.com/adurl/gs-url-benchmark y por favor, échale un vistazo y si hay algo que nos hayamos perdido, por favor, tómate el tiempo para crear un problema en el repositorio de GitHub. Este benchmark en particular en el nodo 18.15.0 ejecutó alrededor de 0.8 millones de URL por segundo. En ese momento, dno 1.32.5 estaba haciendo 0.9 millones, bun 0.5.9 estaba alrededor de 1.5 millones, y en el nodo 20.1.0, ahora mismo es de 2.9 millones.

URLs por segundo. La biblioteca Ada C++ es segura y eficiente. Lo escribimos en C++ moderno. Realizamos pruebas exhaustivas. Probamos con sanitizadores. Realizamos fuzzing testing. Tenemos muchas unit tests que contribuyeron especialmente a las pruebas de la plataforma web. Se informaron algunos errores menores en los últimos meses, principalmente relacionados con el estándar. Los corregimos rápidamente en menos de 24 horas.

Ada está disponible en el lenguaje de tu elección. En JavaScript, está disponible en Node.js. Tenemos enlaces en C en GitHub. Tenemos Rust, Go, Python y R. A menudo, esta es la única forma de obtener soporte en esos lenguajes en particular. Gracias por escuchar. Puedes ponerte en contacto con Ada URL en AdaURL.com. Puedes ponerte en contacto con mi blog en y puedes ponerte en contacto con el blog de mi coautor, Daniel Lemire, en lemire.me. Gracias.