Cada empresa, por pequeña que fuese, disponía de su propia infraestructura, máquinas, comunicaciones, almacenamiento, backup, etc. Miles de de micro-CPDs aparecieron como setas por todos lados. Una empresa mas o menos grande disponía de varios, por no decir decenas, de estos micro-CPDs, era una época en la que Internet movía mucho dinero y esto se traducía en un aumento notable en la inversión en IT, eran los felices años de “las vacas gordas”.

¿ Por qué hablo de todo esto ? Porque muchas veces solemos perder la perspectiva temporal del entorno en el que trabajamos y especialmente en el mundo IT, la llegada de nuevos paradigmas son acogidos como verdaderos salvadores, cuando sencillamente, en la mayoría de los casos es el reflujo de algo con lo que ya se trabajaba antes, pero con otra denominación y algunas características realmente innovadora. La informática nació en entornos concentrados, grandes máquinas destinadas para cálculos que requerían mucho tiempo de procesamiento y que trabajaban con colas de ejecución, donde tenías que solicitar un tiempo de CPU para ejecutar tus programas. Posteriormente, se produjo una evolución, al aparecer los primeros PCs, donde cada usuario podía disponer de su propio ordenador. Con la llegada de los PCs los usuarios no necesitaban acceder a máquinas grandes y costosas para realizar sencillas tareas como editar un fichero de texto, ahora cada usuario disponía de su propio ordenador personal donde ejecutar sus programas y almacenar su información, y no debía compartir con otros usuarios el tiempo de CPU. Este nuevo modelo también sirvió para desarrollar las redes de comunicaciones que se empleaban para interconectar PCs y permitir a los usuarios poder trabajar con información que no estuviera almacenada en su PC.

Después de un periodo de expansión, irremediablemente viene otro de contracción, como bien sabemos por los efectos en la economía. Podemos asegurar que el periodo de expansión ya ha terminado por lo que actualmente nos vemos inmersos en una etapa durante la cual veremos como se desarrolla una tendencia para volver a concentración de la tecnología IT, argumentando un mejor aprovechamiento de los recursos gracias a las sinergias, ahorrar costes y hacer mas accesible las distintas tecnología de la información a las empresas y los usuarios finales.

Desde el punto de vista IT, estamos saliendo de una etapa donde se ha producido una dispersión geográfica de la información, cualquier empresa o usuario disponía de capacidad para la creación y almacenamiento de la información, esto ha supuesto que la información de una compañía, por ejemplo, aunque pensemos lo contrario, se encuentre dispersada por centenares de sitios, desde PCs de usuarios a bases de datos en servidores y ahora nos estamos dando cuenta del coste real de mantener toda esta información y sobre todo qué información de toda la que maneja una organización es realmente útil para el desarrollo del negocio. Un ejemplo, ¿cuanto espacio de almacenamiento de una empresa contiene información personal de los empleados? ¿cuanto cuesta el mantenimiento anual de toda esta información? ¿cuanto ocupa el backup de toda esta información?, en la actual época de recortes en los presupuestos, tener que destinar dinero de un departamento de IT para gestionar información que no está directa o indirectamente relacionada con el negocio de nuestra organización se ha convertido en un despilfarro. Hemos puesto el ejemplo del almacenamiento, pero otro tanto ocurre con las licencias de software o las infraestructuras para maquetas o pruebas, son casos en los que el gasto IT se dispara

La mayor parte de mi vida profesional ha estado ligada a la administración de sistemas y por lo tanto he tenido que estar muchas horas en los CPDs y una cosa que desde el principio siempre me llamó la atención fue ver el derroche tan enorme de recursos que suponía el modelo de granjas de servidores. En cualquiera de los CPDs en los que he trabajado existían filas y filas de racks llenos de máquinas, los cuales solían estar muy por debajo de sus posibilidades, si lo pensamos un momento hablamos de miles de billones de ciclos de CPU desperdiciados, miles de millones de vatios consumidos únicamente para ejecutar operaciones NOP en los procesadores. Desde la perspectiva actual donde tecnologías como la virtualización se están imponiendo, pensar en miles de máquinas empleando un 10% de su CPU suena sencillamente absurdo. Todos los fabricantes disponen de alguna herramienta de virtualización, las cuales nos venden anunciando las ventajas de utilizar de forma inteligente todos los recursos de los que disponemos.

Sin analizar la situación económica con la que se desarrolló el modelo de granja, que lo justifica por si mismo, sino analizando el aspecto puramente técnico, siempre he pensado que las granjas de servidores era un derroche de tecnología, de recursos que no estaban siendo utilizados, pero que ocupaban espacio físico, consumían potencia y generaban calor, es decir, había máquinas las cuales estaban consumiendo energía, con ventiladores funcionado para enfriar un hardware que realmente no estaba siendo utilizado, cualquiera que haya trabajado con granjas de servidores sabe de qué estoy hablando y mi sensación al entrar en un CPDs era que en vez de granjas de servidores para dar servicios a aplicaciones, lo que había eran granjas de ventiladores para mover aire en los CPDs.

¿Sorprendente verdad? da un poco de escalofríos que en plena crisis económica pensemos cuanto dinero de IT se ha tirado por la alcantarilla, pero eran otros tiempos y no debemos perder la perspectiva económica de esos tiempos, ahora es fácil criticar las decisiones que tomamos en el pasado, pero la realidad es que las granjas fue un modelo barato que permitió el avance de la tecnología relacionada con IT, al abrir la caja de Pandora que estaba controlada por una serie de fabricantes. Ahora, la situación económica ha cambiado y el mercado obliga a las áreas IT a la reducción de costes, lo que significa sencillamente menos inversiones. Los fabricantes producen máquinas con menos consumo y mas capacidad de computo y reaparece en escena una tecnología como es la virtualización. Ahora a todo el mundo se le llena la boca de las bondades de virtualizar para aprovechar los ciclos de CPU, permitiendo que varios usuarios trabajen sobre la misma máquina, aprovechando todo lo posible los recursos disponibles de una máquina. Y por si fuera poco, aparece el concepto de Cloud Computing como paradigma redentor de los problemas de las áreas de IT y solución perfecta para la reducción de costes.

¿ Qué es Cloud Computing ?

No existe una definición unificada del concepto Cloud Computing, esta falta de acuerdo en la definición provoca que bajo el paraguas de este término se acomoden todo tipo de tecnologías e  implementaciones, generando un gran desconcierto para la gente de IT, a la que se le piden soluciones de este tipo y sobre todo para la gente de Negocio, que ven en este nuevo paradigma la solución para muchos de los problemas actuales que las organizaciones tienen en las áreas de IT.

Podemos decir que Cloud Computing consiste en una serie de servicios los cuales se ofrecen a los usuario  y la infraestructura IT sobre los que se soportan son mas o menos transparentes para ellos. Desde el punto de vista del usuario estos servicios se encuentran en la nube (Cloud), para el usuario la nube consiste en la red, en muchos gráficos donde se representan equipos interconectados se utiliza una nube para representar esa parte de la infraestructura de la que no tenemos conocimiento y que realmente no es imprescindible conocer su constitución para que nuestro esquema tenga sentido. Por lo tanto la nube es la infraestructura de la que no deseamos tener conocimiento, únicamente la vamos a utilizar sin tener la necesidad de preocuparnos por sus problemas o limitaciones.

El concepto de Cloud Computing, es bastante genérico y no existe un estándar que se pueda seguir, por lo que los distintos fabricantes aplican este término a tecnologías que a veces, no tienen mucho que ver entre ellas, sencillamente se ha dado el pistoletazo de salida para vender un nuevo concepto y en esta carrera todo vale, cualquier cosa hoy día es Cloud. Pero sin entrar en temas concretos sobre lo que los fabricantes quieren que compremos, podemos analizar el termino Cloud Computing desde una perspectiva en la que se engloba, de forma totalmente general y abierta, una serie de tecnologías y buenas practicas. Existen una serie de características que una solución Cloud debería cumplir, pero no es estrictamente obligatorio que las cumpla todas:

• Deslocalizacion de la plataforma IT. La infraestructura IT necesaria para que el servicio funcione, no necesita estar en las instalaciones del cliente. El cliente sencillamente utiliza un servicio que está sobre una infraestructura que puede localizarse en cualquier parte del globo y de la que no necesita conocer nada.
• Elasticidad de los recursos. El cliente no debe preocuparse por la capacidad de los recursos asignados al servicio que ha contratado, ya que en caso de que fuese necesario emplear mas recursos para un servicio, debido a un pico de trabajo por ejemplo, sencillamente se asignan nuevos recursos sin necesidad de parar el servicio, permitiendo de forma mas o menos dinámica  redimensionar los recursos que utiliza el servicio, una vez que las necesidades de recursos disminuyan, se podrían liberar los recursos no utilizados.
• Auto-Billing. La facturación se realizará de forma automática sin tener que renegociar las condiciones del servicio, el modelo es el mismo que el empleado en la facturación telefónica, se cobra por lo consumido.
• Virtualizacion. La virtualización es una tecnología imprescindible para desarrollar un servicio Cloud, ya que permite aprovechar de forma mas eficiente los recursos IT disponibles, balanceando dichos recursos entre distintos servicios si fuese necesario y sin la necesidad de parar el servicio.
• Aceso universal. Al estar el servicio en la nube, el acceso a dicho servicio es universal ya que se debería poder acceder desde cualquier punto del planeta, ayudando de esta forma a la integración de aplicaciones en entornos corporativos distribuido en distintas localizaciones.
• Gestion simplificada. La gestión por parte del cliente del servicio debería ser mediante una serie de procedimientos y aplicaciones sencillas que faciliten el trabajo de provisión, incidencias, cobros, etc. De los servicios contratados, así como seguimiento de los niveles de servicios acordados.
• Reducción de los costes. Normalmente las infraestructuras que soportan servicios Cloud son utilizadas por varios clientes, lo que permite reducir los costes de inversión y mantenimiento de la misma, trasladando estos ahorros a los costes que el cliente tiene al contratar el servicio.
• Gestion del acceso a la información. La plataforma cloud suele ser compartida por varias empresas, por lo que se necesita una gestión eficaz de acceso a la información que garantice que otra empresa no puede acceder a mis datos.

