Mentiras, grandes mentiras y estadísticas (de Cloudflare): desmentimos las recientes pruebas de rendimiento de Cloudflare

Hace unas semanas, Cloudflare, competidor de Fastly, publicó una entrada de blog en la que afirmaba que su plataforma de «edge computing» es aproximadamente tres veces más rápida que Compute@Edge. Esta conclusión, carente de todo sentido, demuestra con claridad que se pueden utilizar las estadísticas para confundir a los consumidores. Aquí encontrarás un análisis de la metodología de realización de pruebas que emplea Cloudflare y los resultados de una comparativa más objetiva y práctica.  

Suele decirse que hay tres tipos de mentiras: las mentiras, las grandes mentiras y las estadísticas. Este dicho quizás no haga justicia a algunos datos estadísticos, que son bastante fiables. Sin embargo, las estadísticas que recoge la afirmación siguiente no lo son:

¿Por dónde empezar? La mención de Catchpoint dota a esta afirmación de un supuesto carácter de estudio independiente realizado por terceros. No lo tiene. Catchpoint permite configurar sus herramientas en función de las necesidades que tengas. Esto quiere decir que podrías utilizar aquellas para crear un test según un estándar para pruebas de referencia que sea equitativo y riguroso...; o bien podrías apoyarte en las mismas para contar la historia que más te convenga.

¿Qué errores contienen sus pruebas?

El diseño y la ejecución de las pruebas de Cloudflare presenta varios defectos: 

1. Cloudflare empleó una muestra selecta de nodos de Catchpoint en las pruebas. Aunque ignoramos por qué se escogió este conjunto de nodos en particular, conviene resaltar dos aspectos: primero: las ubicaciones de la infraestructura de Cloudflare no coinciden con las nuestras; segundo: elegir las ubicaciones de prueba de manera sesgada tiene un efecto radical en los resultados que se obtienen.

2. En las pruebas que realizó Cloudflare se comparó JavaScript ejecutándose en Cloudflare Workers —producto consagrado y de disponibilidad general— con JavaScript ejecutándose en Compute@Edge. Aunque la plataforma Compute@Edge está disponible en la actualidad para todo el mundo en fase de producción, la compatibilidad de Compute@Edge con JavaScript está en fase beta. En nuestra documentación se afirma con claridad que los productos en fase beta no son aptos para su uso en producción. En este sentido, una prueba más ajustada a la realidad habría sido comparar Rust ejecutándose en Compute@Edge con JavaScript ejecutándose en Cloudflare Workers: los ciclos de ambos productos son más equiparables.

3. Cloudflare utilizó en su comparativa una cuenta de prueba gratuita de Fastly. Las prestaciones de cuentas de prueba gratuita y cuentas de pago son diferentes: el uso está limitado en las primeras, y el rendimiento de ambas en condiciones de carga no es comparable.

4. Cloudflare realizó las pruebas durante una sola hora y en un solo día. Se impide así normalizar patrones de tráfico diarios o eventos anómalos y deja abierta la posibilidad de que se produzcan distorsiones aleatorias. Si realizaras varias tandas de pruebas a diferentes horas del día, es probable que, en algún momento, logres obtener los resultados esperados.

5. Según la entrada de blog de Cloudflare, el código de la prueba «ejecutó una función que se limita a devolver la hora actual». Sin embargo, el ejemplo de código que se incluye más adelante en dicha entrada devuelve una copia de los encabezados de la petición entrante. O bien la afirmación del blog es incorrecta, o bien lo es el código de ejemplo. Resulta imposible evaluar o reproducir un resultado en condiciones objetivas si la metodología de la prueba no se explica con claridad.

6. No es coherente medir el rendimiento de Compute@Edge evaluando únicamente el tiempo hasta el primer byte (TTFB) por medio de pruebas donde apenas hay cargas de cálculo, las cargas útiles no están dimensionadas de manera significativa y no hay API de plataforma.

Los defectos que acabamos de exponer sugieren que el método que ha utilizado Cloudflare es seudocientífico. Así que... ¿por qué nos parece importante destacarlo? Y, ya puestos, ¿qué rendimiento real presenta Compute@Edge?

¡Sorpresa!: Compute@Edge es más rápida que Cloudflare Workers

