Más allá del perfilado

1. Introducción

Antes de rediseñar toda la solución, todavía hay muchos puntos en los que podemos mejorar en PROFI sin cambiar fundamentalmente su comportamiento.

En el capítulo anterior, nos hemos centrado en mostrar los errores tradicionales que causan problemas de rendimiento, exclusivamente en la parte de la API. Se trataba de demostrar que la falta de rendimiento no siempre (ni mucho menos) requiere de mucha experiencia para encontrar una solución, sino que a menudo proviene de una docena de casos de programación relativamente bien identificados.

Existen muchos otros casos que, si bien no están relacionados con el tuning, siguen siendo errores de programación que se sabe que dificultan el rendimiento, pero que no son lo suficientemente frecuentes como para justificar un capítulo específico. El objetivo aquí no es ser exhaustivo, sino presentar algunos casos concretos, para mejorar la comprensión del problema por parte del lector.

El objetivo de este capítulo es también proponer algunos métodos sencillos para mejorar el rendimiento de una aplicación, sin que se corresponda necesariamente con la corrección de un error de código, pero sin que pueda hablarse tampoco de puesta a punto, dada la sencillez de las soluciones propuestas.

El autor ya no propondrá necesariamente métodos detallados, sino a veces simples comentarios sobre tecnologías concretas, combinados con consejos sobre cómo utilizarlas (o incluso abandonarlas).

2. Mejorar la experiencia

Rendimiento real y percibido

Los desarrolladores pueden tener una evaluación positiva del rendimiento de su código, respaldada por un benchmark, mientras que el cliente usuario considera que la aplicación es lenta. Detrás de esta realidad, en primer lugar puede ser que el desarrollador esté trabajando en una máquina potente y, por tanto, solo tenga en cuenta su propia percepción del rendimiento, basada en su hardware.

También puede ocurrir que la forma de cronometrar una característica, incluso cuando se ve desde el lado del cliente, no sea la misma entre un desarrollador y un usuario. Un desarrollador tendrá tendencia a añadir un temporizador al código y a confiar en ese valor, sin darse cuenta de un problema potencial si la lentitud...

1. Cuidado

¿Qué podemos hacer cuando hemos pasado por todos los puntos "clásicos" explicados en este libro y seguimos teniendo problemas de rendimiento con nuestra aplicación objetivo? Entonces es el momento de pasar a la segunda fase, llamada puesta a punto (tuning), donde ajustaremos todos los parámetros a nuestra disposición, identificaremos los cuellos de botella del sistema y ahorraremos el último porcentaje de tiempo a costa de un gran esfuerzo. De esta fase proviene la reputación de complejidad de la optimización del rendimiento, ya que a menudo se subestima la primera fase de la que hemos hablado a lo largo de este libro. En la inmensa mayoría de los casos, sencillamente no será necesario pasar por esta etapa de puesta a punto porque simplemente corrigiendo las partes incorrectas del código habrá mejorado el rendimiento lo suficiente.

Lo hemos repetido ampliamente a lo largo del libro: no se trata de que el autor se dedique a hacer tuning y recomendaciones de rendimiento que solo tendrían sentido en un contexto concreto. A lo largo de los capítulos anteriores, hemos examinado los errores «tradicionales» que son comunes en las aplicaciones y que reducen en gran medida el rendimiento.

En la introducción, presentamos las tres fases de la mejora del rendimiento de una aplicación.

Dado que el perfilado ha sido el tema de la mayoría de los capítulos anteriores, hablaremos brevemente de la puesta a punto. No se trata de una sección de tuning porque el resto del libro explica que, en el 99 % de los casos, existen formas mucho más sencillas y seguras de mejorar el rendimiento de una aplicación. A lo sumo, ofreceremos algunas sugerencias y remitiremos al lector a un análisis más profundo de estos puntos, si alguna vez necesita ponerlos en práctica. La literatura sobre el ajuste del rendimiento es, por desgracia, abundante. El adverbio «por desgracia» se justifica por las siguientes dos razones:

1. Problemática

En la sección anterior hemos hablado del tuning, explicando que esta fase seguía al perfilado en caso de que éste no alcanzara los objetivos de rendimiento fijados. Por experiencia, el autor puede asegurar que en las aplicaciones no críticas este es raramente el caso.

Pero si tenemos que pasar por esta segunda fase, y estamos absolutamente seguros de que el perfilado ya no nos muestra ningún caso estándar, que es simplemente la complejidad inherente de la aplicación lo que la hace lenta, ¿cómo no perder el tiempo con un tuning fino, que funcionará en un sistema, pero no en otro que apenas es diferente, y por tanto poco explotable y rentable? Sobre todo, una vez realizada esta fase de puesta a punto, ¿qué se puede hacer si todavía no se consigue el rendimiento deseado?

Entonces es el momento de pasar a la siguiente fase, que consiste en completar la fase de arquitectura inicial volviendo a los fundamentos de la aplicación y repensándola en profundidad. ¿Está nuestra base de datos limitando nuestra escalabilidad? En determinadas condiciones, las bases de datos pueden colocarse en la memoria RAM, con una excelente ganancia de rendimiento. Otra alternativa sería colocar una caché de tipo Redis entre la base de datos y la aplicación, para que los datos a los que se accede con frecuencia estén disponibles directamente. Sin embargo, como con cualquier uso de la tecnología de almacenamiento en caché, hay que prestar especial atención a la invalidación de los datos para que la consulta siempre devuelva valores relevantes desde el punto de vista del negocio. Las arquitecturas sencillas e innovadoras pueden incluso permitirnos prescindir por completo de una base de datos y, sin embargo, conservar la mayor parte de la funcionalidad asociada a ella.

2. Escalabilidad