Tipos de Servicios

Cuando hablamos de servicios en la nube, encontramos tres tipos básicos de servicios, cada uno de ellos dispone de un ámbito y características determinadas y se ajusta a una serie de necesidades, por lo que somos nosotros como clientes, los que debemos decidir qué modelo elegir, según las necesidades de nuestra organización.

IaaS – Infraestructura como un Servicio

El modelo de Infraestructura como un Servicio consiste en disponer de elementos de infraestructura IT, como son máquinas, SO, almacenamiento, elementos de comunicaciones, etc. Para utilizarlos, bien como parte de nuestra propia infraestructura, bien como elementos sobre los que implementar nuestro negocio.

Un ejemplo de IaaS sería contratar máquinas virtuales con una cantidad de memoria y un número de CPUs, además de un sistema operativo que sería administrado por nosotros. Otro ejemplo de IaaS sería acceder a espacio de almacenamiento para que nuestra organización pueda almacenar los datos y que sean accesibles desde cualquier punto del globo.

PaaS -  Plataforma como un Servicio

La Plataforma como un Servicio consiste en disponer de una plataforma sobre la que se desarrolla una serie de aplicaciones que serán la base de la implementación de nuestro negocio. Se trata de un servicio compuesto por herramientas de desarrollo y gestión de datos, con las que podemos desarrollar aplicaciones. Los servicios PaaS normalmente dan acceso a una serie de APIs sobre los que se puede desarrollar para posteriormente utilizar las aplicaciones en la infraestructura que el proveedor posee en la nube.

Un ejemplo de PaaS sería una plataforma sobre la que varios equipos de nuestra organización, localizados en distintos países desarrollan una aplicación que se utilizará internamente en nuestra organización.

SaaS -  Software como un Servicio

El último modelo de servicio en la nube es el Software como un Servicio, en este modelo se ofrece un servicio para que sea utilizado directamente por los usuarios, sin necesidad de que el cliente tenga que realizar desarrollos o integrar infraestructuras en la nube. En el modelo SaaS el cliente contrata la utilización de un software y paga por su uso.
Un ejemplo de SaaS sería contratar un servicio en la nube para que nuestra organización gestione la formación de los empleados, mediante un a plataforma de formación en la nube.

Cloud Computing para Usuarios

Desde el punto de vista de un usuario que contrata un servicio alojado en la nube, existen una serie de ventajas y desventajas que debemos conocer antes de migrar algún servicio de nuestra organización a la nube.

Entra las ventajas podemos citar:

• Solo se paga por lo que se usa, esta característica genera un ahorro directo, ya que con el modelo de nube, no hay que repercutir conceptos como los costes de mantenimientos de software y hardware o las inversiones para la ampliación de infraestructuras en caso de que nuestro negocio necesite crecer, solo debemos pagar por los recursos consumidos en la nube.
• Se reducen los tiempos de desarrollo del Negocio. Cuando nos planteamos utilizar un servicio en la nube solo debemos contratar el servicio con unos requerimiento mínimos para que pueda sostener la implementación del negocio que vamos a realizar y pagaremos mas cuando el servicio comience a ser utilizado. Montar maquetas es un proceso sencillo y barato ya que no necesitamos realizar una inversión en infraestructura IT, únicamente contratamos un servicio en la nube, creamos una maqueta y comprobamos si es viable la implementación del negocio, una vez terminada la prueba podemos o bien terminar el contrato del servicio o reducir los recursos contratados para de esta forma reducir el coste del servicio contratado.
• Se reducen los problemas derivados de una plataforma IT. El usuario no debe preocuparse por problemas como la escalabilidad o las copias de respaldo, la nube se encarga de todo, por lo que la organización no tiene que emplear ni tiempo ni recursos en mantener una infraestructura para el Negocio. La organización se puede concentrar en el desarrollo del Negocio.

Como desventajas podemos citar:

• No controlar la localización de los datos. Un servicio en la nube puede almacenar los datos en distintas localizaciones y el usuario del servicio no tiene control sobre donde están sus datos. Esta falta de control puede suponer un problema dependiendo del carácter de los datos y la legislación de cada país. Por ejemplo, existen verdaderos problemas para poner datos médicos sobre pacientes en la nube o datos de organizaciones gubernamentales que sean catalogados como clasificados, ya que las leyes de cada país con respecto a este tipo de datos son muy estrictas.
• El usuario debe preocuparse por los SLA (acuerdos de niveles de servicio). La única herramienta que el usuario posee para garantizar el servicio que está contratando son los acuerdos de niveles de servicio (SLA), con lo que se medirá la calidad del servicio.
• Inversión en comunicaciones. Otra de las desventajas de utilizar servicios en la nube es que las comunicaciones con la nube deben ser lo suficientemente fiables como para garantizar el acceso a los servicios contratados. Además de la disponibilidad también debemos asegurarnos que el caudal que tenemos de acceso a los servicios en la nube garantizan que el acceso al servicio tiene la calidad necesaria para el desarrollo del Negocio. Las comunicaciones externas son sensiblemente mas caras que las comunicaciones internas. Al tener servicios en la nube nuestra organización podría tener que aumentar los caudales de acceso a la nube con el consiguiente gasto.
• Nuestra información “podría” ser accedida por terceros. La gestión del acceso a nuestra información  la hemos delegado a un proveedor de servicios en la nube, un problema de seguridad en dicho proveedor puede provocar que los datos alojados en la infraestructura del proveedor pudieran ser accesibles por otras personas. Nosotros como usuarios debemos ser conscientes de este riesgo y lo que supondría que terceros tuvieran acceso a nuestra información.
• Cuidado con los PaaS. Al desarrollar aplicaciones en Plataformas como un Servicio podemos encontrar el problema de la migración, tanto de los datos, como del código a otro proveedor. Muchos proveedores de PaaS ofrecen plataformas propias de desarrollo de aplicaciones por lo que todo lo que desarrollemos en esta plataformas, muy rara veces podremos migrarlo a otras.
• Los recursos no son infinitos. Una de las características de los servicios en la nube es la elasticidad de los recursos, el proveedor nos dará recursos según nuestras necesidades, pero debemos ser conservadores con esta idea, ya que un proveedor de servicios no puede darnos recursos ilimitados y podemos encontrar situaciones donde nuestras necesidades de negocio requieran mas recursos y el proveedor no puede suministrarnos lo que necesitamos, quedando atrapados en un servicio que nos costará mucho esfuerzo migrar a otro proveedor.

Hemos citado ventajas y desventajas que los servicios en la nube pueden presentar para nosotros como usuarios que contratamos un servicio. No todos los servicios presentan todas las ventajas y desventajas, pero debemos recordar que los proveedores de servicios los ofrecen en unas condiciones concretas y que fuera de esa condiciones, todo lo que no esté reflejado en los acuerdos de nivel de servicio, el proveedor no estará obligado a cumplirlo, por lo tanto el utilizar servicios en la nube requiere un esfuerzo a la hora de entender perfectamente qué se está contratando y las características del servicio que se contrata, así como dejar muy claro cuales serán los SLAs que se firmarán.

Conclusión

Tecnológicamente la nube es una idea madura, ya existe la tecnología necesaria para que funcione y de hecho ya está funcionando, pero existe un elemento fundamental para su éxito que es la confianza que debe existir entre el cliente y el proveedor del servicio y es en este elemento, la confianza, en la que los proveedores deberán de trabajar en los próximos años para que los clientes vean que utilizar los servicios en la nube es una ventaja y no un inconveniente. Por lo tanto, mas allá de los ahorros de costes, tiempos de disponibilidad,  tipos de acceso o localización de los servicios, debemos preguntarnos como clientes, qué confianza tengo en el proveedor del servicio que estoy contratando, realmente ¿estoy seguro de que mis datos están en buenas manos? ¿cómo encajan los nuevos servicios en la nube con mis planes de contingencia? ¿quién puede acceder a mis datos? Si necesito crecer, ¿el servicio estará preparado? Estas cuestiones son un ejemplo de algunas de las preguntas que nos tendremos que hacer cuando nos planteamos migrar un servicio a la nube y la única respuesta posible es la  confianza que tengamos en el proveedor del servicio. Por lo tanto creo que la confianza entre proveedor y cliente es uno de los pilares fundamentales de la nube.

Pero algo del libro que me llamó la atención fue la razón del título de “Arquitecto o Abeja?“, se debe a una referencia al libro de Karl Marx El Capital:

“…la abeja avergüenza con la construcción de sus celdas a mas de un arquitecto. Pero lo que diferencia al peor de los arquitectos de la mejor de las abejas, es que éste ha creado la celda en su cabeza antes de comenzar a construirla…”

Es decir, realmente lo importante no es construir algo, sino el proceso creativo que culmina con la creación del método para construir algo. Y esta diferencia es la que Mike Cooley subraya en su libro, intentando trasmitir la idea de que los sistemas no se deben construir sin contar con las personas, es decir que el sistema que se construye tenga como referencia central al ser humano y no al contrario. El libro no deja de ser una crítica a un  posible futuro desde la perspectiva de 1980 y como tal hay que leerlo, además también hay que ser críticos con los críticos, por lo tanto no digo que el libro sea una piedra de Rosetta para entender la actual relación entre el hombre y la tecnología, ni siquiera para justificar nada de lo que está pasando en el mundo IT actualmente, pero si hay un tema que me hizo reflexionar y es el papel que jugamos las personas que trabajamos en ciertas áreas IT, en mi caso los Sistemas, en el actual marco económico y tecnológico, y hacia donde está derivando la situación actual, producto de una época de crecimiento y que en estos momentos necesita un reajuste para soportar la actual situación de crisis.

