Esta publicación no se refiere a los tipos de problemas de rendimiento que un sistema de almacenamiento de archivos agrupado ejecuta; más bien, profundizará en el proceso de encontrar rápidamente esos problemas y eliminarlos.
Dicho esto, muchas de las anécdotas y procedimientos se basan en el campo de los sistemas distribuidos. La aplicación de esta ideología a sistemas embebidos u otros reinos drásticamente diferentes puede no resultar significativa.
Mantener el rendimiento
Escribir código de ejecutante siempre debe ser un objetivo en el software, pero a menudo no es la primera prioridad. Para muchos desarrolladores, el código es correcto siempre que pase todas las pruebas y eso es todo. Debido a este comportamiento, uno de los primeros y más críticos pasos para tener un buen rendimiento es hacer que los puntos de referencia de rendimiento se conviertan en pruebas de "corrección". Esto ayuda a evitar regresiones de rendimiento y, si se combina con un perfil detallado, estas ejecuciones de prueba pueden proporcionar los datos necesarios para investigar el rendimiento. Aunque la implicación de mantener el rendimiento es que el rendimiento ya es alto, esta debe ser la primera prioridad en el rendimiento. Sin esto, los cambios que hacen retroceder el rendimiento son mucho más difíciles de diagnosticar y prevenir.
Obteniendo rendimiento
El primer paso para mejorar el rendimiento es establecerse en un tipo o escenario que debería mejorar. Esto significa escribir una prueba de rendimiento que categorice ese escenario, si no existe, y obtener una línea de base. Para recopilar datos útiles concretos, es posible que se deban crear o emplear nuevos sistemas. Herramientas como contadores de rendimiento y rastreo del sistema son excelentes lugares de inicio y las ideas detrás de ellos se pueden extender fácilmente para medir el uso en el código base que se está mejorando.
Ahora que todos los requisitos previos están cubiertos, podemos comenzar a iterar. Con los sistemas implementados para medir tanto el rendimiento general como el de grano fino, el mejor lugar para comenzar es en todos los sistemas que utilizan una gran cantidad de uno o varios recursos del sistema. Dependiendo del producto, el cuello de botella podría estar en muchos sistemas diferentes. El principal efecto secundario de un cuello de botella es que el trabajo se atasca en una cola en algún lugar del sistema. Esto puede manifestarse como un sistema que se ejecuta a una capacidad máxima o cercana o la misma cantidad de trabajos inactivos en el mismo punto. Una vez que sepamos qué sistema está siendo usado en exceso, es hora de hacer una hipótesis acerca de por qué ese sistema está caliente. Idealmente, esto es lo más específico posible y es sencillo realizar un experimento para probar o refutar rápidamente.
A menudo es mejor crear experimentos que se basan en una simplificación excesiva del sistema que se está probando. La razón por la que la prueba de unidad es tan poderosa es que se enfoca en probar una pieza a la vez; en las pruebas de rendimiento es importante cambiar solo un factor a la vez cuando se prueban prototipos. Las pilas de prototipos que parecen mostrar mejoras incrementales pueden tener pistas falsas y generalmente no son concluyentes.
En lugar de centrarse en escribir código seguro y correcto para subprocesos, el enfoque en esta etapa debe ser en los prototipos que brindan las mayores ganancias de rendimiento independientemente de la corrección. Si eliminar la protección alrededor de una estructura de datos genera una gran ganancia de rendimiento, probablemente valga la pena optimizar esa estructura de datos o hacerla segura para el acceso múltiple. La optimización de la estructura de datos sin evidencia de que no es eficaz tiene un alto costo con valor incierto.
Una vez que se realiza un experimento, debe apoyar o contradecir la hipótesis. A menudo, se contradecirán muchas hipótesis antes de encontrar un cuello de botella en el rendimiento. Eventualmente, debería ser posible reducir el espacio del problema a algo específico que se pueda mejorar. En este punto, es hora de cambiar del modo de investigación a la implementación. Esto a veces puede ser difícil ya que es un cambio bastante grande de ritmo y estilo. Además, lo que debe cambiarse fácilmente podría estar en una parte del sistema donde la familiaridad puede ser mínima o inexistente. De nuevo, esto demuestra por qué los prototipos son una parte importante del proceso. Una vez que se construye una solución, el proceso se reinicia; comenzando de nuevo con la recopilación de nuevos datos de referencia.
Para ver esta estrategia en acción, consulte esta publicación de blog de otro miembro de mi equipo: Mejora de la eficiencia de bloqueo
Consejos y trucos
- Toda la investigación es útil. Documente los resultados negativos para evitar duplicar esfuerzos.
- Ve a preguntas que puedan ser respondidas rápidamente.
- Recopilar tantos datos como sea posible
- Utilizar múltiples fuentes de evidencia.
- Confíe en sus herramientas o reconstrúyalas hasta que esté
- Recopila mas datos en serio
- Usa tanto micro como macro de benchmarking.
- Asegúrese de que el entorno en el que realiza las pruebas sea constante en todas las pruebas (a menos que este delta sea el un factor siendo probado)
- Cuando se presenta una hipótesis, a menudo es mejor generar algunas.
- Si hay más de una hipótesis, ordénelas utilizando la búsqueda heurística que desee; algunos factores a considerar son la probabilidad estimada de que la hipótesis conduzca a un mejor desempeño y cuán difícil será la prueba de la hipótesis.
Contáctanos aquí si quieres programar una reunión o solicitar una demostración. Y suscríbase a nuestro blog para obtener mejores prácticas y recursos más útiles.
