Cacheitis: otra enfermedad común del desarrollo software

Hoy hablamos de otra enfermedad habitual en el mundo del desarrollo software. Relacionada con las enfermedades "arquitectónicas", está especialmente relacionado con desvaríos de los arquitectos de software a la hora de implantar soluciones que por su ineficiente diseño, producen un mal rendimiento. Entonces la definición de Cacheitis vendría a ser algo así: "desorden transitorio del arquitecto o diseñador de software por el cual el uso inadecuado de la caché provoca como resultado una solución ineficiente".

¿Y cuál es la primera solución que se les ocurre? Sí señoooor: más caché. Caché por todos lados. Vamos a cachear todo lo cacheable.

En otras ocasiones, es al reves. Se parte con un exceso de caché desde el inicio del diseño, y esto deriva en un mal rendimiento. Para solucionarlo: como no...más caché.

Rodrigo corral en su blog ya hablaba de este problema, y aporta algunas buenas prácticas:

• Asume que no puedes cachearlo todo. Esto es viejísimo: ya es harto conocido por ejemplo, que en el mundo de las bases de datos es absurdo tratar de indexar todo en la búsqueda del rendimiento. Pues esa mala práctica, la cacheitis la extiende al uso de la cache.
• El cacheo temprano no es bueno. A menudo cuando diseñamos una arquitectura establecemos mecanismos de cacheo que luego son utilizados hasta el abuso. El peligro subyacente al cacheo temprano es que comencemos a cachear sistemáticamente elementos que nos parecen costosos sin tener evidencia de que realmente son los mejores candidatos para su cacheo. De nuevo, podemos establecer la comparación con el uso excesivo de índices en las bases de datos.
• Tener en cuenta las otras cachés. Hay que recordar que existen muchos niveles de caché. El motor de base de datos, el servidor web, ADO.Net, etc, etc.
• Una colección estática o global no es una caché: los desarrolladores noveles, y a veces los no tan noveles, utilizan datos estáticos o globales para simular el uso de la caché. Por desgracia, esto es una burda imitación de las múltiples características que deben incluirse en un mecanismo de caché como: acceso frecuente a los datos, políticas de refresco e invalidación, liberación de recursos de uso infrecuente, etc.

¿Qué es lo que hay que hacer? Pues recordar que somos ingenieros, y tratar de aplicar el sentido común (por desgracia, no el más común de los sentidos hoy día). Para ello, hay que relajar el usar la caché en las etapas tempranas del proyecto, y dejar para las etapas de optimización un uso combinado e inteligente de:

• Optimización mediante caché
• Optimización del acceso a datos mediante índices, su propia caché, vistas, datos calculados, etc.
• Minimizar los accesos a servicios web, WCF, y a otras capas de la aplicación, de forma que las operaciones no hagan "excesivos viajes" para obtener la misma información.

De hecho, al final, no es sino hacer uso de los más básicos principios ágiles: simplicidad desde el diseño.