El mundo IT, ha vivido una época de bonanza económica lo que provocó que las compañías invirtieran mucho dinero y recursos en las áreas de Sistemas, otras áreas como la de Desarrollo también han crecido de forma considerable pero no de la forma que lo han hecho las de Sistemas. Al fin y al cabo debemos tener en cuenta que la gente de Desarrollo trabaja con elementos abstractos que para la gente no técnica son difíciles de cuantificar y en una sociedad de consumo como la nuestra, si no lo puedes medir y pesar, es difícil ponerle un precio. Por contra, las áreas de Sistemas trabajan con la parte física de los Sistemas de Información, máquinas, redes, discos, tarjetas, racks, CPDs, etc. Esta diferencia entre los elementos abstractos y los materiales ha provocado, que en la mayoría de los casos, los presupuestos para IT se hayan destinado en su mayoría para las áreas de Sistemas

Siempre he sido bastante crítico con el papel que la gente de Sistemas ha jugado dentro de las empresas, siempre he tenido la sensación que la gente de negocio nos ha visto a la gente de Sistemas como los tipos que trabajan con esas máquinas tan caras en las que se va todo el presupuesto. Las empresas han caído en la trampa de pensar que si es caro es bueno o por lo menos importante, por lo tanto la gente que trabajan con esas máquinas, son gente importante para la compañía y bajo ese canto de sirenas, las áreas de Sistemas hemos caído en el aletargamiento de creernos indispensables. Pensando que somos el centro de masa sobre el que orbitan todos los demás asuntos de la organización y no entendiendo que, si bien somos parte importante de la organización no somos la razón de ser de la misma, somos las herramientas físicas sobre las que se implementa un negocio.

Con el boom de las “Punto Com” las áreas de Sistemas crecieron de forma extraordinaria, en la actual situación, donde la economía está en un proceso de contracción, hay menos presupuesto para infraestructuras, las áreas financieras están exigiendo que se gaste menos y por lo tanto las áreas de Sistemas deben solucionar los problemas derivados de esta disminución de presupuesto. Hemos pasado de un periodo donde sencillamente se compraba a otro donde hay que plantear soluciones ingeniosas que acompañen al negocio, no que supongan un lastre y este objetivo es el que se deben marcar las áreas de Sistemas, dar soluciones creativas, aprovechando al máximo los recursos disponibles.

Hasta ahora en las áreas de IT un modelo muy extendido era el de la externalización de recursos y servicios, esta externalización afectaba principalmente a las áreas de desarrollo e implantación de proyectos, pero ahora ha entrado en escena un nuevo modelos de negocio para los proveedores de servicios, el  Cloud Computing que permiten la externalización de los servicios IT, como las infraestructura (IaaS), los entornos de desarrollo (PaaS) y los servicios (SaaS). En un mundo interconectado, donde la globalización de las comunicaciones permite estar conectado a cualquier parte del mundo, comienza a dejar de tener sentido que la plataforma IT que necesita nuestra organización tenga que ser propiedad de la compañía.

Con este escenario de contracción económica y reducción de los presupuestos las áreas de Sistemas vamos a tener que reinventarnos y demostrar a las compañías que podemos dar valor añadido, mas allá de administrar el almacenamiento, los Sistemas Operativos y las Comunicaciones. Por lo tanto creo que ahora es el momento en el que Sistemas debemos comenzar a pensar si queremos ser Arquitectos o Abejas porque nos enfrentamos a un panorama incierto, pero creo que todo aquel que decida ser Arquitecto, se plantee la actual situación, no como una época problemática sino como un periodo de cambios, en el que tenemos la oportunidad de adaptarnos a las nuevas circunstancias, no tendrá problemas. Pienso que los problemas los tendrán todos lo que que en sistemas decidan seguir siendo Abejas.

¿Cómo veo yo el futuro?

Se avecina un periodo de cambios, donde se produciran una serie de transformaciones mas o menos críticas sobre la forma en la que las áreas de Sistemas intervienen en el desarrollo del negocio de las compañías.

• Las empresas van a reducir sus presupuestos de las áreas de Sistemas, reduciendo las inversiones, pero exigiendo que se mantengan los actuales niveles de servicio, por lo tanto habrá que hacer más con menos recursos.
• Se buscaran nuevas fórmulas de externalización de los servicios, como la adopción del Cloud Computing, para reducir los costes y aprovechar las ventajas que nos ofrecen, sobre todo durante el periodo de desarrollo del Negocio.
• Disminuirá el tamaño de las áreas de Sistema, con el propósito de crear equipos más dinámicos, con gente que entienda las necesidades de la organización y esté realmente alineado con el Negocio, aportando una perspectiva de las oportunidades que la tenología ofrece a nuestra compañía para el desarrollo del Negocio.
• Las áreas de Sistemas tendrán que gestionar los recursos que la organización haya externalizado, por lo que se requerirá mas trabajo de gestión.
• La tecnología volverá a concentrarse para ahorrar con las sinergias.
• Las compañías comenzaran a delegar la explotación de los Sistemas a empresas como IBM o HP, las cuales pueden dar una respuesta global a las necesidades de cualquier compañía.

Creo que frente a situaciones como las que se avecinan para la gente de Sistemas un cambio de actitud es fundamental, no ver el cambio como un problema, sino como una oportunidad y en este hecho radicará el poder seguir trabajando con lo que realmente nos apasiona, que son los Sistemas, por lo menos a mi :)

Entre las características principales de IllumOS están:

• No se creará una distribución
• Se reemplazará todo el código cerrado que aún se mantiene en OpenSolaris.
• Se mantendrá la compatibilidad 100% con el código de Opensolaris.

En resumen a parte de todas las cuestiones rumorológicas del asunto Oracle+Opensolaris, el nacimiento del proyecto IllumOS es el ejemplo de la razón de existir del Código Abierto, que no importan los problemas, sencillamente se puede seguir avanzando, avanzando y avanzando.

Para mas información este post de Miguel Vidal y el blog de Iban Nieto

Una de las diferencias principales entre una máquinas y un ser humano es la subjetividad con la que una persona experimenta una situación y esta diferencia para una plataforma IT se puede convertir en un problema que debemos tener en cuenta, ya que no todas las personas, aun obteniendo los mismo resultados, experimentarán de la misma forma el uso que hacen de la plataforma. Cuando una persona interactua con un sistema de información, realiza dos acciones básicas, independientemente de la complejidad de las operaciones:

• Introducir información en el sistema.
• Obtener una respuesta satisfactoria del sistema.

Es importante entender que el usuario espera una respuesta satisfactoria y este es uno de los trucos que utilizan algunas aplicaciones muy conocidas. El tiempo que trascurren entre que el usuario finaliza la introducción de la información en el sistema, hasta que obtiene una respuesta, es el tiempo de espera. Dependiendo de la duración del tiempo de espera la satisfacción del usuario puede ser mayor o menor, además la subjetividad del ser humano impide que podamos obtener una relación directa entre tiempo de espera y satisfacción, no todos los seres humanos perciben las situaciones de la misma manera, por lo que el problema de cubrir las expectativas de los usuarios del sistemas frente a los tiempos de respuesta es un problema crítico para las organizaciones, ya que usuarios insatisfechos pueden convertirse en usuario que el negocio pierde.

Debemos entender que Rendimiento no significa Velocidad, de hecho según la Real Academia Española, el significado del término rendimiento es:

Rendimiento.

• 1. m. Producto o utilidad que rinde o da alguien o algo.
• 2. m. Proporción entre el producto o el resultado obtenido y los medios utilizados.
• 3. m. cansancio (‖ falta de fuerzas).
• 4. m. Sumisión, subordinación, humildad.
• 5. m. Obsequiosa expresión de la sujeción a la voluntad de otro en orden a servirle o complacerle.

Podemos comprobar que ninguna de las definiciones habla de velocidad, de hecho la que mejor se ajusta para un entorno IT es:

“Proporción entre el producto o el resultado obtenido y los medios utilizados.”

En este punto, hemos hablado sobre el concepto de Rendimiento y sobre  la Satisfacción de los usuario, pero no hemos comentado nada sobre la relación que existe entre estos dos términos. No existe una relación directa entre Rendimiento y Satisfacción, ya que podemos tener una plataforma con un rendimiento inmejorable pero cuyos usuarios tengan un grado de insatisfacción enorme y
viceversa, podemos disponer de una plataforma con un rendimiento pésimo pero que permite a la organización disponer de un nivel excelente de satisfacción de los usuarios. Vamos a ver dos casos que nos sirvan como ejemplo de las situaciones anteriores:

Ejemplo A: Una plataforma dispuesta por 5 máquinas, las cuales están dando servicio al 90% de sus posibilidades, tanto de velocidad de procesamiento, como de uso de memoria y tiempo de respuesta en el acceso a disco. La plataforma soporta una aplicación para 1000 usuarios, es normal que aun estando los tiempos de respuesta al 100% la plataforma no da unos tiempos de respuesta al usuario los cuales sean satisfactorios. Este problema de satisfacción de los usuarios no está relacionado con el rendimiento, ya que el rendimiento de la plataforma es del 90%, estamos aprovechando los recursos disponibles sacando el mayor provecho de ellos, el problema está relacionado con el capacity planning que se haya realizado de la plataforma, ya que la plataforma debe crecer, bien para absorber mas usuarios, bien para intentar reducir los tiempos de respuesta.

