Recientemente, el líder de la empresa me pidió que comparara el rendimiento de productos de la competencia. Como novato en pruebas de rendimiento, de repente recibí esa tarea y subconscientemente planteé grandes preguntas.
Después de ordenar mi estado de ánimo, pensé: "El líder debe haberme dado esta tarea sólo para ponerme a prueba". Luego comencé este viaje de prueba de desempeño.
Aprendí de mis compañeros desarrolladores a copiar y pegar códigos en Github para descubrir si existía una herramienta de prueba de rendimiento similar a benchmarksql para bases de datos relacionales en el campo de bases de datos de series de tiempo que pudiera admitir un determinado protocolo de base de datos. Rápidamente descubrí la herramienta de comparación, pero no proporcionaba descargas binarias. Esto no fue un problema. Como alguien que había aprendido a programar durante unos días, era muy bueno compilando e instalando programas Go, así que escribí go install con habilidad. pero... ....
Pensé que sólo un novato en programación como yo tendría fallas de compilación. ¿Por qué las herramientas oficiales de productos populares también...?
No importa, seguí buscando y luego encontré la herramienta tsbs modificada según la herramienta de comparación mantenida por timescaledb. Verifiqué brevemente la estructura y el uso del código (solo puedo echar un vistazo breve ...) Es básicamente lo mismo que la herramienta de comparación. Parece que debería ser confiable.
Esta vez no hubo ningún problema para obtener y utilizar la herramienta, por lo que estaba listo para iniciar el "agradable" proceso de prueba. Entonces fue emo. . .
TSBS me hace mala mierda
El uso y las deficiencias de la herramienta tsbs son realmente frustrantes. A medida que avanza la prueba, el consumo mental aumenta ~~~~ ¿Por qué sucede esto? Porque ocurrieron los siguientes problemas durante el proceso de prueba:
1. No hay advertencia cuando la consulta SQL devuelve resultados vacíos
Al realizar una determinada prueba, el tiempo que llevó completar la prueba fue significativamente más rápido de lo esperado (porque el SQL no debería ejecutarse tan rápido) y el consumo de recursos de hardware del servidor también fue menor de lo esperado. Como probador, todavía no puedo Deja ir este fenómeno.Aprobado. Entonces inmediatamente realizamos una investigación que duró medio día y finalmente descubrimos que la escala utilizada por la herramienta tsbs_generate_queries era diferente del valor de escala de tsbs_generate_data. Como resultado, las condiciones en la consulta SQL generada no coincidían. El conjunto de datos real, lo que resulta en algunos SQL que no necesitan ser leídos.Obtener datos, por lo que la ejecución es muy rápida.
Aquí surgen dos problemas de usabilidad:
1. Los parámetros de las dos herramientas deben ser consistentes, pero pueden establecerse de manera inconsistente si no están familiarizados con ellos, lo que lleva a problemas insuficientes e injustos como las pruebas mencionadas anteriormente.
2. Cuando los datos devueltos por SQL están vacíos, la herramienta no avisa. Por lo general, el SQL ejecutado por la prueba de rendimiento debe devolver datos y la herramienta de prueba también debe verificar si hay datos devueltos. Entonces, incluso si la configuración de los parámetros no coincide debido al primer problema, se descubrirá a tiempo y no habrá necesidad de perder tiempo solucionando el problema.
2. Ejecución manual, demasiadas veces.
El líder requiere que se prueben todos los casos de uso de SQL admitidos por tsbs. Como sigue:
The use case matrix of choices is:
use case: devops, query type: single-groupby-1-1-12
use case: devops, query type: high-cpu-1
use case: devops, query type: single-groupby-5-1-1
use case: devops, query type: cpu-max-all-8
use case: devops, query type: double-groupby-1
use case: devops, query type: double-groupby-5
use case: devops, query type: single-groupby-1-1-1
......Hay 45 casos de uso en total, pertenecientes a tres conjuntos de datos. Cada caso de uso necesita ejecutar cuatro declaraciones de línea de comando para generar archivos de datos, escribir datos, generar declaraciones SQL y ejecutar las declaraciones SQL tres veces. En total, necesito ejecutar manualmente 45*4*3=540 declaraciones de línea de comando. Incluso si no se siente mal por la tecla Intro, cuando se ejecuta el comando, debemos esperar a que se complete la ejecución del comando y llevará tiempo. (Automatización... dong dong dong... automatización... dong dong dong)
3. No se puede controlar la duración de la prueba
La condición final de la ejecución de la prueba del caso de uso es completar la ejecución de todo el SQL generado. Pero para los ejecutores de pruebas, hay un problema. Por ejemplo, para las mismas 100.000 sentencias SQL, una sentencia con un QPS de 1.000/s solo necesita ejecutarse en 100, mientras que una sentencia con un QPS de sólo 10/s requiere 10.000. Este tiempo de ejecución varía mucho dependiendo de los diferentes Servicios SQL o bases de datos. .
Queremos poder controlar la duración total de la prueba.
Al utilizar la herramienta tsdb para realizar pruebas, los evaluadores primero deben "explorar" para obtener una cantidad total razonable de SQL para tener un tiempo de ejecución aceptable; de lo contrario, la espera puede ser extremadamente larga. Además, cuando se explora un conjunto SQL razonable para una determinada base de datos y se utiliza para probar otra base de datos, puede llevar mucho tiempo.
4. Declaraciones SQL limitadas
Las declaraciones de tsbs son limitadas, únicamente las enumeradas en el punto 2. Si es necesario agregar nuevas declaraciones SQL, debe agregar código al código del programa tsbs, lo cual es engorroso y difícil.
5. Los resultados de rendimiento no corresponden a declaraciones SQL específicas
tsbs necesita seleccionar el escenario (caso de uso) y el tipo (tipo) para generar la declaración SQL antes de poder ver la declaración SQL de prueba específica. Cuando se completa la prueba y se descubre que los resultados de la prueba de rendimiento no son ideales, solo podemos saber qué escenario o tipo no es ideal, pero no sabemos qué SQL no es ideal, lo que requiere que el evaluador adivine o pruebe uno. por uno, lo cual es muy importante para las pruebas de rendimiento, pero para el análisis final del rendimiento es muy problemático y requiere mucho tiempo.
6. No se admiten escenarios mixtos de lectura y escritura.
De hecho, para las pruebas de rendimiento, un escenario más realista es un escenario en el que hay solicitudes de lectura y de escritura. Por lo tanto, si la herramienta puede admitir escenarios mixtos de lectura y escritura, es importante medir el rendimiento de una base de datos.
7. Las herramientas están demasiado fragmentadas y la configuración de los parámetros es propensa a errores.
No solo hay demasiadas herramientas y están dispersas, y sus parámetros deben ser consistentes para obtener resultados de prueba razonables, sino que cada herramienta tiene muchos parámetros. Una leve negligencia puede conducir fácilmente a diferentes configuraciones de parámetros, lo que puede conducir a diferentes resultados de las pruebas. Aún no se conocen resultados razonables, lo que lleva a conclusiones erróneas.
8. No hay registro automático de resultados.
tsbs requiere que los evaluadores registren manualmente los resultados de la prueba de cada comando, lo cual es particularmente problemático y fácil de recordar incorrectamente.
...No hay más que decir, me siento cansado.
Esta dolorosa ejecución de la orden duró mucho tiempo, llegando al extremo del agotamiento mental. Incapaz de soportarlo, Xiaobai usó su mayor habilidad: la técnica de invocación del jefe, jefe ~ jefe ~
El jefe examinó los requisitos y las preguntas de mi examen, escuchó mis quejas, conectó el teclado y comenzó su actuación.
Finalmente me tomó un mes y me quedé despierto hasta las 12 en punto todas las noches (estaba dispuesto a pasar un mes porque las pruebas de comparación de rendimiento posteriores se realizarán muchas veces, así que decidí dedicar una cierta cantidad de tiempo para ahorrar tiempo de pruebas posteriores). ) y lo modificamos según la herramienta de comparación y optimización, escribimos nuestra propia herramienta de prueba de rendimiento fcbench (la longitud de este mapa del estado de Yan no es mala, Qin Shihuang, por favor, eche un vistazo...)
FCBench me hizo primero alegre(muy feliz)
El ambiente se ha intensificado aquí, golpeemos rápidamente mientras el hierro está caliente y enumeremos las ventajas de fcbench en comparación con la herramienta de comparación.
1. Integre múltiples comandos tsdb
Integre varios comandos tsbs, como tsbs_generate_queries, tsbs_run_queries_influx, etc., en un programa de comando, y el objeto de operación del programa es un caso de prueba. Cada caso de prueba contiene las siguientes etapas:
a. Limpiar el medio ambiente (opcional)
fcbench admite la ejecución continua de casos de uso (también para prepararse para la comparación automatizada del rendimiento), por lo que puede especificar si desea limpiar el entorno en el archivo de configuración del caso. Nota: La base de datos se reiniciará incluso si no se limpia el entorno. La limpieza del entorno puede eliminar la interferencia de diferentes escenarios de prueba o pruebas independientes de múltiples versiones.
b. Preparar datos (opcional)
Los datos preparados aquí son diferentes del archivo de datos preparado de tsbs: fcbench escribe una cierta cantidad de datos en la base de datos de destino como el objeto de destino de la consulta de datos.
C. Ejecutar automáticamente múltiples casos de prueba.
D. Recopilación automática de resultados.
2. Ejecución automatizada de casos de uso
fcbench admite casos de uso de ejecución continua sin intervención manual. Ejecute un comando de agente en la máquina de destino (servidor) y controle el inicio, eliminación, inicialización, parada y otras operaciones de la base de datos mediante el envío de solicitudes http. De esta manera, los casos de uso se pueden ejecutar continuamente en lugar de ejecutar comandos bash línea por línea como tsbs. Por ejemplo, puede ejecutar pruebas toda la noche y esperar a ver los resultados al día siguiente. Todo lo que necesita hacer es preparar un archivo de caso de prueba como se muestra a continuación:
{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":1,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":1000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":100000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":10,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":100,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":5000,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
{"Group":"车载采样时间变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":10000,"SamplingIn3. Admite plantillas SQL
Solo hay un número limitado de SQL ejecutados por tsbs. Si necesita agregar declaraciones SQL para realizar pruebas, debe agregarlas a nivel de código. fcbench proporciona un método de plantilla SQL y se pueden escribir plantillas para ejecutar SQL arbitrario. Por ejemplo:
seleccione aqi de city_air_quality donde site_id = '{site_id}' ordenar por límite de tiempo de descripción 1"
Cuando se ejecuta el '{site_id}' anterior, se completará de acuerdo con el valor en la columna site_id en el conjunto de datos y luego se probará. Al igual que tsbs, el site_id del sql incluido en cada solicitud es diferente.
4. Recopilación automática de resultados.
fcbench generará una recopilación de resultados para cada caso de uso (correspondiente a cada línea en el archivo de caso de prueba) y generará un archivo csv para facilitar el procesamiento y análisis posteriores. Incluye el número de errores de declaración, tiempo de respuesta (promedio, p90, p95, p99), qps, etc. Los evaluadores no están obligados a esperar a que las pruebas se completen y registren manualmente.
5. Fácil de ampliar
Mediante un buen diseño arquitectónico, solo necesita agregar código para una base de datos específica y no necesita modificar el código existente para admitir otros tipos de bases de datos.
Con fcbench, finalmente puedo realizar pruebas de rendimiento felizmente y mi energía mental ha comenzado a recuperarse lentamente ~~~
Por supuesto, esto es solo una prueba comparativa para obtener los resultados de la prueba. De hecho, una prueba de rendimiento completa todavía requiere muchas cosas, como monitoreo de recursos, análisis de cuellos de botella, ajuste de parámetros, etc. Como novato, mi viaje de pruebas de rendimiento acaba de empezar.
[Pruebas de rendimiento] ¡Finalmente, hay un conjunto completo de tutoriales de pruebas de rendimiento! ¡Práctica de proyecto de proceso completo de prueba de rendimiento empresarial real!