Muchos Mitos

Como comentaba hace un tiempo, estoy trabajando con Sql Server. Eso no solo implica cambiar de motor y olvidar algunas cosas que en Oracle estaban desde la década pasada (me olvidaba de una en el post anterior: poder hacer inserts masivos desde variables en memoria, y poder hacer updates masivos a secas), sino también cambiar de comunidad, leer otros libros, otros blogs, hablar con otra gente.

Además de mi pequeño berrinche por perder algunas features que me han gustado, he notado algo peor: la comunidad de Sql Server es notablemente más pobre que la comunidad de Oracle. Y no lo digo porque no haya personas como Tom Kyte, Craig Shallahamer, Jonathan Lewis o Cary Millsap (porque, por ejemplo, Kalen Delaney evidentemente sabe de que habla), sino porque hay un concepto que en la comunidad de Oracle está bastante claro y que la de Sql Server no parece haber descubierto: la gestión de performance por índices agregados no sirve. Pareciera a veces que a los muchachos de Sql Server les falta leer a Neil Gunther.

Los libros de performance de Sql Server que estoy leyendo insisten, todos, con la vieja y ridícula idea de hacer una linea base de indicadores cuando tu sistema anda bien y luego detectar desvíos sobre esos indicadores, así, de alguna manera, detectarías los problemas de performance antes de que sucedan viendo los síntomas antes de que se manifiesten en el ambiente productivo. Y cuando tenés un desvío, apretás el botón rojo ponés la batiseñal en el cielo y al rato vienen superman y linterna verde (bueno, nadie es perfecto) a rescatarte.

Esta idea tiene varios problemas. Diría que esta idea solo tiene problemas. Y en todos los niveles. Empecemos.

Primero, establecer una linea base de indicadores cuando tu sistema anda bien es una quimera, por varias razones: a veces llegás, como consultor experto en performance, como DBA, como arquitecto, como galeote o lo que fuera a algún lugar donde, si las cosas anduvieron bien, vos jamás las viste. Otras, el sistema cambia lo suficiente como para que la línea base se desactualice antes de que tenga validez estadística (esto implica mayor funcionalidad que implica más carga que requiere una actualización en hardware: o dicho de otra manera, el software cambia). Y a veces (esto es particularmente cierto en las puntocom), no se necesita que cambie el sistema, tan solo cambia el patrón de uso por alguna condición comercial o del entorno.

Otro problema tiene que ver con que el conjunto de indicadores de un sistema corriendo no es un sistema de ecuaciones con solución única. Es decir, que un sistema puede andar bien con varias combinaciones de indicadores. El único indicador razonable para medir la performance es el tiempo de respuesta en relación a la carga de trabajo: si el resto cambia pero mi tiempo de respuesta es razonable, entonces está bien independientemente de lo que diga el hit ratio, la tasa de inserción, la cantidad de log file syncs (o como se llamen en Sql Server) o lo que fuera.

Por último (cerrando los problemas que se me ocurren ahora, no pienso poder abarcarlos todos), muchas veces los indicadores no sirven para nada. El indicador más exitoso en esto de no tener ninguna utilidad práctica es el hit ratio (calculo que porque es el más fácil e intuitivo). Cary Millsap explica por qué el hit ratio no es un buen indicador, demostrando que un hit ratio muy alto puede ser problemático. Particularmente nunca vi un caso así, pero sí vi bases con hit ratios 'bajos' (de alrededor del 70%) que soportaban sistemas que escalaban muy bien y con excelente tiempos de respuesta.

El problema con el hit ratio es el viejo problema de confundir correlación con causalidad. A veces, ciertos problemas que degradan la escalabilidad y los tiempos de respuesta, también bajan el hit ratio, lo que no quiere decir que todos los problemas de performance lo hagan ni que un hit ratio menor al 90% solo pueda ser causado por algún problema. Lo mismo se aplica a cualquier indicador.

