NCache Puntos de referencia de rendimiento
2 millones de operaciones/seg
(Clúster de 5 nodos)
Resumen Ejecutivo
NCache puede ayudarlo a escalar linealmente y mejorar el rendimiento de manera fácil y rentable. Las empresas Fortune 500 de todo el mundo han confiado NCache durante más de 13 años para eliminar los cuellos de botella de rendimiento relacionados con el almacenamiento de datos y las bases de datos y para escalar las aplicaciones .NET al procesamiento de transacciones extremas (XTP).
Este documento utilizará NCache 5.0 con API modernas y algunas características nuevas para demostrar la escalabilidad lineal y el rendimiento extremo que puede lograr para sus aplicaciones .NET. En este experimento, empaquetamos un módem NCache API con una topología de caché particionada con canalización habilitada. Los datos se distribuyen completamente en todos los servidores de almacenamiento en caché y los clientes se conectan a todos los servidores para solicitudes de lectura y escritura.
En este punto de referencia, demostramos que el NCache el clúster puede escalar linealmente y eso lo logramos 2 millones de transacciones por segundo usando solo 5 nodos de servidor de caché. También demostraremos que NCache puede ofrecer una latencia inferior al microsegundo incluso en un clúster grande. En este documento técnico, cubriremos la configuración de los puntos de referencia, los pasos para realizar los puntos de referencia, las configuraciones de prueba, las configuraciones de carga y los resultados. Puede ver el experimento de referencia en acción en este video.
Descripción general de la configuración de Benchmark
Revisemos nuestra configuración de referencia. Vamos a utilizar servidores AWS m4.10xlarge para esta prueba. Tenemos cinco de estos NCache servidores en los que configuraremos nuestro clúster de caché. Tendremos 15 servidores cliente, desde donde ejecutaremos aplicaciones para conectarnos a este clúster de caché.
Vamos a utilizar Windows Server 2016 como sistema operativo – Data Center Edition, 64 bits. Él NCache la versión que se utiliza es 5.0 Enterprise. En esta configuración de referencia, utilizaremos un Topología de caché con particiones. En una topología de caché dividida, todos los datos se distribuirán completamente en particiones en todos los servidores de almacenamiento en caché. Y todos los clientes estarán conectados a todos los servidores para solicitudes de lectura y escritura para utilizar todos los servidores al mismo tiempo. No tenemos la replicación activada para esta topología, pero hay otras topologías como la Topología de réplicas con particiones que viene equipado con soporte de replicación.
Tendremos Tubería habilitado, que es una nueva característica en NCache 5.0. Funciona de tal manera que en el lado del cliente acumula todas las solicitudes que ocurren en tiempo de ejecución y aplica esas solicitudes a la vez en el lado del servidor. La acumulación se realiza en microsegundos, por lo que está muy optimizada y es la configuración recomendada cuando tiene requisitos de carga transaccional altos.
Aquí hay una descripción general rápida de nuestra configuración de referencia, que incluye hardware, software y configuraciones de carga.
Configuración de hardware:
| Detalles del cliente y del servidor (Máquina virtual) |
AWS m4.10xlarge: 40 núcleos, 160 GB de memoria, red: Ethernet de 10 Gbps |
| No. de nodos de servidor | 5 |
| Nº de nodos de cliente | 15 |
Configuración de software:
| Sistema operativo | Windows Server 2016 Edición de centro de datos – x64 |
| NCache Versión | 5.0 |
| Topología de clúster | Configuración de caché con particiones |
Configuración de carga:
| Tamaño del caché | 4 GB |
| Tamaño de datos | Matriz de bytes de tamaño 100 |
| Articulos totales | 1,000,000 |
| Tubería | implante |
| Relación de obtener/actualizar | 80:20 |
| Temas | 1280 |
| Instancias de aplicaciones | 2 instancias por máquina cliente, 30 instancias en total |
Población de datos
Después de la configuración de nuestro entorno de referencia, comenzaremos con una población de datos de 1 millón de elementos en el clúster de caché. Ejecutaremos la aplicación Cliente (Cargador de elementos de caché) que se conectará y agregará 1 millón de elementos en el caché. Un cliente se conectará con todos los servidores de almacenamiento en caché y agregará 1 millón de elementos en el clúster de caché, después de lo cual podemos comenzar con las solicitudes de lectura y escritura.
Puede usar este Paquete Nuget – NCache SDK para instalar el SDK en la máquina cliente y configurar la canalización entre el cliente y el servidor e implementar la aplicación de generación de carga (GitHub) para completar 1 millón de elementos de caché en el clúster de caché.
Crear carga de transacción
Ahora ejecutaremos la aplicación para crear una carga transaccional en este clúster de caché con un 80 % de operaciones de lectura y un 20 % de operaciones de escritura. Puede monitorear toda la actividad usando los contadores Perfmon. Inicialmente, conectaremos 10 instancias de clientes a cada NCache servidor con actividad en búsquedas y actualizaciones por segundo.
1 Carga de transacción de 1 millón de operaciones/seg.
Puede ver en la captura de pantalla que con 10 instancias de cliente que se conectan a un clúster de 5 nodos, tenemos solicitudes por segundo que oscilan entre 180,000 190,000 y 5 XNUMX. Y como tenemos XNUMX NCache servidores que están trabajando en paralelo, la acumulación de estas solicitudes nos lleva a 1 millón de solicitudes por segundo por parte de este clúster de caché.
Tenemos un uso eficiente de la memoria y la CPU y la operación promedio de microsegundos/caché es un poco menos de 10 microsegundos por operación. Nuestra etapa uno se completa donde hemos logrado 1 millón de operaciones por segundo desde nuestro clúster de caché.
| Etapa 1 - Hoja de datos de resumen | |
| Total de servidores de caché en clúster | 5 |
| Total de instancias de clientes conectadas | 10 |
| Solicitudes por segundo/nodo | 180,0000 190,000 ~ |
| Solicitudes totales - Clúster de caché | 950,000 1,000,000 ~ |
| % de tiempo de procesador (máx.) | 20% |
| Memoria del sistema | 4.2 GB |
| Latencia (operación de microsegundos/caché) | 10 microsegundos/operación |
2 Carga de transacción de 1.5 millón de operaciones/seg.
Ahora que hemos alcanzado el millón de TPS, es hora de aumentar la carga en forma de más instancias de aplicaciones para aumentar la carga transaccional. Y tan pronto como estas aplicaciones se ejecutaran, vería un aumento en el contador de solicitudes por segundo. Vamos a aumentar la cantidad de clientes a 1. Con esta configuración, puede ver en la captura de pantalla a continuación que ahora estamos mostrando 20 solicitudes por segundo por instancia. Hemos logrado con éxito 300,000 millones de solicitudes por segundo de este clúster de caché.
Puede ver que el recuento de solicitudes por segundo por cada servidor es 300,000. Las recuperaciones son un poco más de 200,000 50,000 por segundo y las actualizaciones están entre 100,000 4 y 3 4 y puede ver que el microsegundo promedio por operación de caché es inferior a XNUMX microsegundos; eso es sorprendente porque tenemos una latencia muy baja junto con el impacto de la canalización. Cuando tiene una alta carga transaccional desde el extremo del cliente, la canalización realmente ayuda y reduce la latencia y aumenta el rendimiento. Es por eso que recomendamos que esté activado. Además, tenemos el promedio de microsegundos por operación de caché ahora en algún lugar alrededor de XNUMX-XNUMX microsegundos por operación de caché.
| Etapa 2 - Hoja de datos de resumen | |
| Total de servidores de caché en clúster | 5 |
| Total de instancias de clientes conectadas | 20 |
| Promedio Solicitudes por segundo/nodo | 300,000 |
| Solicitudes totales - Clúster de caché | 1,500,000 |
| % de tiempo de procesador (máx.) | 30% |
| Memoria del sistema | 6 GB |
| Latencia (operación de microsegundos/caché) | 3 ~ 4 microsegundos/operación |
3 Carga de transacción de 2 millón de operaciones/seg.
Aumentemos aún más la carga ejecutando más instancias de aplicaciones que también mostrarán un mayor aumento en las solicitudes por segundo. Ahora vamos a conectar las instancias de 30 clientes a todos NCache servidores.
Según la captura de pantalla a continuación, ahora puede ver que hemos tocado con éxito 400,000 solicitudes por segundo que estamos recibiendo por cada NCache servidor; tenemos 5 NCache servidores por lo que hace que el número de hasta dos millones de transacciones por segundo por este NCache clúster de caché. Y tenemos los microsegundos promedio por operación de caché que suman menos de 3 microsegundos. También tenemos la memoria del sistema y el tiempo del procesador muy por debajo de los límites con una utilización del 40 - 50 % en ambos frentes.
Ahora tenemos una latencia de 2 ~ 3 us/operación, una mejora con respecto al resultado anterior. Una vez más, puede ver una combinación de recuperaciones, actualizaciones y una utilización eficiente de los recursos de CPU y memoria. Podemos concluir aquí que NCache es linealmente escalable. Ahora revisemos nuestros números de escalabilidad.
| Etapa 3 - Hoja de datos de resumen | |
| Total de servidores de caché en clúster | 5 |
| Total de instancias de clientes conectadas | 30 |
| Promedio Solicitudes por segundo/nodo | 400,000 |
| Solicitudes totales - Clúster de caché | 2,000,000 |
| % de tiempo de procesador (máx.) | 60% |
| Memoria del sistema | 6 GB |
| Latencia (operación de microsegundos/caché) | 2 ~ 3 microsegundos/operación |
Resultados de referencia
Pudimos demostrar que NCache es linealmente escalable y pudimos lograr los siguientes resultados después de ejecutar los puntos de referencia:
Conclusiones
- Escalabilidad lineal: Con 5 NCache servidores pudimos lograr 2 millones de solicitudes por segundo. Agregar más y más servidores significa más capacidades de manejo de solicitudes de NCache.
- Baja latencia y alto rendimiento: NCache ofrece una latencia de submicrosegundos (2.5 ~ 3 microsegundos) incluso con un tamaño de clúster grande. NCache ayuda a cumplir con los requisitos de baja latencia y alto rendimiento, incluso a escala. Tenemos una latencia muy baja, un impacto derivado del pipelining. Cuando tiene altas cargas transaccionales desde el extremo del cliente, la canalización realmente ayuda y reduce la latencia y aumenta el rendimiento.