Ejemplo B: Supongamos la misma plataforma del ejemplo anterior, pero esta vez el número de usuarios que la utilizan es de dos, es normal que pensemos que el grado de satisfacción de los usuarios sea muy superior al del ejemplo anterior pero el rendimiento de la plataforma deja mucho que desear, ya que no estamos sacando provecho de los recursos disponibles.

Los ejemplos anteriores ilustran como la relación entre rendimiento y satisfacción del usuario no es línea, es decir mayor rendimiento mayor satisfacción. Nosotros como ingenieros de la plataforma IT, debemos buscar un punto intermedio que permita tener un rendimiento en la plataforma el cual genere un grado de satisfacción del usuario correcto para el desarrollo del negocio.

Tiempo de respuesta vs respuesta satisfactoria

En el apartado anterior comentamos que un usuario espera una respuesta satisfactoria del sistema y la interpretación de respuesta satisfactorio es subjetiva, como también es subjetivo la forma en la que  el usuario experimenta el tiempo de espera. Pero ¿qué ocurre cuando modificamos alguno de los parámetros anteriores? es decir, modificamos
el tiempo de respuesta  o bien el resultado que obtiene el usuario, para que la  sensación que tenga sea satisfactoria. Nosotros como ingenieros podemos trabajar en la reducción del tiempo de espera, ya que este tiempo está relacionado directamente con la plataforma IT. Pensemos en Google, la cual posee una enorme infraestructura IT
la cual permite reducir los tiempos de respuesta, pero Google no siempre da una respuesta satisfactoria en cuanto a los resultados, pero su tiempo de respuesta siempre es muy bajo, por lo tanto el usuario aunque no recibe la respuesta esperada, tiene un buen nivel de satisfacción, sencillamente porque tienen la impresión que el sistema responde muy rápidamente.

Tiempo de respuesta

Vamos a centrarnos en la variable que está relacionada directamente con la plataforma IT, es el tiempo de respuesta de la plataforma frente a una petición determinada. El tiempo de respuesta comienza justo en el momento que el usuario termina de introducir la petición y da la orden de ejecutarla, nosotros vamos a pensar en un click del ratón sobre un botón “Aceptar” en una aplicación, por ejemplo una aplicación WEB.

Se envía la petición

Tiempo de red (Tr1)

Se recibe la petición

Se trata la petición

Tiempo de procesamiento (Tp)

Se envía la respuesta

Tiempo de red (Tr2)

Se recibe la respuesta

El tiempo de red depende del tamaño de la petición, por lo tanto Tr1 no tiene por qué ser igual a Tr2, aunque la infraestructura de red (en teoría) sea la misma tanto para el envío como para la recepción. De los 3 tiempos, nuestra plataforma intervienen los 3, pero no de manera homogénea, ya que el tiempo de red, tanto Tr1 como Tr2 dependerá de la infraestructura del usuario, la infraestructura de terceros y también de nuestra  infraestructura de red. Por lo tanto, nosotros somos responsables de una parte del tiempo que se emplea en Tr1 y Tr2. En cuanto a Tp, es el tiempo de procesamiento de la petición, en este tiempo se incluye todo el tiempo que emplean las distintas tareas de nuestra plataforma para devolver una respuesta. El tiempo de procesamiento (Tp) es 100% nuestra responsabilidad y por lo tanto es en la reducción de este tiempo, donde tendremos mayores oportunidades para mejorar la percepción que tienen los usuarios de la plataforma sobre los tiempos de respuesta.

Desde el punto de vista del usuario  el tiempo de respuesta es:

Tusr = Tr1 + Tp + Tr2

Desde nuestro punto de vista, el tiempo de respuesta debe ser el mismo, pero debemos ser conscientes que aunque podemos trabajar en los 3 tiempos,  donde conseguiremos mejores resultados será intentando minimizar el tiempo de procesamiento (Tp).

Tiempo de procesamiento

El análisis del tiempo de procesamiento nos ayudará en la tarea de intentar encontrar un punto del procesamiento de la petición que podamos mejorar para que se reduzca en su conjunto el Tp. Dependiendo de la plataforma en la que trabajemos, debemos realizar un desglose de todas las operaciones que se realizan para procesar una petición, analizando los tiempos que se emplean en cada una de las operaciones.

Siguiendo una arquitectura típica, la mayoría de las plataformas están formadas por 3 capas:

• La capa de Presentación.
• La capa de Aplicación.
• La cada de Datos.

En cada una de las capas identificaremos las operaciones que realizan los distintos componentes de la capa para tratar la petición. También mediremos los tiempos de transferencia de información entre una capa y la siguiente, para identificar posibles mejoras en la capa de comunicaciones.

Este tipo de análisis nos permitirá identificar aquellas partes de la plataforma las cuales no  están dando un buen rendimiento, ya sea por exceso de provisión como por defecto. Recordemos que un buen rendimiento no es obtener un resultado lo más rápidamente posible, sino que el tiempo de respuesta quede justificado por el coste de la petición. No debemos pensar cuando hablemos de rendimiento únicamente de velocidad, también debemos pensar en costes y justificaciones de las distintas soluciones que se ajusten a las necesidades de negocio de nuestra organización.

El análisis del rendimiento debemos verlo como ejercicio que abarque el conjunto de la plataforma IT, ya que debemos considerar la plataforma IT como un sistema complejo formado por elementos que interactuan mediante una serie de directrices, por lo tanto en el rendimiento intervienen tanto los elementos como la definición de las directrices.  Pensemos por ejemplo, para qué queremos disponer de discos rápidos, si resulta que la infraestructura de comunicaciones no tiene suficiente ancho de banda para transmitir todo lo que las aplicaciones obtienen de los discos, este es un ejemplo de una plataforma que pensamos dispone de un buen rendimiento en los discos, pero cuya infraestructura de red está por debajo de las necesidades de la nuestra plataforma, por lo que podemos afirmar que en su conjunto el rendimiento es muy bajo, ya que tenemos elementos que tienen un coste alto, como pueden ser los discos de fibra, pero de los que conseguimos una tasa de transferencia muy por debajo de sus posibilidades potenciales, debido a que las aplicaciones no conseguirá transmitir por la red, tan rápido como podrían leer de los discos.

Otro ejemplo, podría ser el uso de CPU, actualmente existen en el mercado una serie de procesadores multicore. Este tipo de procesadores tienen un gran potencial en cuanto a l rendimiento que podemos obtener de ellos. Han sido diseñados para ejecutar aplicaciones multithread, ya que se basan en un principio mediante el cual una aplicación multihread comparte el espacio de direcciones del proceso, por lo tanto todos lo threads, por el principio de proximidad tendrán las mismas peticiones de memoria y por lo tanto muchos aciertos en las caches. Pero por muchas máquinas con procesadores multicore que tenga nuestra plataforma, si la aplicación no está preparada para cierta carga, el rendimiento que sacaremos de los procesadores será muy pobre. Por ejemplo, un problema típico de las aplicaciones multithread es  que a partir de un número de sesiones concurrentes los threads de aplicación comiencen a competir por elementos de sincronización, lo que provocará que la ejecución normal de dichos threads se ralentice. La pregunta que nos debemos hacer es ¿en qué nos ayudan nuestras nuevas CPUs multicore? La respuesta es sencilla, en disponer de más threads luchando por un recurso compartido, es decir, sencillamente en nada. Este es un ejemplo de como un elemento, como puede ser una CPU multicore, con un buen potencial en cuanto a rendimiento, en ciertas circunstancias su rendimiento es muy pobre y puede darse el caso que hasta peor que en otro tipo de CPUs, pero este es otro tema que discutiremos otro día.

Estos ejemplos, sirven para ilustrar el por qué debemos analizar los tiempos de cada una de las tareas que ejecutan los distintos elementos de una plataforma para procesar una petición. Es sorprendente la veces que en una plataforma con un potencial en rendimiento enorme, no podemos obtener los resultados esperados por culpa de que dicho potencial de rendimiento se empobreces por el comportamiento de un único elemento, que a primera vista parecía insignificante, como una tarjeta de red, un espacio de disco compartido, el número de semáforos de un SO o la configuración por defecto del pool de conexiones a una base de datos.

Capa de presentación

La capa de presentación es la encargada de presentar los resultados solicitados a la plataforma, normalmente está formada por un pool de máquinas, sobre las que se balancean las peticiones y de esta forma poder distribuir la carga. Existen tres problemas que se pueden presentar en la capa de presentación y que afectan directamente al tiempo de respuesta.

• El balanceo no sea homogéneo, es decir, que todas las máquinas no reciben el mismo número de peticiones, en este caso se produciría un problema de carga en algunas de las máquinas, impidiendo que tanto la recepción como la presentación de los datos no se hagan en los tiempos esperados de operación normal del sistema.
• El tiempo de sesión sea insuficiente, la capa de presentación se encarga de mantener establecida la sesión con el usuario, una elección errónea en la configuración del tiempo de sesión del servicio puede provocar que se generen timeout en esta capa, generando de esta forma 2 problemas, por un lado se cierra la comunicación con la capa de aplicación, lo que suponen no poder aprovechar el trabajo que ésta capa estaba realizando y por otro lado, al cerrar la conexión con el usuario, este tiene la sensación de que se ha producido un error.
• Problemas de Caché, la mayoría de las plataformas implementan algún tipo de cache en la capa de presentación, lo que reduce el número de peticiones, sobre todo, cuando hablamos de contenido estático. No disponer de una buena politica para implementar las caches puede provocar un rendimiento ineficiente en la capa de presentación.