Millsap usa el siguiente ejemplo: supongamos dos conjuntos de consultas que obtienen exactamente el mismo conjunto de datos. El primero luego de correr en un sistema tiene un 99% de hit ratio y el segundo un hit ratio de 90%. Es mejor el primero?. Depende: supongamos que el primero hizo 10000 lecturas (entre lógicas y físicas) y el segundo 100. Millsap aclara que "el hecho de que acceder a memoria sea 10000 veces más rápido que acceder a disco no significa que una lectura lógica (resuelta en el caché) sea 10000 veces más rápida que una lectura física (en los datafiles)". Más aún, si tenemos consultas que leen inecesariamente una y otra vez los mismos bloques, el hit ratio será alto.

Por supuesto, mis rápidos comentarios sobre el artículo de Millsap no son excusa para no leerlo. Incluso si no se trabaja con Oracle, los conceptos se aplican a cualquier base de datos.

Resumiendo, los mejores indicadores (debería decir 'únicos indicadores') de la performance de un sistema son sus tiempos de respuesta y su capacidad de escalar, no un hit ratio o una esotérica combinación de indicadores. Ignoro cuanto tiempo tardará la comunidad de Sql Server en darse cuenta de esto. Tal vez cuando tengan que soportar un volumen realmente alto.

Yo no hago eso en público

"Math is like sex. It's something you shouldn't do in public."
--K. Cunningham (estuve toda la semana diciendo que era de Daniel Dennet. Y no se quien es Cunningham)

"Physics is to mathematics as sex is to masturbation"
--R. Feynmann (de esta estoy seguro)


La verdad es que de ambas frases, solo la primera viene a cuento. La segunda la agrego porque me gusta la comparación, y porque me gusta la matemática. Incluso, no veo en la frase ningún contenido peyorativo hacia la matemática: está claro que es la base de la física, y no podés ser un buen físico si no manejás razonablemente bien la matemática. Es decir, la comparación de la frase es perfecta.

Pasada esta pequeña introducción algo adolescente, puedo ir al punto: me encontré estas últimas semanas con un tipo de personaje, simpático si tenemos suerte, insoportable la mayoría de las veces: el matematicofílico. Este curioso personaje no puede dejar de vocear, casi diría de apostar, las complejidades de los algoritmos que ve por ahí. Es capaz de gritar, desde tres escritorios de distancia 'ese algoritmo tiene complejidad (n)* log(n)!!'. Por supuesto, nadie tiene ganas de ponerse a analizar sus afirmaciones.

Me queda claro que nadie determina en cinco segundos la complejidad de un algoritmo, al igual que nadie puede formalizar un problema combinatorio en cinco segundos. No importa, el matematicofílico es capaz de hacer ambas cosas: puede gritar 'eso es una combinatoria sin repetición de 4 en 8!', o puede proferir el grito de guerra del algoritmo que mencionaba antes, y salir de la discusión, contento de haber sido capaz de iluminarnos con su sabiduría, sabiendo que ahora tenemos una luz para guiarnos a hacer software más performante. Gracias totales.

He encontrado más de un tipo de matematicofílico: desde el chanta absoluto (el otro día, mi amigo P. me hacía acordar de A., uno que calificaría de chanta e indeseable) hasta este que inspiró el presente artículo, que cuando programa lo hace bien, que es un tipo que realmente sabe de informática y que ha cursado la mejor carrera de informática que se da por estas pampas.

De todas formas, existe un pequeño detalle: en este caso, el matematicofílico le pone un parche primoroso a algo que son solo harapos. Y pone la energía en el lugar equivocado. Me explico: el software que solemos hacer, sin ser CRUD crudo, se lleva la parte del león del procesamiento en la base de datos. Del tiempo total de las transacciones, un porcentaje abrumador se consume en la base de datos. Más aún, la base de datos (estamos hablando de MS SQL Server, pero lo mismo sería cierto si estuviéramos hablando de Oracle con su maravilloso RAC) es el componente con escalabilidad horizontal más complicada.

