Aprender a comprender el desempeño de un sistema en ejecución es inevitable por la misma razón que tiene el aprender a depurar. Incluso si el código que comprendes perfectamente es justamente el costo del código que escribes, tu código hará llamadas a lo interno de otros sistemas de software sobre los que tienes poco control o visibilidad. Sin embargo, en la práctica los problemas de desempeño son un poco diferentes y un poco más fáciles que la depuración en general.
Supón que tú o tus clientes consideran que un sistema o un subsistema es muy lento.
Antes de que intentes hacerlo más rápido, debes construir un modelo mental de por qué es lento. Para comprender el problema, puedes usar una herramienta de perfilación o una buena bitácora para determinar realmente dónde están siendo gastados el tiempo y los otros recursos. Hay un famoso dicho de que el 90% del tiempo será gastado en 10% del código. Yo añadiría a eso la importancia de los costos de entrada/salida (E/S) a los tópicos de desempeño. A menudo la mayor parte del tiempo se gasta en E/S de una forma u otra. Encontrar la E/S costosa y el costoso 10% del código es un buen primer paso para comprender el problema.
- Identifica los cuellos de botella de desempeño.
- Analiza detenidamente el comportamiento del sistema.
- Evalúa el uso de recursos.
Hay muchas dimensiones relacionadas al desempeño de un sistema computacional, y muchos recursos consumidos. El primer recurso a medir es el tiempo del reloj de pared, el tiempo total que pasa para la computación. Registrar en la bitácora el tiempo del reloj de pared es particularmente valioso debido a que él puede informar acerca de circunstancias impredecibles que surgen en situaciones donde otra forma de perfilación es impráctica. Sin embargo, esto podría no siempre representar toda la escena. Algunas veces algo que toma un poco más de tiempo pero que no quema tantos segundos del procesador será mucho mejor con lo que tienes que lidiar realmente en el ambiente computacional. Similarmente, la memoria, el ancho de banda de la red, la base de datos u otros accesos a servidores pueden, al final, ser mucho más costosos que los segundos del procesador.
La contención de recursos compartidos que están sincronizados puede causar estancamiento e inanición. El estancamiento es la incapacidad para proceder debido a la inapropiada sincronización o demanda de recursos. La inanición es la falla al calendarizar apropiadamente un componente. Si puede ser del todo anticipado, es mejor tener una forma de medir esta contención desde el inicio de tu proyecto. Aún si esta contención no ocurre, es muy útil ser capaz de afirmar eso con confianza.
Fuente:
Cómo Ser Un Programador: Un Resumen
Corto, Comprensivo y Personal
por Robert L. Read
Si quieres conocer otros artículos parecidos a Cómo Comprender Problemas de Desempeño puedes visitar la categoría SISTEMAS OPERATIVOS.
Deja una respuesta