En la mayoría de los casos la capa de presentación no implementa demasiada lógica del negocio, sencillamente existe para recibir y enviar datos, por lo tanto debemos asegurarnos que los datos, tanto de peticiones de entrada, como las respuestas de salida estén el menor tiempo posible en tránsito en esta capa. Ni que decir tiene que cualquier problema en esta capa, independientemente de lo bueno que sea el rendimiento en las capas inferiores, afectará directamente en el tiempo de respuesta que percibe el usuario.

Capa de Aplicación

La capa de Aplicación implementa la lógica del negocio, dependiendo de la complejidad de esta lógica la capa de Aplicación será mas o menos complicada desde un punto de vista de su arquitectura. La capa de Aplicación se encarga de modelar las respuestas que la plataforma debe dar, en función de las peticiones recibidas. Esta capa es la que puede presentar el mayor número de problemas, en cuanto al rendimiento se refiere. Es la capa mas compleja desde un punto de vista lógico. También tenemos el problema de la implementación que se haya realizado en la lógica de negocio. En esta capa podemos encontrar, entre otros problemas, alguno de los siguientes,  que afecten de forma directa al tiempo de respuesta:

• Una mala implementación de la lógica de Negocio. Los componentes de la capa de aplicación son los encargados de modelar los datos para construir una respuesta, dependiendo de la implementación de los procesos de modelado de datos, la capa necesitará mas o menos tiempo.
• Problemas de sincronización. Hoy en día la mayoría de las aplicaciones están costruidas sobre entornos multithread, permitiendo que varios threads de un mismo proceso trabajen de forma mas o menos coordinada para modelar los datos. Si los métodos de sincronización entre los distintos threads no están correctamente implementados, pueden provocar esperas para intentar acceder al recurso compartido, lo que se traducirá en un aumento del tiempo de respuesta. A parte de los problemas derivados de las espera, se puede producir una situación aún peor en la que los threads queden bloqueados, lo que se conoce como deadlock.
• Problema en el balanceo de peticiones. Al igual que ocurre en la capa de presentación, normalmente la capa de aplicación está formada por una granja de servidores, sobre los cuales se balancean las peticiones para intentar distribuir la carga. Si las peticiones que recibe la capa de aplicación no son homogéneas en cuanto al orden de magnitud de sus pesos, se puede producir un desequilibrio en el balanceo de carga, algunas de las máquinas estarían procesando peticiones pesadas mientras siguen recibiendo otro tipo de peticiones mas ligeras, frente al resto de máquinas que solo reciben peticiones ligeras. Esta diferencia entra la carga de las máquinas provocaría de forma aleatoria un problema con los tiempos de respuesta.

A grandes rasgos, estos son tres ejemplos, de los problemas que primero se deberían intentar resolver en la capa de aplicación, ya que, dependiendo de la naturaleza de la plataforma IT que tenga nuestra organización, son los principales causas de aumento en el tiempo de respuesta.

Capa de datos

La capa de datos es la encargada de almacenar los datos de la plataforma, normalmente esta compuesta por una serie de máquinas en las cuales corre varias Bases de Datos. La capa de Aplicación se encarga de solicitar los datos que necesita a la Capa de Datos, así como solicitar también que se almacenen nuevos datos o las modificaciones que se vayan realizando. Los tiempos de respuesta de la capa de Datos intervienen directamente en el tiempo de respuesta del usuario, ya que la capa de aplicación cuando solicita un dato, debe esperar un tiempo determinado a que la capa de datos conteste. Los principales problemas que nos podemos encontrar en la capa de Datos son:

• Problemas de acceso al hardware de almacenamiento. Los datos, normalmente, están almacenados en un espacio de disco, este espacio puede ser interno a la máquina o externo servidor por una red SAN/NAS. Realizar un análisis sobre las distintas capas por la que pasa el dato desde que solicita hasta que se obtiene, es una tarea imprescindible para identificar algún posible cuello de botella.
• Configuración de caches en los gestores de datos. La mayoría de los gestores de datos, normalmente las Bases de Datos, disponen de una serie de parámetros para la configuración de caches internas localizadas, en la mayoría de las veces, en memoria RAM, realizar una configuración correcta de estas caches, evitara tener que solicitar el dato a disco y por lo tanto evitamos el tiempo que se necesita para traer el dato del disco.

En la capa de Datos, debemos estar seguros que el acceso al almacenamiento físico en disco en correcto, está bien dimensionado y los tiempos de respuesta del acceso a los disco está dentro de los márgenes que hemos establecido para que la respuesta a la capa de aplicaciones sea optima. También revisar que los distintos niveles de caché están perfectamente configurados y trabajan de forma que su uso sea eficiente, todos los datos que podamos recuperar de cualquiera de los distintos niveles de caché será mas rápido que tener que recuperar un número determinado de bloques en un disco físico.

Conclusión

Como mensaje resumen del post, cuando hablemos de Rendimiento no debemos pensar en velocidad, sino en el término eficiencia. Si conseguimos que nuestra plataforma sea eficiente conseguiremos entre otras cosas velocidad, pero he dicho “entre otras cosas”, estas otras cosas son, ajuste de costes, justificación de las soluciones sobre la arqutectura de la plataforma y sobre todo conocimiento de nuestra propia plataforma.

Hay 3 principio que sigo cuando ejecuto un Capacity Planning y son los 3 consejos que doy a aquellas personas que me preguntan sobre cómo construir un Capacity Planning:

1. Un Capacity Planning es un proceso vivo durante la vida de un proyecto o una plataforma, por lo que debemos ser sumanete cuidadosos a la hora de construir un modelo, ya que éste debe ser lo suficiente versatil para adaptarse a las modificaciones en la plataforma o proyecto, a lo largo de su vida.
2. El Capacity Planning es el medio no el fin.  no debemos complicanos la vida construyendo de un modelo demasiado complicado, ya que el Capacity Planning es una herramienta para conseguir un fin. Por lo tanto,  debemos construir la herramienta, lo mas sencilla posible.
3. El modelo de representación de la realidad que costruyamos en un Capacity Planning debe emular la con la mayor realidad posible el comportamiento de la plataforma. Este modelo es nuestro banco de pruebas,  por lo que debemos tener cuiado al construir el modelo porque nos puede dar información sesgada.

Cómo construir un modelo matemático sencillo

Como buen ingeniero, intento utilizar las matemáticas de una forma moderada considero que son una herramienta muy útil, pero desde la perspectiva de un Capacity Planning, no podemos basar la toma de decisión sobre nuestra plataforma únicamente en un modelo matemático. Por lo general los ingenieros usamos las matemáticas para crear modelos de simulación y esta es una de las tareas de un Capacity Planning, aunque como veremos en el ejemplo por muy buena que sea tus matemáticas, nadie construye un puente solo con una navaja suiza.

Nuestro ejemplo es tremandamente sencillo, pero nos permitirá entender cual es el procedimiento para crear un modelo matemático. Dicho procedimiento podremos aplicarlo en nuestro Capacity Planning extrapolando las tareas al número de elementos y variables de nuestro sistema.

El procedimiento es tan sencillo como:

1. Elegir las variables que deseamos modelizar
2. Estudiar la relación entre las variables y con el sistema.
3. Calcular las funciones necesarias para el modelado.
4. Realizar los cálculos con nuestro modelo.

Elegir las variables que deseamos modelizar

Para el ejemplo vamos a construir un sencillo modelo que nos permita conocer el comportamiento de 2 variables:

• El porcentaje de uso de CPU.
• El número de peticiones que puede recibir nuestro sistema.

Con nuestro modelo, podremos saber cuantas se necesita para que el sistema pueda atender un número de peticiones determinadas y de esta forma poder tomar una decisión sobre la forma de crecimiento y las limitaciones del sistema.

Tenemos el siguiente conjunto de muestras que hemos recogido durante 24 horas.

para nuestro ejemplo vamos a ver 2 tipos de peticiones distintas.

• Peticiones A, son peticiones las cuales consumen un cantidad fija de CPU, todas las petciones consumen la misma cantidad de CPU. Este tipo de peticiones son por ejemplo el número de bytes transferidos, el tiempo  de CPU que se emplea para transferir un byte es el mismo que para otro byte, siempre desde el punto de vista de sisteman simples.
• Peticiones B, son peticiones que no consumen la misma cantidad fija de CPU. Este tipo de peticiones son por ejemplo ls petciones que recibe un servidor deAplicaciones o de Base de Datos, donde el uso de CPU de cada petición dependerá de la naturaleza de la misma.

Estos son los dos tipos de peticiones que podemos observar en cualquier sistema, peticiones fijas y peticiones variables.

Hemos representado ambos tipos de peticiones en el mismo gráfico para que podamos ver como. aunque se conserva el uso de CPU, el número de peticiones varía de una muestra a otra. En el gráfico podemos ver cómo las peticiones de tipo A y B emplean la misma cantidad de CPU, aunque desde las 10:00 hasta las 21:00 el número de peticiones de tipo B es inferior al de tipo A, es deci, durante este periodo de tiempo se producen peticiones que consumen mas CPU.

Estudiar la relación entre las variables y con el sistema.

En este paso debemos analizar la relación que existe entre las dos variables que estamos estudiando, el %CPU y el número de peticiones. Una forma sencilla es representar ambos conjuntos de datos en una gráfica donde tendremos en el eje de la X los valores de %CPU y en el eje de la Y los valores con los número s de peticiones.

Podemos ver como los peticiones de tipo A y tipo B se distribuyen de forma distinta en el gráfico. Podemos utilizar alguna función de regresión para obtener una función que represente a la distribución de tipo A y B. Con cualquier programa de tipo hoja de cálculo podemos obtener una función de regresión. Para nuestro ejemplo hemos utilizado Excel y hemos obtenido:

• Para las peticiones de tipo A tenemos la función  Fa(x)=0,357x
• Para las peticiones de tipo B tenemos la función Fb(x)=5,6068Ln(x)-9,7538

Con esta información sabemos que la relación que existe entre el uso de CPU y el número de peticiones de tipo A es linea, es decir si una petición de tipo A consume un porcentaje de CPU, dos peticiones de tipo A consumen el doble de porcentaje de CPU.

La relación entre el uso de CPU y el número de peticiones de tipo B es NO linea y por lo tanto es mas difícil de estudiar.

Calcular las funciones necesarias para el modelado.

Una vez que conocemos la naturaleza de la relación entre las dos variables que estamos estudiando podems comenzar con el análsis para la obtención de las funciones que nos permiten definir el comportamiento de nuestro modelo.

Modelo lineal

Hemos visto que la relación entre uso de CPU y el número de peticiones de tipo A es lineal y hemos obtenido la función que describe dicha relación:

Fa(x)=0,357x

Es decir que cada petición consume el 2,8% del uso total de CPU.

Pero normalmente, los sistemas tienen una distribución a lo largo del tiempo que define el comportamiento del mismo. No es igual la carga que podemos añadir a un sistema a las 03:00 de la mañana que a las 17:00 de la tarde. Debemos recordad que uno de los objetivos del  Capacity Planning se dar respuesta a preguntas como ¿podrá mi sistema aguntar 50 usuarios mas? pero estos usuario tendrán una distribución en el tiempo. Por lo tanto debemos modelar el funcionamiento de nuestro sistema durante un periodo de tiempo.

En el siguiente gráfico hemos representado la distribución del %CPU y las peticiones de tipo A.

Hemos incluido la función polinómica de grado 6 que podremos emplear para describir el comportamiento de la varible %CPU y número de peticiones.

Fcpu(x) = -1E-05×6 + 0,0016×5 – 0,0639×4 + 1,0062×3 – 5,8686×2 + 7,3204x + 25,136

Fpet(x) = -4E-06×6 + 0,0006×5 – 0,0228×4 + 0,3593×3 – 2,0959×2 + 2,6144x + 8,9772

Podemos ver que la relación que existe entre ambas funciones tiene un factor de 0,357.

Modelo NO lineal

En este cas, el conjunto de peticiones de tipo B no son iguales y además se distribuyen en el tiempo de una forma determinada, tenemos que encontrar la función que define la relación entre %CPU y número de peticiones.

En la siguiente table tenemos una columna para el %CPU, el número de peticiones de tipo B y el factor Fcpb.

Fcpb = %CPU / Peticiones B

En el siguiente gráfico representamos la columan FcpB para obtener la función polinómica de grado 6 que define su comportamiento.

Ya tenemos la función que relaciona ambas variables.

FcpB(x)=0,0000165639*x6- 0,0011982358*x5 + 0,03245624*x4 – 0,4095446*x3 + 2,4555428*x2 – 6,2596358*x + 7,574714
Ahora podemos calcular cuanta CPU utilizarán un número determinado de peticiones en un momento determinado. Pero tal como comentamos al principio, aunque hemos utilizado una función polinómica de grado 6, en este dicha función está cometiendo 2 errores importantes:

• Primero, está sesgando el pico que se produce a las 19:00, por lo que podemos cometer un error al calcular el uso de CPU de un determinado número de peticiones en ese momento, las 19:00
• Segundo ha aumentado en el factor de relación entre ambas variables en las horas 15:00, 16:00 y 17:00 por lo tanto si utilizamos esta función en esas horas, el uso de CPU o el número de peticiones que podemos calcular será erróneo.

Realizar los cálculos con nuestro modelo.

Una vez que tenemos el modelo construido y somos conscientes de los defectos que presenta el modelo, podemos hacer nuestros calculos dobre la capacidad, los siguientes gráficos muestran una simulación de un incremento de 0% de peticiones, de un 30% y de un 60%

Conclusión

En este post hemos visto como se puede crear un sencillo modelo mátemático, mediante la utilización de las funciones de regresión, en nuestro caso funciones polinómicas de grado 6 y como la utilización de este tipo de modelos tienen sus ventajas, como son poder crear un modelo totalmente teórico del comportamiento de la plataforma bajo unas circustancias determinadas, pero también presenta inconvenientes como pueden ser el sesgo de los datos o la modificación de ciertos factores que no coinciden con la realidad de nuestra plataforma.

Los modelos matemáticos no son malos, sencillamente son otra de las herramientas que podemos utilizar para la ejecución de un Capacity Planning y al igual que ocurren en otras ramas de la ingeniería, por ejemplo la obra civil, un puente no se hace solo con matemáticas.

Para que podamos entender el ambito en el que se puede aplicar la Gestión del Conocimiento, primero debemos tener mas o menos claro qué significa realmente terminos como información o conocimiento, los cuales muchas veces empleamos en un contexto equivocado, asumiendo que son iguales o parecidos. Sin entrar en una discusión académica, vamos a ver un modelo que define cuatro conceptos, los cuales nos servirán para clasificar los distintos estados de la información de nuestro sistema. A mi personalmente, me gusta el modelo de jerarquía Dato-Información-Conocimiento-Sabiduría (DIKW en inglés), ya que identifica de forma sencilla y clara cuales son los distintos estadios en los que se puede encontrar lo que comúnmente conocemos como “Información” y que veremos que es un termino erróneos en algunas de las situaciones en las que lo empleamos.

Dato, Información, Conocimiento y Sabiduría

El modelo Dato-Información-Conocimiento-Sabiduría consiste en un modelo jerárquico piramidal, es decir que cada capa se apoya en la capa inferior, ya que sencillamente le da un valor añadido a ésta, dicho valor añadido junto con el valor de la capa inferior dan como resultado una nueva capa. La base de la pirámide es el dato, justo encima del dato está la capa de información la cual se forma a partir del dato. Sobre la capa de información está la capa de conocimiento que al igual que ocurre con la capa inferior la capa de conocimiento da un valor añadido a la capa de información. Por último como capa cúspide de la pirámide está la capa de sabiduría.

La pirámide DICS podemos aplicarla en los sistemas de información para identificar cual es el estadio de la pirámide en el que se encuentra nuestro sistema y analizar si realmente se ha conseguido el objetivo que se perseguía. Pero no solo desde el punto de vista de los objetivos puramente de negocio es útil analizar y reflexionar sobre la posición de la pirámide que ocupa nuestra plataforma, desde un punto de vista de la gestión de los recursos, conocer la distribución de nuestro equipo humano en la pirámide es un ejercicio que nos permitirá identificar lagunas y carencias de conocimiento que podrían provocar de manera directa problemas en la gestión tanto de los Sistemas de Información como del equipo humano.

La aportación que cada componente del equipo de personas que explotan un Sistema de Información se puede medir de muchas formas, pero hay dos variables que son tremendamente útiles, la actitud y la aptitud. El mantener dichas variables dentro de unos rangos mínimos permitirá que el equipo funcione correctamente.

Dato

Podemos definir el dato como la unidad mínima de información con la que trabajamos, el dato por si solo no aporta nada, no podemos tomar decisiones únicamente contando con el dato, independientemente del número de datos que tengamos. El dato simplemente nos ayuda a disponer de una representación entendible para nosotros de ciertas características tangibles o abstractas del sistema. Datos son por ejemplo los bytes de la memoria de una máquina, el número de transferencias que realiza un disco duro, la velocidad de una tarjeta de red o el número de cores de un procesador, todos estos ejemplos son “datos”  que por si solos no aportan nada, simplemente son valores que podemos obtener de un Sistema de información y cuyos nombres son la nomenclatura acordada oficial o extraoficialmente para que todas las personas que trabajamos en las áreas de Sistemas podamos identificar de qué dato se trata.

Como ejemplo, podemos comentar la utilidad de los comandos de un SO, son pequeños programas que nos permiten ejecutar sencillas acciones sobre los sistemas, la mayoría de esta acciones consisten en operaciones para obtener datos, por ejemplo el consumo de CPU, el número de páginas usadas en memoria, el número de semáforos creados, el identificador de un usuario, el tamaño de un disco, etc.

Dato = Unida mínima de información

Información

El segundo nivel de la pirámide DICS es la información, como hemos comentado, el dato por si solo no sirve para mucho, necesitamos agrupar los datos para obtener algo mas que simples cifras sobre los elementos de una plataforma o estados de los dispositivos que forman parte del Sistema de Información. Podemos decir que la información consiste en la agrupación de varios datos y que dicha agrupación confiere un significado al conjunto, añadiendo un nivel mas de valor al que se puede obtener del dato por si solo. Obtener información de un conjunto de datos es un ejercicio de inteligencia propiamente dicho, ya no se trata de valores identificados con un nombre, sino que se realiza un ejercicio de abstracción del conjunto de datos para obtener un valor que los represente a todos, de esta forma la información trasmite un mensaje que puede ser interpretado.

Como ejemplos de información de un Sistema de Información podemos citar el estado de una máquina, la información de estado está compuesta por la agrupación de todos los datos relevantes de una máquina, por ejemplo el uso de CPU, el uso de disco, el uso de la
red, etc. Todos estos datos en su conjunto permiten dar información sobre el estado de una máquina. Subiendo un nivel en la arquitectura de un sistema de información, podemos poner otro ejemplo, el estado de la plataforma mediante la obtención de la información
agrupando los datos de estado de todos los elementos de una plataforma, en este caso el dato es la información que se obtiene de cada sistema y la información es la agrupación de todos los estados, dando de esta forma información sobre el sistema de información en su totalidad.

Información = Agrupación de los datos para trasmitir un mensaje del conjunto

Conocimiento

