Comprensión de la referencia de rendimiento publicada por Cisco y Solarflare utilizando Couchbase Server

De vez en cuando, los usuarios que buscan ejecutar Couchbase Server en producción preguntan sobre el rendimiento de Couchbase Server, así como los resultados de tiempo de respuesta y rendimiento para cargas de trabajo típicas. Recientemente Cisco y Solarflare publicaron un whitepaper presentando los resultados de un benchmark que ejecutaron en los Cisco Labs usando Couchbase Server como base de datos NoSQL. Mientras que el benchmark fue diseñado específicamente para demostrar los beneficios de 10Gig Ethernet, así como las optimizaciones a nivel de kernel, también demuestra algunas fortalezas clave de Couchbase Server que nuestros clientes han llegado a amar y confiar en sus despliegues de producción. Este blog destaca algunos detalles adicionales y conocimientos obtenidos de ese ejercicio de evaluación comparativa.

El benchmark ejecutó dos conjuntos de pruebas, ambos con una carga de trabajo mixta con 70% de lecturas y 30% de escrituras. En la primera prueba, el tamaño del documento almacenado varió de 128 bytes a 16 KB y se midió la latencia media de las operaciones de lectura y escritura de extremo a extremo (del cliente al servidor de base de datos y viceversa) para distintas configuraciones de red.

El gráfico 1 muestra los resultados y demuestra que Couchbase Server es ridículamente rápido con respuestas de microsegundos incluso en una Ethernet de 1 Gig y un tamaño de documento de 16 KB. La latencia fue inferior a 200 μseg utilizando una Ethernet de 10Gig para documentos de todos los tamaños e inferior a 500 μseg para todos los casos. Pero lo más importante es que demuestra latencia constante y previsible (Gráfico de latencia plana en 10GigE, mientras que los documentos más grandes tardan algo más en transferirse en una red de 1GigE). Este aspecto clave desempeña un papel importante en la experiencia de usuario de las aplicaciones web.

Gráfico 1

En la segunda prueba, se midió el rendimiento medio a medida que se añadían nodos al clúster de Couchbase, de 1 a 5 nodos.

Gráfico 2

En el gráfico 2 se puede ver que, incluso con sólo 4 nodos, el rendimiento es de casi 1,15 millones de operaciones. por segundo. Acerca de 1,4 GB por segundo de datos se transfiere realmente entre el servidor de la base de datos y el cliente.  Alto rendimiento de escritura incluso con documentos de 1 KB de tamaño considerable. Aunque un alto rendimiento puede ser un requisito para algunas aplicaciones, esta prueba también mostró rendimiento lineal a medida que se añaden más servidores al clúster: 0,62 millones de ops / seg con 2 nodos y 1,15 millones de ops / seg con 4 nodos.

Puede que se pregunte cómo este nivel de rendimiento de la base de datos es factible. En el centro está la arquitectura y el diseño de Couchbase Server:

1. Una arquitectura de nada compartida en la que todos los nodos son idénticos e independientes permite una escalabilidad lineal
2. Las claves se reparten automáticamente por todo el clúster y se distribuyen uniformemente tanto si el clúster tiene 1 como 8 nodos.
3. La baja granularidad de los bloqueos de Couchbase y la mínima contención permiten un alto rendimiento de escritura.
4. Las lecturas se producen independientemente de las escrituras y de forma simultánea, lo que permite un alto rendimiento de lectura independientemente del número de escrituras.
5. El nivel de caché gestionado integrado permite respuestas de baja latencia constantes

A continuación he incluido algunos detalles adicionales sobre la configuración de Couchbase Server para el benchmark. Espero que hayas encontrado este blog útil, y te animo a descargar Couchbase Server para ver si se adapta bien a tu aplicación web.

Otras notas

A continuación se ofrecen algunos detalles adicionales sobre la configuración del banco de pruebas:

Se utilizaron ocho nodos que ejecutaban Couchbase Server 1.8.0 como servidores de bases de datos NoSQL, y un nodo se utilizó para ejecutar las pruebas. Couchbase Server se configuró con una réplica. Se utilizó un servidor como cliente para ejecutar la carga de trabajo. El generador de carga de trabajo utilizado para la prueba fue mcsoda generador de carga de streaming de código abierto con una mezcla de operaciones GET y SET en una proporción de 70:30.

Más información sobre el generador de carga de trabajo aquí.