El matematicofílico entonces, decía, gasta su energía en optimizar una parte pequeña del problema, mientras descuida las cagadas que hacen los programadores cuando acceden a los datos, él incluido, que es bueno cuando hablamos de generar código.

Ignoro por qué, pero el patrón de pensar la base de datos como una caja negra misteriosa que, no importa lo que hagamos, siempre responderá igual está extendidísimo. Y no hablo de los malos programadores, sino de los buenos. El origen de ese problema?. Ni idea.

Modelos de espera

Por motivos que no vienen al caso, el otro día estaba repasando las herramientas y papers que tengo en mi notebook y que pueden llegar a ser útiles en el trabajo. Pienso que hay una, que he usado en los proyectos de mejora de performance (mi pasión oculta, y algo así como el premio consuelo: puedo jugar a detective sin trabajar para House o sin dedicarme a la investigación) que bien vale un post.

La herramienta es tan simple como una planilla excel que se basa en la idea de que un sistema que atiende transacciones en, en definitiva, un modelo de colas. La idea del modelo de colas es bastante simple:

• Existen una cantidad variable de recursos que atienden peticiones (canales).
  
• Los clientes arriban al sistema y si no hay un recurso que atienda espera poniéndose en una cola.
• Los canales demoran en atender cada cliente un tiempo variable descrito por una función de probabilidad.
• Los clientes arriban al sistema en intervalos variables descriptos por una función de probabilidad
  

Los cálculos que yo conozco se basan en sistemas donde la disciplina de la cola es FIFO, la distribución de los arribos se describe como un proceso Poisson caracterizado por la tasa de clientes arribados sobre unidad de tiempo. Los tiempos de servicio de los canales (lo que tarda cada canal desde que la petición entra el canal, no a la cola, hasta que sale) se describen por medio de una distribución exponencial. Se puede complicar más ( impaciencia de los clientes, otras disciplinas de espera ) pero usualmente el modelo básico es suficiente para analizar un software up&running.

Prácticamente, no me he encontrado con un sistema que no pueda ser modelado como un sistema de colas:

• Un sistema web recibe peticiones (los GET y POST HTTP) que son atendidas por threads que corren en el application server. Los threads son los canales de atención y si no hay un thread disponible, la petición espera.

• Un proceso batch procesa peticiones (transacciones) que esperan en cola hasta que el proceso puede atender a la próxima.

• Una base de datos que recibe DML es tiene una serie de procesos que atienden las peticiones

Encuentro particularmente útil el modelo de colas no para reemplazar al test de stress de un sistema, sino para complementarlo. Así, luego de terminar el test de stress o de mirar en producción un rato puedo contestar fácilmente preguntas del tipo:

• Que sucedería si mi sistema recibe el doble de peticiones y hago un esfuerzo (en rediseño) para que el tiempo de servicio no aumente más del 10%?

• Si espero un determinado incremento en la carga de transacciones, cual debería ser mi optimización del tiempo de servicio para obtener un determinado tiempo libre del canal (para tareas administrativas, por ejemplo).

Craig Shallahamer tiene un excel de un modelo de colas en su web (en el link hasta que Craig decida rediseñar su página). Es una modesta maravilla que en la primer solapa requiere la introducción de los valores característicos y en las siguientes muestra la evolución del sistema con variaciones de los valores característicos.

Así que la próxima vez que un cliente, con cara de ‘ahá, acá te cagué, consultor’ pregunte: 'y de donde sacaste que si la carga de transacciones aumenta un 20% me quedo sin tiempo para el backup', uno puede sacar las planillas y agobiarlo con una clase de investigación operativa ligera.

Y como bien saben los economistas, mostrar números y matemática razonablemente avanzada da un aura de respetabilidad. Aunque todo esté construido sobre nada. En realidad, el modelo de colas sí funciona para el análisis de performance de los sistemas informáticos, simplemente tenía ganas de hablar mal de los economistas. Porque (y con el solo objeto de divertirse un rato con una buena lectura y sin que tenga relación con el post) como bien señala Leonardo Moledo, con la economía es otra historia.