El segundo peldaño de la pirámide es el conocimiento. La información nos permite obtener agrupar los datos disponibles y generar ciertas abstracciones para que podamos trabajar con una representación del conjunto de datos. Si queremos seguir avanzando en la pirámide DICS debemos aportar algo mas a la información y como es la experiencia. Decimos que el conocimiento es la suma de la información y la experiencia. Podemos recoger todos los datos de un sistema, agruparlos para obtener información, por ejemplo información de estado de los elementos de la plataforma, Conocimiento sería aplicar nuestra experiencia a la información para identificar posibles tendencias en el comportamiento del sistema. Nuestra experiencia nos permite ir ampliar la información del sistema comparándola con otras situaciones parecidas y que nos permite no tener que disponer de todo el juego de datos e información. Una persona con experiencia no necesita conocer toda la información que un sistema puede generar para identificar problemas, tendencias, etc.

 Conocimiento = Información + Experiencia

Sabiduría

El último peldaño de la pirámide es la sabiduría, esta es la cúspide del entendimiento que podemos llegar a tener sobre algo. La sabiduría es la suma del conocimiento y la optimización. La optimización es un proceso creativo que se encarga de intentar  modificaciones en la gestión de la información que realiza el Sistema de Información para cubrir las necesidades del negocio. La sabiduría supone poder modificar el sistema para mejorarlo con la garantía que dichas modificaciones lo mejoraran, gestionando todo el conocimiento para la toma de decisiones.

Sabiduría = Conocimiento + Optimización

Sistemas de Información y DICS

Ya hemos repasado las 4 partes de la pirámide DICS, ahora debemos analizar donde están los distintos componentes de nuestro Sistema de Información en dicha pirámide y como esta distribución afecta al proceso de negocio de nuestra organización. Mucha gente piensa que cuando hablamos de gestión del conocimiento únicamente nos referimos a las personas, pero los Sistemas también pueden retener conocimiento, mediante modelos de aprendizaje asistido por ejemplo, un claro ejemplo son los sistema detección de correo basura. Estos sistemas se basan en el aprendizaje de unos patrones que les permiten identificar correos que “pueden ser” SPAM. Por una razón puramente práctica vamos a separar la parte de Sistemas y recursos humanos de un Sistemas de información. Aunque en la práctica los Sistemas de Información los operan recursos humanos en mayor o menor medida, por lo que dicha separación es ficticia y únicamente la vamos a realizar para facilitar el ejercicio de identificación del estado de nuestros Sistemas de información dentro
de la pirámide DICS.

Sistemas

Un sistema de información está compuesto por una serie de elementos Hardware y Software que son los encargados de gestionar toda la información para generar un producto.  Por definición todos los Sistemas trabajan con datos, algunos de nuestros sistemas organizan los datos en información, herramientas de monitorización por ejemplo, las herramientas de monitorización analizan los datos de los sistemas para agruparlos y generar una información que puede ser interpretada por un operador para detectar un problema.

Si el sistema es capaz de adquirir experiencia, hemos comentado los sistemas de detección de SPAM, los sistemas de monitorización que son capaces de identificar problemas en base a la información disponible y a los eventos ocurridos anteriormente. Y por su puesto todos los componentes del Busines intelligence, como son los cuadros de mando, ayuda a la toma de decisión, etc. Los cuales utilizan toda la información disponible del negocio para crear un conocimiento que permita tener un alto porcentaje de acierto en la toma de decisión.

La sabiduría es una fase de la pirámide que por ahora está fuera del alcance de los Sistemas.

Equipo humano

El equipo humano del Sistema de información si puede estar en las 4 partes de la pirámide DICS, puede generar datos, interpretar la información, tener la experiencia suficiente para adquirir conocimiento y disponer de la sabiduría necesaria para entender como los Sistemas de Información interactuan con el Negocio para mejorar los procesos de gestión de la información.

Del equipo humano debemos analizar la desviación que se produce en el equipo con respecto al objetivo inicial de la formación de dicho equipo. Vamos a suponer un ejemplo típico de equipo que opera un Sistema de Información y asignaremos los roles que por defecto suponemos a cada uno de los componentes del equipo.

• Operadores, se encargan de generar datos y de tener la suficiente capacidad para interpretar la información que el sistema genera.
• Administradores, con la información disponible y la experiencia que tiene el equipo de administración, se supone que este equipo cuenta con un conocimiento sobre los sistemas de la plataforma que garantice el normal funcionamiento del mismo.
• Seguridad, es equipo igual que el de administradores estaría en la capa de Conocimiento de la pirámide DICS.
• Arquitectura, es el único equipo, desde un punto de vista del Sistema de información en su conjunto, al cual se le puede considerar que tienen un conocimiento sobre la plataforma y sabe como se deben optimizar los procesos de la misma y por lo tanto en este equipo de personas radica la sabiduría de la plataforma, siempre pensando desde un punto de vista de Sistemas.
• CTO, con el responsable técnico ocurre una paradoja y es que sus competencias no pasan por adquirir la sabiduría del equipo de Arquitectura, ni el conocimiento de las áreas de administración o seguridad. Podemos decir que está a un nivel mas cercano al negocio que el resto de los equipos, el CTO se encarga de gestionar los recursos necesarios para que los objetivos marcados en el Sistema de Información se cumplan.

Este es un ejemplo de roles de los distintos componentes de un equipo de Sistemas y como a dichos componentes se les asigna un capa en la pirámide DICS, pero desde el punto de vista del Sistema de Información, ya que en cada una de sus áreas de competencia, desplazándonos un nivel mas bajo en la arquitectura del sistema de información, la pirámide se vuelve a aplicar y es en este nivel donde podemos encontrar grandes desviaciones del conocimiento esperado. Pongamos un ejemplo de un equipo de administración de sistemas formado por 3 personas y que tienen las siguientes áreas de competencia, según el cuadro de abajo:

Para nuestro ejemplo, el equipo tiene un serio problema con el Backup, porque solo uno de los administradores podemos situarlo en la capa de Información de la pirámide DICS, lo que significa que este equipo únicamente puede saber si se han realizado los backups, pero no en la realidad no puede realizar tareas de administración sobre el backup, cuando ésta es una de sus áreas de competencia y responsabilidad.

Otro problema que podemos deducir del cuadro anterior es la diferencia tan grande que existe entre los conocimientos de los administradores 1 y 2 con respecto al del administrador 3,  dependiendo de la actitud de los componentes del equipo, podría surgir un problema de competencias y responsabilidad.

Conclusión

Como resumen, podemos decir que para garantizar el mayor rendimiento de un Sistemas de Información, entre otras actividades debemos analizar como los sistemas con los que trabajamos y las personas, bien sean parte de los equipos que gestionamos, bien como compañeros, están situados dentro de la pirámide DICS. Este análisis nos permitirá identificar problemas actuales o conflictos futuros, carencias y necesidades en la plataforma, en fin, la gestión del conocimiento es una herramienta fundamental en la optimización de los procesos que controlan el Sistema de Información.

Para identificar cual podría ser el problema, comenzamos por lo mas lógico, crear un script en DTrace que buscara todas las llamadas de sistemas que emplearan un tiempo excesivo, por ejemplo mas de 1 segundo, todos sabemos que 1 segundo es demasiado tiempo para una llamada a sistema, pero quisimos probar suerte.

root@host # cat ./syscall_all_pid.d
/*
 * Presenta el tiempo empleado por cada syscall
 * si es superior a los 1000 mseg
 *
 * Como parametro acepta el PID del proceso
 *
 *  Version: 1.0
 */    

syscall:::entry
/pid==$1/
        {
        array[tid]=timestamp;
        self->th=tid;
        }    

syscall:::return
/pid==$1 && (timestamp-array[tid])/1000000 > 1000 && self->th == tid/
        {
        printf("nTID:  % 8d t Time: %d t %s",tid,(timestamp-array[tid])/1000000,probefunc);
        }

Al ejecutar el script obtenemos una salida parecida a la siguiente.

root@host # dtrace -q -s ./syscall_all_pid.d 4096    

TID:       692   Time: 1009      pollsys
TID:        98   Time: 1009      lwp_cond_wait
TID:       115   Time: 1259      lwp_cond_wait
TID:       233   Time: 1009      lwp_cond_wait
TID:       692   Time: 1009      pollsys
TID:       113   Time: 1259      lwp_cond_wait
TID:        98   Time: 1009      lwp_cond_wait
TID:       112   Time: 2009      lwp_cond_wait
TID:       233   Time: 1009      lwp_cond_wait
TID:       692   Time: 1009      pollsys
TID:       259   Time: 3078      lwp_cond_wait
TID:        98   Time: 1010      lwp_cond_wait
TID:       224   Time: 7507      read
TID:       259   Time: 1144      lwp_cond_wait
TID:       692   Time: 1009      pollsys
TID:        98   Time: 1009      lwp_cond_wait
TID:       262   Time: 1281      recvfrom

De la salida anterior nos llamó la atención las llamadas read, ya que el resto pollsys, lwp_cond_wait y recvfrom son normales, ya que son syscall relacionadas con la espera, pero el tener llamadas read no es tan normal.

Lo siguiente que hicimos fue crear un script para estudiar con algo de mas detalle las llamadas read

root@host # cat syscall_read_pid.d
/*
 * Presenta el tiempo empleado por cada llamada read
 * si es superior a los 1000 mseg
 *
 * Como parametro acepta el PID del proceso
 *
 *  Version: 1.0
 */    

syscall::read:entry
/pid==$1/
        {
        array[tid,arg0]=timestamp;
        self->fd=arg0;
        self->th=tid;
        self->sz=arg2;    

        self->vtype=(int)(curthread->t_procp->p_user.u_finfo.fi_list[arg0].uf_file->f_vnode->v_type);    

        }    