Conviene aclarar que no se puede afirmar lo anterior con certeza porque el TTFB es una métrica que no indica qué plataforma es la «más rápida» —veremos detalles al respecto más adelante—. Lo que sí podemos afirmar es que nuestra red y Compute@Edge obtienen mejores resultados que la red de Cloudflare y Cloudflare Workers en una versión menos sesgada de las mismas pruebas; incluso en términos del TTFB.

Es difícil medir el rendimiento relativo de redes del borde. La época de las CDN ya quedó atrás, por lo que no es posible valorar una red del borde a partir de una sola métrica. Si algún actor debería ser consciente de esta circunstancia, ese es Cloudflare; sobre todo, por las impresionantes capacidades en el edge de que dispone. Sin embargo, ninguna de estas se aplicó a la ejecución de las pruebas.

Todos desconfiamos de participar en este tipo de «pruebas de referencia», en las que se comparan métricas parecidas. ¿El motivo?: que añaden confusión. Además, no podemos definir nuestras propias métricas con fines comparativos porque las condiciones de uso de Cloudflare prohíben realizar pruebas de referencia de sus servicios:

Por eso, sometimos a nuestra propia plataforma a las mismas pruebas (reproduciendo los encabezados y midiendo el TTFB a través de Catchpoint), aunque con bastantes diferencias clave:

• Utilizamos muchos más nodos de Catchpoint (673, en lugar de 50) y durante un periodo mucho más largo (una semana, frente a una hora).

• Utilizamos un archivo binario de Wasm compilado con Rust (en vez de con JavaScript). 

• Utilizamos una cuenta de pago de Fastly (en vez de una cuenta de prueba gratuita).  

En este enlace podrás ver los resultados en bruto. La conclusión que se extrae es que, al hacer pruebas más equitativas, la rapidez de nuestra red y Compute@Edge es mayor que la de la red de Cloudflare y Cloudflare Workers en cuatro de seis aspectos, incluso en términos dela métrica que mostramos a continuación, que también es errónea:

Datos de Fastly: TTFB medio, 673 nodos de Catchpoint, 378 000 peticiones, realizadas desde las 00:00 h del 24/11/2021 hasta las 00:00 h del 30/11/2021 (seis días) [resultados]. Datos de Cloudflare: TTFB medio, 50 nodos de Catchpoint, número de peticiones desconocido, realizadas desde las 20:30 h del 08/11/2021 hasta las 22:00 h del 08/11/2021 (1,5 h) [resultados].

Si atendemos al TTFB preferido de Cloudflare, nuestra red con Compute@Edge en ejecución es casi dos veces más rápida que Cloudflare Workers en Norteamérica y Europa, y 10 veces más rápida en Oceanía. No hay que olvidar que las condiciones de servicio de Cloudflare prohíben realizar pruebas de referencia, lo cual nos impide realizar evaluaciones comparativas directas de su producto y tratar de replicar las cifras de Oceanía.

Compute@Edge no tiene asociado un lenguaje nativo, porque ejecutamos los archivos binarios de WebAssembly directamente en nuestros servidores en el edge. Sin embargo, Rust es el lenguaje que ofrece en la actualidad una de las mejores combinaciones de experiencia del desarrollador y rendimiento del código compilado. Podrás ejecutar casi cualquier cosa en Compute@Edge si se compila en WebAssembly. Y la gente lo hace.

Vale, pero... ¿qué pasa con JavaScript?

Aunque somos conscientes de que la compatibilidad con JavaScript es importante para muchos clientes, aún no nos convence el rendimiento que se consigue con paquetes de Compute@Edge compilados con JavaScript. Es por eso por lo que está en beta. En el momento en el que un producto está listo para la fase de producción, le retiramos la calificación de beta.

Crear nuestra plataforma de «edge computing» ha supuesto salirnos de la mayoría de las tendencias del sector. Esto se traduce en que nuestro rendimiento evoluciona de manera diferenciada, ya que los problemas que nos afectan de inicio son distintos.

Uso de cifras adecuadas en las comparativas

Vayamos ahora al fondo del TTFB y analicemos por qué esta métrica no es útil en este contexto.

Cloudflare publicó los resultados de pruebas que no miden el rendimiento de cálculo de una forma significativa. En lugar de medir una sola variable, deberíamos utilizar una prueba de referencia que evalúe el rendimiento del «edge computing» en casos de uso esencial que sean importantes para los clientes. Dicha prueba debería incluir el tiempo de ida y vuelta (RTT) de la red y otras variables, como las siguientes:

• Tiempo de arranque hasta la entrega de petición al código del cliente

• Rendimiento de cálculo («tiempo de reflexión») respecto a cargas de trabajo de diversos tamaños

• Rendimiento de la caché respecto a objetos muy populares y contenido long-tail

• RTT hasta los servidores de origen para casos de uso en los que intervengan peticiones de origen

Las pruebas de Cloudflare son deficientes hasta en la medición del RTT de la red —porque el TTFB engloba al RTT de la red y al tiempo de reflexión del servidor—. Además, la contribución de cada componente a la cifra global es indescifrable: para comprender el rendimiento con mayor precisión, los componentes deberían poder distinguirse.  

Por ejemplo, en las gráficas siguientes se muestran las medidas del RTT de la red y el TTFB registradas en Asia respecto a un servicio de Fastly. La rapidez que alcanza cualquier acierto de caché que se distribuye desde nuestra plataforma VCL (gráfica izquierda) es tal que el RTT de la red (azul) es básicamente idéntico al TTFB (verde). Si se utiliza Compute@Edge (gráfica derecha), el TTFB queda diferenciado, lo cual refleja el incremento de costes que supone ejecutar código arbitrario. Aun así, el RTT representa la mayor parte de la cifra global del TTFB en regiones cuya latencia de conexión suele ser más alta (Asia en los ejemplos siguientes).

El RTT varía según la ubicación geográfica, tendencia que se acentúa de forma espectacular en los resultados de la prueba principal expuestos antes. Por tanto, podemos afirmar que las pruebas de Cloudflare no ofrecen claridad respecto al rendimiento relativo de nuestras plataformas de edge computing —o sea, en lo que se refiere al «tiempo de reflexión del servidor»—.

Diseño de mejores resultados para los clientes

El proyecto en el que trabajamos ahora es un conjunto de herramientas de comparación de rendimiento que evaluará las prestaciones en un entorno más realista. Además, vamos a publicar su código y vamos a encargar a un tercero independiente la medición y publicación de los resultados correspondientes. Y lo hacemos así totalmente convencidos: porque nos cansan las competiciones de «nerd-sniping», que nos desvían de nuestro objetivo: mejorar Internet para todo el mundo.

Para terminar, afirmamos de manera categórica que es falso que la plataforma Cloudflare Workers sea un 196 % más rápida que Compute@Edge. De hecho, ni siquiera es más rápida que nuestra plataforma. De todos modos, las variables relevantes para nuestros clientes son aquellas que son esenciales para sus negocios. Si no sabes si Fastly es lo suficientemente rápido para tus necesidades específicas en relación con las métricas que te interesan, no lo dudes más: prueba nuestra solución y compruébalo tú mismo/a.

Este artículo contiene «previsiones de futuro» que se basan en las creencias y suposiciones de Fastly, así como en información que estaba a nuestro alcance en la fecha de su publicación. Las previsiones de futuro implican riesgos, incertidumbres y otros factores, conocidos o no, que podrían provocar que nuestros resultados, rendimiento o logros reales fueran distintos de los indicados, expresa o implícitamente, en dichas previsiones. Estas previsiones incluyen, entre otros factores, declaraciones acerca de futuras ofertas de productos. Salvo que la ley exija lo contrario, Fastly no asume ninguna obligación de actualizar estas previsiones de futuro públicamente ni de informar de los motivos por los que los resultados reales podrían discrepar de manera sustancial de aquellos avanzados en dichas previsiones, incluso en el supuesto de conocer más adelante nueva información que no esté disponible en la actualidad. Algunos de los factores relevantes que podrían causar discrepancias sustanciales en los resultados reales de Fastly se detallan en los informes que Fastly presenta a la Securities and Exchange Commission (SEC, Comisión del Mercado de Valores de los EE. UU.), como el informe financiero anual de Fastly, recogido en el Formulario 10-K para el ejercicio fiscal finalizado el 31 de diciembre de 2020, y los informes trimestrales, recogidos en el Formulario 10-Q. En el sitio web de Fastly se publican copias de los informes presentados a la SEC, que también pueden solicitarse a Fastly y obtenerse gratuitamente.