syscall::read:return
/pid==$1 && (timestamp-array[tid,self->fd])/1000000 > 1000 && self->th == tid && self->vtype != 9/
        {
        printf("nTID:  % 8d t FD: % 8d  t  Size: % 8d t Time: %d t %s  t v_type DPort: ",tid,self->fd,self->sz,(timestamp-array[tid,self->fd])/1000000,probefunc);
        }    

syscall::read:return
/pid==$1 && (timestamp-array[tid,self->fd])/1000000 > 1000 && self->th == tid && self->vtype==9/
        {
        self->sdata=(sonode_t *)(curthread->t_procp->p_user.u_finfo.fi_list[self->fd].uf_file->f_vnode->v_data);
        self->so_in=(struct sockaddr_in *)(self->sdata->so_faddr.soa_sa);
        self->port=self->so_in->sin_port;    

        printf("nTID:  % 8d t FD: % 8d  t  Size: % 8d t Time: %d t %s  t v_type %d  DPort: %d",tid,self->fd,self->sz,(timestamp-array[tid,self->fd])/1000000,probefunc,self->vtype,self->port);
        }

Al ejecutar el script obtenemos una salida parecida a la siguiente.

root@host # dtrace -q -s ./syscall_read_pid.d 4096    

TID:       224   FD:        9     Size:    32768         Time: 7510      read    v_type 9  DPort: 5002
TID:       118   FD:       46     Size:        8         Time: 9113      read    v_type 9  DPort: 1521
TID:       224   FD:        9     Size:    32768         Time: 7503      read    v_type 9  DPort: 5002
TID:       224   FD:        9     Size:    32768         Time: 7507      read    v_type 9  DPort: 5002
TID:       118   FD:       46     Size:        8         Time: 9106      read    v_type 9  DPort: 1521
TID:       224   FD:        9     Size:    32768         Time: 7515      read    v_type 9  DPort: 5002
TID:       118   FD:       46     Size:        8         Time: 8733      read    v_type 9  DPort: 1521

De la salida del script syscall_read_pid.d podemos ver que hay llamadas de sistemas read las cuales están demorando unos 9 segundos, además son llamadas que utilizan un FD a un puerto 1521, que es el de BD. Tenemos que identificar qué se ha solicitado a la BD para que la respuesta sea tan lenta, ya que las syscall las debemos considerar desde el punto de vista de ejecución de un thread como una operación atómica. Otro aspecto curioso de este ejemplo es que lo que se devuelve en la llamada read son únicamente 8 bytes.

root@host # dtrace -q -s ./syscall_sendread_pid.d 4096  > /tmp/salida_dtrace

root@host # cat /tmp/salida_dtrace | more    

 Time:      495
 Time:     1495
   2091          TID: 224        FD: 9           Size: 32768     Time: 0         read entry
 Time:     2495
   2039          TID: 223        FD: 9           Size: 32768     Time: 0         send entry
   2039          TID: 223        FD: 9           Size: 32768     Time: 0         send return
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
         0: 78 c0 01 39 1f e7 38 cd 63 c7 bf b5 80 01 5a 55  x..9..8.c.....ZU
        10: 16 a7 9b dd b8 43 e0 00 01 05 1f f8 a3 37 be bf  .....C.......7..
        20: 79 c0 01 0a 54 e7 3b cd 63 c7 bc b5 80 01 45 a9  y...T.;.c.....E.
        30: 5e f6 da b9 92 d2 94 00 05 ad 74 f4 a7 37 b1 53  ^.........t..7.S
        40: 1b 85 01 09 05 ac 31 99 6f 78 8e f4 80 02 14 a3  ......1.ox......
        50: 16 b0 9b df 65 cd e0 00 05 2b 0f bc e5 67 b8 a7  ....e....+...g..
        60: 3c 85 01 09 05 a5 79 cd 6f 7a 96 b1 80 0e a9 cf  <.....y.oz......
        70: 1b f3 98 8e fc bc e0 01 2c a2 18 14 65 37 bd ee  ........,...e7..
        80: 51 48 4e cf 8c e7 2d cd 6c 2b d2 f0 80 02 15 ab  QHN...-.l+......
        90: 5e f8 87 96 a3 bc e3 50 14 2a 57 bd e7 7f e9 ef  ^......P.*W.....
        a0: 7b 9a 5d 0a 55 ad 78 85 3b 7b dd a0 92 02 15 aa  {.].U.x.;{......
        b0: 5f bb cf de f4 ec f3 00 05 2b 56 f4 b2 37 be bf  _........+V..7..
        c0: 6c c0 01 0e 54 e7 2d cd 6c 2b cb f0 80 22 17 e3  l...T.-.l+..."..
        d0: 0a f3 98 8e e0 bc e0 20 07 62 03 bc e5 67 aa ef  ....... .b...g..
...
  7797          TID: 118        FD: 46          Size: 169       Time: 0         read entry
   7797          TID: 118        FD: 46          Size: 169       Time: 0         read return
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
         0: 00 00 06 02 01 01 00 01 0a 00 00 00 07 06 76 6f  ..............vo
        10: 71 2e 61 78 15 01 01 01 07 06 76 6f 72 2e 61 78  q.ax......vor.ax
        20: 15 01 01 01 07 06 76 6f 73 2e 61 78 15 01 01 01  ......vos.ax....
        30: 07 06 76 6f 74 2e 61 78 15 01 01 01 07 06 76 6f  ..vot.ax......vo
        40: 75 2e 61 78 15 01 01 01 07 06 76 6f 76 2e 61 78  u.ax......vov.ax
        50: 15 01 01 01 07 09 78 38 71 6b 31 70 2e 61 78 15  ......x8qk1p.ax.
        60: 01 01 01 07                                      ....

El contenido del fichero temporal es la salida de la instrucción tracemem, ahora tendriamos que sacar la información de este fichero. Mediante un script en PERL podemos tratar nuestro fichero para que de una salida mas sencilla, pero este es un trabajo que dejo aquí para quien se anime. Nosotros vamos a seguir paso a paso. Lo siguiente es buscar en el fichero /tmp/salida_dtrace todas las líneas correspondientes al thread 118 que es el que ha obtenido respuestas lentas de la BD

root@tcapp04 # cat /tmp/salida_dtrace | grep "TID: 118"
   ...    

   8076          TID: 118        FD: 46          Size: 17        Time: 0         send return
   8076          TID: 118        FD: 46          Size: 8         Time: 0         read entry
  17183          TID: 118        FD: 46          Size: 8         Time: 9106      read return
  17183          TID: 118        FD: 46          Size: 210       Time: 0         read entry
  17183          TID: 118        FD: 46          Size: 210       Time: 0         read return
  17184          TID: 118        FD: 46          Size: 23        Time: 0         send entry
  17184          TID: 118        FD: 46          Size: 23        Time: 0         send return
  ...
  17247          TID: 118        FD: 46          Size: 218       Time: 0         read return
  17247          TID: 118        FD: 46          Size: 17        Time: 0         send entry
  17247          TID: 118        FD: 46          Size: 17        Time: 0         send return
  17248          TID: 118        FD: 46          Size: 8         Time: 0         read entry
  25981          TID: 118        FD: 46          Size: 8         Time: 8733      read return
  25981          TID: 118        FD: 46          Size: 65        Time: 0         read entry
  25981          TID: 118        FD: 46          Size: 65        Time: 0         read return    

root@host #

Con la salida anterior podemos identificar el comportamiento de las llamadas a sistemas read y send y lo que nos debería llamar la atención es el tiempo transcurrido entre la entrada en el read y la salida de dicha llamada a sistema, hay un intervalo de 9,1 segundos. Una vez que hemos detectado este read, debemos saber qué se envió a la BD mediante la llamada send para intentar identificar la causa de la lentitud. Buscamos en el fichero de salida de dtrace todas las lineas anteriores a los 8076 milisegundos y encontramos que en el milisegundo 8070 se ejecuta una llamada send

   8070          TID: 118        FD: 46          Size: 2048      Time: 0         send entry
   8070          TID: 118        FD: 46          Size: 2048      Time: 0         send return
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
         0: 08 00 00 00 06 00 00 00 00 20 03 5e 00 02 80 29  ......... .^...)
        10: 00 01 02 25 e2 01 01 0d 00 00 00 00 04 7f ff ff  ...%............
        20: ff 01 02 01 32 00 00 00 00 00 00 00 0a 53 45 4c  ....2........SEL
        30: 45 43 54 20 44 49 53 54 49 4e 43 54 20 44 6f 63  ECT DISTINCT Doc
....

Ahora solo tenemos que sacar la consulta y averiguar si está bien construida, faltan indices, etc. Pero este es otro asunto. Este blog es un ejemplo de como una herramienta como DTrace nos puede ayudar a identificar puntos lentos en nuestras aplicaciones.

• En en plano laboral, hemos estado algo liados, cosas que hacer.
• En el plano personal, mis hijos prefieren ver a Mickey Mouse en Youtube que verme a mi escribiendo en el blog :)

Es el primer evento realizado por la comunidad de Cherokee. Si no conoces Cherokee, ésta es una buena oportunidad de conocer a parte de la gente que está colaborando en su desarrollo, así como asistir a charlas sobre casos de exito. Este joven servidor web se está posicionando muy bien dentro del estrecho mundo de los servidores web, la interfaz es muy amigable y su arquitectura se aleja de la de Apache, lo que le permite una gran capacidad de adaptación a cualquier entorno y sobre todo es una opción indiscutible en entornos de carga extrema. Durante el encuentro se presentará la versión 1.0.

Puedes encontrar toda la información, así como los formularios de registro en la web del evento http://summit.cherokee-project.com