ESTUDIO ARQUITECTURA WEB

Centro de Recursos Informticos y Educativos

CONTENIDO
ESTUDIO ARQUITECTURA WEB............................................................................... 1 CONTENIDO............................................................................................................ 2 INTRODUCCIN...................................................................................................... 4 1.ORGANIZACIN ACTUAL...................................................................................... 4 1.1 Poseidon ....................................................................................................... 5 1.1.1Benchmark sobre servidor Poseidon........................................................6 1.1.2Resultados Pruebas de Rendimiento Poseidon.........................................7 1.1.3Anlisis resultados pruebas de rendimiento...........................................10 1.2 Fenix .......................................................................................................... 11 1.3 Situacin de los servidores..........................................................................12 2.TECNOLOGA DE LA INFORMACIN....................................................................14 2.1 Information Technology Infrastructure Library, ITIL v3................................15 Los procesos ITIL V3....................................................................................... 15 Diseo del Servicio......................................................................................... 16 3.ARQUITECTURAS WEB ALTERNAS......................................................................19 3.1 Arquitectura IBM.......................................................................................... 19 3.2 Arquitectura con CDN.................................................................................. 20 3.3 Arquitectura Flickr....................................................................................... 22 3.4 Arquitectura Live Journal............................................................................. 24 4.SERVICIOS web actuales.................................................................................... 27 4.1 Requerimientos de servicios......................................................................28 4.2 Tipos de servicios....................................................................................... 28 4.3 Riesgos de servicio..................................................................................... 29 5.VIRTUALIZACIONES ........................................................................................... 31 6.1 Portales o servicios para externos...............................................................32

6.2 Servicio o aplicativos de apoyo...................................................................32 6.3 Servicios de vital importancia para la Universidad......................................32 6.4 Servicios de alta demanda o cuellos de botella...........................................33 6.CARACTERIZACIN DE LOS SERVICIOS (Para implementacin bajo virtualizaciones)................................................................................................... 34 7.Servicios bajo virtualizaciones...........................................................................40 8.CONSIDERACIONES FINALES.............................................................................. 43 8.1 Optimizaciones de la Arquitectura Web a Futuro........................................43 8.2 Optimizaciones a nivel de Software............................................................48 8.2.1 Buenas prcticas en Fase de Desarrollo...................................................50 8.3 Estadsticas de servidores...........................................................................52 8.4 Pruebas de Apache vs. Lighttpd sobre Wordpress (MediaWiki y Atesa)......53 8.5 Servidor Web............................................................................................... 56 8.5.1 Sistema Operativo................................................................................. 58 9.CONSIDERACIONES FINALES.............................................................................. 61 ANEXO N1 FORMATOS DE DESCRIPCIN DE SERVICIOS ACTUALES....................68 Blog UTP............................................................................................................ 68 Wiki UTP............................................................................................................ 69 Portal Institucional............................................................................................. 71 Portal Atesa de Occidente................................................................................. 74 ANEXO N2 FORMATO DOCUMENTACIN DE NUEVOS SERVICIOS.......................76 ANEXO N3 RESULTADOS PRUEBA APACHE VS. LIGHT ........................................81 ANEXO N4 CONSULTA DE HERRAMIENTAS PARA RECOLECCIN DE ESTADSTICAS DE SERVIDORES................................................................................................... 87 DEFINICIONES....................................................................................................... 88 BIBLIOGRAFA....................................................................................................... 89

ESTUDIO ARQUITECTURA WEB

El presente estudio de arquitectura se encuentra orientado a soportar los nuevos servicios web de forma escalable, los cuales surgirn como resultado del proyecto de optimizacin y estandarizacin Web de la Universidad Tecnolgica de Pereira a travs de sus portales.

INTRODUCCIN
Con el fin de tener claridad sobre la solucin que se desea construir para la Universidad y que satisfaga las necesidades respecto a los servicios web, es de suma relevancia documentar de manera precisa la informacin actual, las personas involucradas y la manera como debe realizarse el proceso de migracin de la arquitectura, por tanto, este documento se elabora con el propsito de plasmar la informacin de la justificacin y descripcin de los servicios implementados junto con las de conclusiones del estudio.

1. ORGANIZACIN ACTUAL
La Universidad Tecnolgica de Pereira (U.T.P.) es una universidad colombiana, de carcter pblico (estatal), que contaba en 2008 con aproximadamente 14.000 estudiantes (Estadsticas e Indicadores 2008) en programas de pregrado y posgrado, cursando sus estudios en jornada diurna, nocturna y jornada en horarios especiales. Teniendo en cuenta la posicin privilegiada de la Universidad Tecnolgica de Pereira en el sector de educacin superior en Colombia, se requiere que sta cuente con un sitio Web que se constituya en una carta de presentacin altamente representativa de su calidad acadmica y administrativa, para lo cual el sitio Web debe convertirse en uno de los principales medios de comunicacin entre la Universidad y la comunidad. Teniendo en cuenta la relevancia del sitio Web, debe garantizarse que la informacin publicada all siempre este actualizada y cuente con el respaldo de los responsables de la misma, esto es que sea oficial. El actual proyecto de Estandarizacin y Actualizacin Sitio Web UTP requiere un soporte tcnico de Arquitectura que permita el normal funcionamiento y posterior crecimiento de los productos y servicios obtenidos como resultado del mismo, el presente estudio de arquitectura Web se plantea para proveer dicho soporte. Hasta el momento la arquitectura Web de la Universidad ha venido definindose

segn cada nuevo producto/servicio que va surgiendo lo cual origina problemas de rendimiento, compatibilidad e inseguridad de las aplicaciones ya establecidas. Recursos disponibles, Arquitectura Web La universidad cuenta con recursos de hardware y software que actualmente soportan los servicios Web que se prestan a la comunidad. En general el rea de desarrollo Web cuenta con dos servidores. Uno de produccin llamado hasta el momento Poseidon y otro para pruebas llamado Fenix. En el servidor Poseidon el rea de administracin de la red se encarga de su administracin (sistema operativo, aplicaciones instaladas)

1.1

Poseidon

Servidor de produccin CPU: 2 Nucleos a 1.0 Ghz Memoria: 8192 Mb Disco: 200 Gb

1.1.1 Benchmark sobre servidor Poseidon

Se realizaron pruebas de rendimiento y estrs sobre el servidor Poseidon para determinar cmo se est comportando actualmente, para ello se uso el mdulo de Apache AB (Apache Benchmark). AB es una herramienta para pruebas de rendimiento a Apache la cual est diseada para darle una aproximacin del rendimiento de la instalacin. Esta herramienta muestra especialmente cuantas solicitudes por segundo Apache es capaz de servir. Los criterios principales que se consideran para la prueba son: -C Concurrencia Nmero de mltiples solicitudes para realizar al tiempo. El valor predeterminado es una peticin a la vez. -N solicitudes Nmero de solicitudes para llevar a cabo en la sesin de evaluacin. El nmero de concurrencia se aument y luego el nmero de solicitudes. El aumento de solicitudes especialmente mostraba el estrs que puede manejar el servidor en un determinado tiempo. Con el siguiente Script se realizaron las pruebas:
#!/bin/bash if [ -n "$1" ] then cont=1 for N in 10 100 1000 10000 do for C in 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 110 120 130 140 150 do if [ $N -gt $C ]; then echo echo "Benchmarking... $cont ($N HTTP requests, simulating $C concurrent users)" echo "Benchmarking... $cont ($N HTTP requests, simulating $C concurrent users)" >> $2.log echo "Comando usado: ab -n $N -c $C $1" >> $2.log ab -n $N -c $C $1 >> $2.log echo "" >> $2.log

echo "" >> $2.log echo "Sleeping 5 seconds..." ; sleep 5 cont=$(($cont+1)) echo done else done fi

# display error message on wrong usage echo echo "Usage: script [hostname to benchmark with http://and trailing/] [output file .png] " echo "e.g: ./script http://example.com/ /home/myhome/graph.png echo fi

1.1.2 Resultados Pruebas de Rendimiento Poseidon

Benchmark Archivos Dinmicos (# Solicitudes: 100)

Benchmark Archivos Estticos (# Solicitudes: 100)

Benchmark Archivos Dinmicos (# Solicitudes: 1000)

Benchmark Archivos Estticos (# Solicitudes: 1000)

Benchmark Archivos Dinmicos (# Solicitudes: 10000)

Benchmark Archivos Estticos (# Solicitudes: 10000)

1.1.3 Anlisis resultados pruebas de rendimiento

Es importante resaltar que estos datos por si solos no permiten hacer conclusiones puesto que hasta ahora no existe un marco de referencia. Sern precisamente estos datos base lo que permitir hacer un comparativo con las nuevas arquitecturas propuestas, ahora bien, aunque existen pruebas sobre portales de reconocido rendimiento (google, facebook) no es posible comparar situaciones tan diferentes como lo son la Universidad y un buscador de la magnitud de Google. Tambin se debe tener en cuenta que hasta el momento el servidor no solo se est dedicando a atender los servicios web, puesto que adicionalmente atiende la base de datos, otros servidores como el de streaming, licencias matlab, procesos de backup y algunos otros que se desconocen en el momento por falta de informacin acerca del uso real del hardware. Archivos dinmicos Los archivos dinmicos requieren procesamiento por parte de PHP y el servicio de base de datos, el archivo que se utilizo para la prueba fue la pgina principal. Tiempo de solicitud vs concurrencia (usuarios simultneos) Cuando aumenta el nmero de usuarios que simultneamente se conectan el tiempo aumenta en un factor de 47,425 m/s (promedio) Solicitudes por segundo vs concurrencia (usuarios simultneos) En promedio el punto ms alto que se alcanza para atender solicitudes es de 20,6 solicitudes, teniendo en cuenta que el servidor parece no responder a un nmero mayor de 100 usuarios concurrentes. Tambin se puede notar que en general el servidor atiende para concurrencias mayores a 10 en promedio la misma cantidad de solicitudes, aunque para casos menores que 10 se puede notar una baja atencin de las solicitudes.

Archivos estticos Se consideran archivos estticos aquellos que no necesitan ningn preprocesamiento y pueden ser servidos directamente por Apache, para la prueba se utilizo el escudo de la Universidad ubicado en la siguiente direccin http://www.utp.edu.co/principal/images/utp.png Tiempo de solicitud vs concurrencia (usuarios simultneos). En general el comportamiento del tiempo contra los usuarios que realizan peticiones simultneas es similar a los archivos dinmicos pues corresponde a una tendencia lineal, aunque en este caso el factor es de 1,71 ms (promedio). Solicitudes por segundo vs concurrencia (usuarios simultneos) Esta prueba mostr un comportamiento fluctuante, esto puede ser debido a los otros procesos del servidor, aunque en general tambin conserva la facultad de servir en promedio una cantidad de archivos aunque aumenten o disminuyan el nmero de peticiones.

1.2

Fenix

Servidor de pruebas y desarrollos Marca: Hp Compaq Modelo: dc5800 small factory Memoria Ram: 4 GB Disco duro: 2 discos de 250 GB, serial SATA Procesador: Intel(R) Core (TM)2 Duo CPU E8400 @ 3.00GHz, 64 bits. En un disco duro se encuentra instalado el sistema operativo, y el otro disco es para las copias de seguridad del servidor poseidon.utp.edu.co, la base de datos de la pagina Web, del aplicativo redmine y del mismo servidor fnix. Configuracin del Servidor DNS: fenix.utp.edu.co IP privada: 10.1.1.18 IP pblica: 200.21.217.91 Sistema operativo: Ubuntu 9.04, codename: jaunty Servidor Apache Versin: Apache2-2.2.11 Server root: /etc/apache2 Documentroot: /var/ww PHP Version: PHP version 5.2.6-3 Configuration file: /etc/php5/apache2

Base de Datos Motor Mysql 5.0.75 Motor Postgresql 8.3.9

Con el aumento de los servicios de la Universidad los procesos de gestin y cambio estaban bajo presin. Pues no slo deben continuar manteniendo el alto nivel de disponibilidad requeridos en este ambiente competitivo, sino tambin para proporcionar este servicio de manera rentable.

1.3 Situacin de los servidores

La dependencia de - administracin de la red - como resultado de los estudios de seguridad ya tena en marcha un proyecto de reestructurar la disposicin de los servidores, por lo que si bien el servidor Poseidon y Fenix actuales se encuentran en este momento como se describen en puntos anteriores, su prxima disposicin ser similar al siguiente diagrama:

2. TECNOLOGA DE LA INFORMACIN

Responsables actuales de la gestin TI Las funciones de administracin de servicios son las funciones de las personas o los equipos de la organizacin, como profesional de soporte tcnico o administracin del sistema. Actualmente la principal administracin de los servidores corre por cuenta de administracin de la red, es decir, la actualizacin de aplicativos, sistema operativo y nuevas instalaciones hacer parte de sus funciones. El rea de desarrollo web hace las solicitudes cuando necesita hacer cambios al sistema y administracin de la red las atiende. Respecto al rea de desarrollo web, esta realiza los aplicativos sobre el servidor de pruebas Fenix y una vez estn listos son migrados a Poseidon. Es importante destacar que el rea de desarrollo se enfoca en desarrollo e implementacin de los aplicativos (software) y administracin de la red se encarga de lo relacionado con servidores. Problemtica actual El estudio se desarroll para abarcar una serie de problemticas, sin embargo cabe resaltar que ests son comunes a muchas organizaciones, por lo tanto es posible tomar modelos que tengan xito para su aplicacin. Existe duplicacin de esfuerzos dentro de los procesos existentes Actualmente el sistema operativo:

No se capturan los incidentes y las tendencias de uso de los servidores Es necesaria la captura de los incidentes y las tendencias de uso de los servidores para analizar la utilizacin del recurso y as dar servicio efectivo a los clientes. Los datos donde se informen los incidentes y las tendencias de uso de los servidores pueden determinar el uso mximo y planear su capacidad por ejemplo. Es muy importante el establecimiento de polticas de gestin del crecimiento de demanda del recurso, as a medida que se de este crecimiento y mientras se preocupan por monitorear o supervisar el cumplimiento y disponibilidad de los servidores se proporciona conectividad a los usuarios Proporcionar un menor costo de las operaciones de la parte de desarrollo web agilizando tareas que pueden realizarse de manera automtica, se busca siempre una relacin coste/beneficio aceptable.

Las soluciones planteadas estn en funcin de proporcionar

Mayor proteccin para la infraestructura del rea de desarrollo web Aumento del nivel de servicio y disponibilidad a los clientes de universidad: estudiantes, profesores, administrativos, comunidad general. Estratgico cambio en la cultura de gestin de servicios del rea desarrollo web de reactivo a proactivo Mejora de forma significativa los procesos ajustndose a un estndar mejores prcticas reconocidas de TI (ITIL, MOF)

la en de de

Basados en los objetivos

Proporcionar un modelo que cubra las necesidades de capacidad del rea de desarrollo web tanto presentes como futuras. Controlar el rendimiento de la infraestructura del rea de desarrollo web Desarrollar planes de capacidad asociados a los niveles de servicio acordados Gestionar y racionalizar la demanda de servicios del rea de desarrollo web

En esencia el objetivo ltimo debe ser colocar la tecnologa al servicio del cliente. La tecnologa, al menos en lo que respecta a la gestin de servicios TI, no es un fin en s misma sino un medio para aportar valor a los usuarios y clientes. Para gestionar las tecnologas de la informacin pertinentes para definir la Arquitectura de la Web de la UTP se tom la tcnica de gestin de procesos ITIL pues provee todas las herramientas necesarias para la gestin de las tecnologas de la informacin.

2.1 Information Technology Infrastructure Library, ITIL v3

Biblioteca de Infraestructura de Tecnologas de la Informacin, para la Gestin de Servicios de Tecnologas de la Informacin, pero tambin para la gestin de procesos en general, ya que las tcnicas de gestin de procesos son una herramienta indispensable para empresas que desean coordinar sus procesos TI con ITIL. Para desarrollar la Arquitectura de la Web de la UTP se proyecta gestionar el proceso a travs de tcnicas de gestin de procesos como ITIL pues provee todas las herramientas necesarias para la gestin de las tecnologas de la informacin pertinentes para definir la arquitectura Web.

Los procesos ITIL V3

ITIL V3 est orientado al Ciclo de Vida del Servicio. Segn la perspectiva empresarial, los servicios de TI, al igual que los productos, tambin se encuentran condicionados a un ciclo de vida tpico, que empieza con la

introduccin del servicio al mercado y finaliza con la exclusin del mismo del portafolio de servicios. Cada una de las cinco disciplinas principales de ITIL est enfocada a una fase especfica dentro del Ciclo de Vida del Servicio: 1. Estrategia del Servicio: Propone tratar la gestin de servicios no slo como una capacidad sino como un activo estratgico. Se determina qu clase de servicios deben ofrecerse a determinados clientes y/o mercados. 2. Diseo del Servicio: Cubre los principios y mtodos necesarios para transformar los objetivos estratgicos en portafolios de servicios y activos. El Diseo del Servicio se ocupa de desarrollar soluciones adecuadas a los requisitos, de proyectar nuevos servicios y de modificar y/o mejorar los ya existentes 3. Transicin del Servicio: Cubre el proceso de implementacin de nuevos servicios o su mejora. transicin para la

4. Operacin del Servicio: Comprende las mejores prcticas para la gestin del da a da en la operacin del servicio, es decir, las tareas operacionales. 5. Mejora Continua del Servicio (CSI): Proporciona una gua para la creacin y mantenimiento del valor ofrecido a los clientes a traces de un diseo, transicin y operacin del servicio optimizado. Se aplican mtodos de gestin de calidad con el fin de aprender de los xitos y fracasos del pasado.

Diseo del Servicio

En la fase del Diseo del Servicio se determinan los requisitos concretos. El Diseo del Servicio se ocupa de desarrollar soluciones adecuadas a estos requisitos, de proyectar nuevos servicios y de modificar y/o mejorar los ya existentes. La principal misin de la fase de Diseo del Servicio es la de disear nuevos servicios o modificar los ya existentes para su incorporacin al catlogo de servicios y su paso al entorno de produccin. El Diseo del Servicio debe seguir las directrices establecidas en la primera fase y debe a su vez colaborar con ella para que los servicios diseados: Se adecuen a las necesidades del mercado. Sean eficientes en costes y rentables. Cumplan los estndares de calidad adoptados. Aporten valor a clientes y usuarios.

La disciplina ITIL V3 de Diseo del Servicio (Service Design) abarca los siguientes procesos: Gestin del Catlogo de Servicios Asegurarse de que se realice y se edite debidamente un Catlogo de Servicios que contenga informacin precisa y actualizada de todos los servicios operacionales y de los prximos a ofrecerse. La gestin de este catlogo provee informacin fundamental para el resto de los procesos de Gestin de Servicios. Gestin del Nivel de Servicio (SLM, Service Level Management) Negociar Acuerdos del Nivel de Servicios con los clientes y disear servicios de acuerdo con los objetivos propuestos. La Gestin del Nivel de Servicio (SLM) tambin es responsable de asegurar que todos los Acuerdos de Nivel Operacional y Contratos de Apoyo sean apropiados, y de monitorear e informar acerca de los niveles de servicio. Gestin del Riesgo El objetivo es identificar, evaluar y controlar riesgos. Esto incluye el anlisis del valor de los activos de la empresa, la identificacin de amenazas a dichos activos y la evaluacin de su vulnerabilidad ante esas amenazas. Gestin de la Capacidad Este proceso tiene como objetivo asegurar que la capacidad de servicios de TI y la infraestructura de TI sean capaces de cumplir con los objetivos acordados, en capacidad y desempeo de manera econmicamente efectiva y puntual. La Gestin de la Capacidad toma en cuenta todos los recursos necesarios para llevar a cabo los servicios de TI, y prev las necesidades de la empresa a corto, medio y largo plazo. Gestin de la Disponibilidad Se busca definir, analizar, planificar, medir y mejorar la disponibilidad de servicios de TI en todos los aspectos. La Gestin de la Disponibilidad se encarga de asegurar que la infraestructura, los procesos, las herramientas y las funciones de TI sean adecuados para cumplir con los objetivos de disponibilidad propuestos. Gestin de la Continuidad del Servicio de TI (ITSCM, IT Service Continuity Management) A travs de este proceso se controlan riesgos que podran impactar seriamente los servicios de TI. La Gestin de la Continuidad del Servicio de TI se ocupa de que el proveedor de servicios de TI siempre pueda proveer un mnimo nivel del servicio propuesto reduciendo el riesgo de eventos desastrosos hasta niveles aceptables y planificando la recuperacin de servicios de TI. La ITSCM debe disearse para que apoye la gestin de la continuidad del negocio. Gestin de la Seguridad de TI

Se asegura la confidencialidad, la integridad y la disponibilidad de los informes, datos y servicios de TI de una organizacin. Normalmente, la Gestin de la Seguridad de TI forma parte del acercamiento de una organizacin a la gestin de seguridad, cuyo alcance es ms amplio que el del proveedor de Servicios de TI. Gestin de Cumplimiento El objetivo es asegurar que los procesos, sistemas y servicios de TI cumplan con las polticas institucionales y los requerimientos legales. Gestin de la Arquitectura de TI Se busca trazar un plan para el desarrollo futuro del panorama tecnolgico, tomando en consideracin la Estrategia del Servicio y las nuevas tecnologas disponibles. Gestin de Suministradores El proceso asegura que todos los contratos de suministradores apoyen las necesidades de la empresa, y que todos los suministradores cumplan sus compromisos contractuales.

3. ARQUITECTURAS WEB ALTERNAS

3.1 Arquitectura IBM

La arquitectura de IBM posee una descripcin de capas muy detallada, pues se especifica concretamente como se enlazan todos los elementos de la arquitectura, nos interesa conocer en primer lugar la zona desmilitarizada (zona controlada). En la DMZ se controla el trfico a mltiples niveles, all se encuentra ubicado el balanceador de cargas en Hardware; tambin se tiene balanceador de cargas en Software y Caching Proxy, quienes se encargan de distribuir el uso de los recursos de cada unas de las capas, los recursos adicionales se relacionan por lo tanto como replicas de los servidores ya existentes. A travs del Reverse Proxy pasa todo el trfico entrante de Internet y con el destino de uno de los servidores web. Tambin puede distribuir la carga entre varios servidores web. En ese caso puede necesitar reescribir las URL de cada pgina web (traduccin de la URL externa a la URL interna correspondiente, segn en qu servidor se encuentre la informacin solicitada). La arquitectura de IBM tiene servidor Web y servidor de bases de datos (clster) separados en diferentes mquinas.

La arquitectura de IBM tiene servidor Web y servidor de bases de datos (clster) separados en diferentes mquinas.

3.2 Arquitectura con CDN

Content Delivery Network o Red de Distribucin de Contenidos es un sistema de computadores en red a travs de Internet. Una arquitectura con una red de distribucin de contenido (CDN) se usa principalmente para agilizar la distribucin de archivos estticos (imgenes, hojas de estilo, javascripts, multimedia, entre otros), esto permite tener contenidos replicados en mltiples servidores por todo el mundo, acelerando as la descarga de los mismos de cara a los clientes, pues se sirven desde la ubicacin ms cercana al usuario.

La suma de la capacidad de los servidores estratgicamente colocada puede ser superior a la capacidad de la red troncal. Esto puede resultar en un aumento impresionante del nmero de usuarios simultneos. En lugar de cargar todo el trfico en una red troncal o enlace de pares, un CDN puede descargar stas redirigiendo el trfico a servidores de borde. CDN generalmente ofrece contenidos a travs de conexiones TCP y UDP. El rendimiento de TCP en una red se ve afectado por la latencia y la prdida de paquetes. A fin de reducir ambos parmetros, CDN tradicionalmente coloca los servidores lo ms cerca posible a las redes de los usuarios. En teora, si se encuentra ms cerca el contenido ms rpida ser la entrega, a pesar de esto la distancia de la red no puede ser el factor que conduce a mejores resultados. Los usuarios finales probablemente experimentarn menos jitter, menos picos y sobretensiones en la red y la mejora de flujo de calidad - especialmente en reas remotas. El aumento de la fiabilidad CDN permite a un operador ofrecer contenido con alta calidad de servicio, bajos costos y baja carga de red. CDN tecnologas brindan un mayor control de la entrega de activos y la carga de red. Se puede optimizar la capacidad de cada cliente, ofrecen puntos de vista de tiempo real de carga y las estadsticas, revelan que los activos son populares, muestran regiones activa y notificar ver los detalles exactos de los clientes. Estos datos de uso son una caracterstica importante que un proveedor de CDN debe proporcionar, ya que los registros de uso ya no estn disponibles en el servidor de origen de contenido despus de haber sido conectado a la CDN, porque las conexiones de los usuarios finales son atendidas por los bordes CDN en lugar del origen de contenido.

3.3 Arquitectura Flickr

Flickr es un sitio web que permite almacenar, ordenar, buscar, vender y compartir fotografas y videos en lnea. La popularidad de Flickr se debe fundamentalmente a su capacidad para administrar imgenes mediante herramientas que permiten al autor etiquetar sus fotografas y explorar y comentar las imgenes de otros usuarios. En noviembre de 2008, Flickr albergaba ms de tres mil millones de imgenes. Cada minuto se agregan a Flickr alrededor de 5000 imgenes Se tiene que aproximadamente las estadsticas de Flickr eran: Ms de 4 millones de peticiones por da. ~35 Millones de fotos en squid cache. ~2 Millones de fotos en la RAM del squid. ~470 Millones de fotos, guarda 4 o 5 tamaos de cada imagen. 38k req/sec hacia memcached (12 Millones de objetos). 2 PB de almacenamiento en crudo. Cerca de 400,000 fotos son agregadas cada da.

Y se tena una arquitectura parecida a la siguiente:

De esta arquitectura cabe resaltar los siguientes aspectos: Pair of ServerIron's: funciona como balanceador de carga en el cual incluyen redundancia de datos. Squid Caches: provee la primera capa de cacheo, la cual se encarga de cachear el contenido esttico tal como imgenes y HTML, as evitando a PHP App Servers se sobrecargue por el volumen de consultas. PHP App Servers: clster de servidores de aplicativo los cuales tienen la funcionalidad de la pgina. Storage Manager: es el encargado de organizar la informacin. Master-master shards: estas son los nodos de lectura y escritura de los usuarios luego este es replicado a Dual Tree Central Database Dual Tree Central Database: guarda la informacin del usuario Memcached Cluster: usado por PHP App Servers para tener la cache de la parte del aplicativo Big Search Engine: es utilizada para llevar registro de la porcin de datos que quieren servir.

La arquitectura de Flickr est diseada de manera que pueda soportar incrementos en el trfico y as evitar conflictos en el uso de recursos por parte de los servicios soportados, pues el servidor web y el servidor de base de datos se encuentran en servidores separados. Adicionalmente se contempla no slo un servidor sino un clster. Se contemplan balanceadores de cargas y replicacin para atender las peticiones. No se dispone de un solo servidor dedicado exclusivamente a los archivos estticos. Para acelerar la respuesta de los servicios se utilizan memorias cache. Los cuales revisan si la solicitud del cliente ha sido servida ya en algn momento y se encuentra en su memoria la respuesta, para lo cual sirve al cliente esta informacin, evitando as el paso hasta el servidor web y que este realice las consultas o procesos junto con el servidor de base de datos.

3.4 Arquitectura Live Journal

Esta arquitectura tiene las siguientes caractersticas: Pair of BigIP's: funciona como balanceador de carga, tambin proporciona funciones de control de acceso y seguridad de aplicaciones. Perlbal proxies: funciona como balanceador de carga de software, por donde pasa todo el trfico entrante de Internet para dar seguridad y descargar los servidores web almacenando contenido esttico, es decir, provee la primera capa de cacheo la cual se encarga de cachear el contenido esttico tal como imgenes y HTML, evitando as que los App Servers se sobrecarguen por el volumen de consultas. mod_perl App Servers: clster de servidores de aplicativo los cuales tienen la funcionalidad de la pgina. MogileFS Storage: es el encargado de organizar la informacin, son nodos de almacenamiento donde los datos se guardan fsicamente. Estos nodos son simplemente servidores HTTP que recibe peticiones PUT, GET, DELETE.

MogileFS Trackers & DB: el tracker es el proceso encargado de recibir las peticiones del cliente y gestionarlas. En el MogileFS DB se almacenan los metadatos y los namespaces. Memcached Cluster: usado por el App Servers para tener la cache de la parte del aplicativo, su objetivo es el de almacenar objetos en memoria RAM a los que podamos acceder a posteriori cuando sea necesario. Se puede almacenar cualquier clase de objeto que estar asociado a un identificador nico. Master-master shards: estas son los nodos de lectura y escritura de los usuarios luego este es replicado a Dual Tree Central Database Dual Tree Central Database: guarda la informacin del usuario.

4. SERVICIOS WEB ACTUALES

Los servicios contemplados en la arquitectura de la Web son: Portal Institucional Blog Wiki Atesa

Los cuales se encuentran definidos claramente en sus respectivos formatos anexos, el cual es el compendio de los servicios aprobados que actualmente se encuentran implementados. (ANEXO N1) Adems para dar un mejor soporte a los servicios brindados a travs de la Web de la Universidad se ha diseado un nuevo formato para especificar los nuevos servicios contemplados en la Arquitectura Web. (Adjunto se anexa el formato para Documentacin del Servicio, ANEXO N2) Para soportar los aplicativos actuales se debe cumplir con los siguientes requerimientos: Apache (http://www.apache.org/) Versin > 2.0 Servidor HTTP. Este servidor debe servir los archivos que se encuentran en el dominio http://www.utp.edu.co PHP (http://php.net) Version >= 5.2.3

Servicios de apoyo a la lgica del negocio: Archivos Estticos (http://media.utp.edu.co) El servicio de archivos estticos tiene como objetivo albergar todos aquellos archivos que no usan lenguajes de programacin en su interior. A continuacin aparecen los aplicativos que deben correr para este servicio. Lighttpd (http://www.lighttpd.net): Servidor HTTP tiene como caracterstica que es ligero, rpido y flexible, este servicio se usa para servir ms rpido los archivos que no requieren procesamiento lgico del servidor como son los scripts. Este servidor debe procesar los archivos que se encuentran en el dominio http://media.utp.edu.co

Acceso rpido a datos pre-cargados Servicio que se encarga de cache en memoria de datos de varios aplicativos. Memcache (http://memcached.org/): Es utilizado por el CMS liviano y prximos software para servir las vistas y objetos ms rpidamente. ste libera la carga de los servidores y optimiza el tiempo de presentacin al cliente de una pgina. Se debe contar con una gran memoria ya que todas las aplicaciones se conectaran a l para guardar cache.

4.1 Requerimientos de servicios

En el diseo del servicio se consideraron los elementos de software para su despliegue, se debe tener en cuenta, que no se tomaron en consideracin los elementos de hardware (internetworking y almacenamiento va SAN ya que dichos elementos no son de control del rea de desarrollo web). Es necesario detallar los requerimientos de cada servicio, para as tener la especificacin del sistema a desarrollar. Los requerimientos que se definen en la documentacin del servicio son: 1. Funcionales 2. No Funcionales 3. Evaluacin del servicio

Adicionalmente se requiere darle un peso a los requerimientos no funcionales dependiendo de los servicios evaluados con la siguiente tabla, para as establecer una prioridad en la prestacin de los servicios. SERVICIOS REQUERIMIENT OS Confiabilidad Disponibilidad Rendimiento Seguridad Escalabilidad Total Servicio 1 Servicio 2 Servicio 3 Servicio n (Peso de 1 a 5) (Peso de 1 a 5) (Peso de 1 a 7) (Peso de 1 a 5) (Peso de 1 a 5)

Posterior a ello se debe realizar una evaluacin del servicio, lo cual tambin se especifica a travs de un formato.

4.2 Tipos de servicios

Se han contemplado cuatro tipos de servicio principales:

Servicios de Negocio: Servicios core de la Universidad, los servicios que son vitales y propios del negocio. Ejemplo: Pgina principal de la universidad Servicios Administrativos: Son servicios que soportan los procesos de organizacin de la Universidad. Ejemplo: Redmine Servicios de Apoyo: Servicios dentro que del contexto de las aplicaciones proporcionan servicios a otros servicios. Es importante resaltar que la ausencia de estos servicios de apoyo no debe afectar a los aplicativos que los utilicen. Ejemplo: Memcached Servicios de Infraestructura: Servicios que dan soporte a nivel de todos los servicios de la Universidad, tales como logging, auditora, seguridad. Ejemplo: OpenAM

4.3 Riesgos de servicio

Los riesgos de servicio son los riesgos asociados a cada uno de los servicios a partir de lo que se consideraron tres puntos clave: Riesgos de red, administrativos y de software. En cada uno de los formatos donde se describen los servicios se especifica el riesgo y su tipo de riesgo, es importante identificar los riesgos para en el momento de una problemtica tener documentando cual es la dependencia que debe encargarse. Servicios no contemplados Algunos de los servicios prestados por medio de la pagina institucional no pertenecen al rea de desarrollo web, esos servicios son listados a continuacin pero no sern tenidos en cuenta para el proceso de establecimiento de la arquitectura. -Todos los aplicativos alojados bajo el dominio https://appserver.utp.edu.co/ -Toda pgina que no se encuentre instalada bajo el servidor denominado Poseidon Sin embargo se definen servicios adicionales que si bien hacen parte del Portafolio de Servicios del CRIE se pueden definir como sub-servicios sustentados a travs del Portal Institucional, como lo son: Aplicativo de prstamo de salas Aplicativo de inscripcin de monitores Portal Academia Regional CISCO

Mdulos CISCO Redmine Moodle Capacitacin

Adems en esencia el criterio principal para considerar un servicio como no contemplado definitivamente ser todo servicio que no est dentro de la descripcin de servicios o el servicio que no est incluido en Portafolio de Servicios del CRIE.

5. VIRTUALIZACIONES
Existen diversas formas de realizar virtualizaciones, como sugerencia del estudio se recomienda el uso de las Zonas Solaris. Las zonas Solaris son contenedores con el rendimiento de la ejecucin nativa y la seguridad de las mquinas virtuales. Bsicamente consiste en que los procesos pertenecientes a una zona no pueden afectar ni interrelacionarse con procesos de otras zonas, incluso aunque su usuario sea el administrador o "root". A esto se aade la posibilidad de fijar lmites en el uso de procesador, memoria consumida, en el uso de la red, espacio en disco. A estas zonas tambin es posible delegar la gestin a un usuario, con privilegios de administrador o "root" en la zona, sin comprometer la seguridad de la mquina o del resto de zonas. Tipos de zonas Un sistema Solaris puede contener dos tipos de zonas, la zona global y las zonas no globales. La zona por defecto donde est instalado el sistema es la zona global, las zonas adicionales que se creen sern para albergar las aplicaciones las que se desea dar independencia. Componentes de los contenedores Solaris

Identificacin de carga de trabajo Log de uso de recursos Herramientas de administracin de recursos Garantizar uso minimo de CPU (FSS) Limitar maximo uso de CPU (por pools o set de procesadores) Limitar uso de memoria fisica Limitar uso de memoria virtual Limitar uso de ancho de banda Limitar privilegios por zonas

Virtualizacin de sistema operativo por medio de zonas Las zonas estn orientadas para virtualizar instancias del sistema operativo host, con ventajas sobre la vitalizacin tradicional porque permiten a la zona acceder directamente a los recursos de hardware, pero controlando con la zona global la asignacin del recurso. La capa de virtualizacin provee de: Sistema de archivos, dispositivos, red y procesos. Ventajas

Privacidad: Una zona no puede ver procesos fuera de ella

Seguridad: Una zona no afectar la actividad de otra Aislamiento de fallos: Fallo de aplicaciones o servicios dentro de la zona no afectar el funcionamiento de otras zonas Complementado con gestor de recursos No requiere hardware especializado para su funcionamiento A cada zona se le asigna su propia direccin IPV4/IPV6 con su propio espacio de puertos

Se plantean cuatro virtualizaciones principales, esto se propone en bsqueda del aislamiento de errores y una precisa asignacin de recursos:

6.1 Portales o servicios para externos

Esta virtualizacion comprende los portales o servicios que se ofrecen a agentes externos de la Universidad. Por lo general esto servicios no requieren un uso constante del procesador y la memoria asignados. Por ejemplo, una pgina externa desarrollada bajo el CMS liviano consume alrededor de 2MB, as pues esta zona debe tener recursos asignados de la siguiente forma: Memoria: 10MB x servicio o portal instalado Procesador: (debe medirse en funcin del portal)

6.2 Servicio o aplicativos de apoyo

Los servicios o aplicativos de apoyo pueden dejar de funcionar sin afectar notablemente el servicio prestado por la universidad. Estos servicios pueden agruparse bajo una sola virtualizacin. Los recursos asignados a esta, pueden ser expropiados de ser necesario por la virtualizacin principal en caso de ser necesario. Memoria: 10MB x servicio o portal instalado Procesador: (debe medirse en funcin del portal)

6.3 Servicios de vital importancia para la Universidad

Estos servicios deben tener prioridad sobre cualquier otro aplicativo y siempre deben estar disponibles. Para ello aunque la asignacin de recursos se recomienda que sea dinmica, esta es la virtualizaciones que debe tener acceso a todo el recurso en todo momento. Memoria: Toda la disponible Procesador: Todo el disponible Una de las principales ventajas de las virtualizaciones es permitir asignar por porcentajes el uso del recurso. La Zona 3 tiene prioridad sobre todas las otras zonas, por lo que esta debe tener asignado la mayor parte del procesador y la memoria.

6.4 Servicios de alta demanda o cuellos de botella

Servicios como los Blog, con el tiempo empiezan a demandar una cantidad considerable de recursos. Estos servicios son importantes para la comunidad pero no hacen parte de los servicios vitales. Por esta razn y por su posibilidad de ser de alta demanda, deben asignarse bajo virtualizaciones aisladas y optimizadas para su correcto funcionamiento. Memoria: Depende del servicio Procesador: Depende del servicio Como asignar los recursos de forma ms precisa a las dos primeras virtualizaciones Si bien las sugerencias planteadas dependen directamente del nmero de servicios y pueden arrojar una aproximacin inicial solo la medicin continua puede permitir una precisa asignacin, especialmente cuando se trata con servicios tan diferentes y cuyo uso no se puede medir desde el estudio de arquitectura. Para la medicin de los recursos asignados se sugiere la utilizacin de Aplication Manager 9 el cual permite hacer una monitorizacin constante sobre los recursos de las virtualizaciones. Una vez se pueda determinar en general que uso se le da al recurso, se debe asignar el doble de los recursos que hagan alcanzar al sistema el 90% de su utilizacin. Por ejemplo, si la primera virtualizacion tiene asignado 4MB de memoria RAM y 5% del uso de procesador, y durante una semana su comportamiento indica que ha hecho uso del 95% de su memoria y 83% del procesador, se debe proceder a asignar 8MB y 10% del uso del procesador. As mismo, cuando se note que se ha asignado demasiado recurso a una virtualizacion mediante medicin, se debe liberar para otra virtualizacion que lo est solicitando. Servicios sin virtualizaciones Se considero el uso corriente del servidor web, es decir sobre una sola instancia del sistema operativo para permitir una mayor facilidad de administracin Bajo esta implementacin se resalta la facilidad de administracin, pues solo se posee un servidor web que controlar y conserva la dinmica que hasta el momento se llevaba en la seccin. Los servicios nuevos y antiguos que se implementen deben tener muy en cuenta el uso de los recursos de software sugeridos para optimizacin.

6. CARACTERIZACIN DE LOS SERVICIOS (Para implementacin bajo virtualizaciones)

Con el objetivo de crear zonas ajustadas a los servicios y determinar los servicios ptimos a cada zona, se deben proveer unos criterios respecto a los servicios que definan el entorno adecuado para cada uno. Tipo de Servicio

Servicios de Negocio Servicios Administrativos Servicios de Apoyo Servicios de Infraestructura

Pblico objetivo y su poblacin estimada

Cliente Administrativos dependencia

Comunidad Externa Requerimiento estudiantes Requerimiento comunidad universitaria

Usuarios

Estudiantes Docentes Administrativos Egresados Comunidad externa

Debe determinarse cul es el pblico al que va dirigido la prestacin del servicio categorizado y cul es su poblacin estimada, pues esto es base para determinar los recursos que necesita el servicio y garantizarle el servicio tanto a los clientes como a los usuarios; por lo tanto debe definirse cul es el pblico objetivo. Disponibilidad del Servicio

Se categorizan los servicios dependiendo de la disponibilidad que deban tener esto de acuerdo a su funcionalidad puesto que se pueden requerir permanentemente o por perodos determinados.

Permanente 24x7 Horario de oficina, Lun. a Vie. 8am-12m y 2pm-6pm Semestre acadmico

Servicios relacionados (priorizar) Se listan otros servicios relacionados con el que se est definiendo, asignndoles una prioridad para as garantizar este servicio y el conjunto de servicios que se relacionan con l. Se deben definir si los servicios que se relacionan dependen de l o ste depende de otros, adems tambin es importante definir como se relacionan.

Servicios de los que depende Servicios dependientes de l

Escalabilidad Una aplicacin web escalable tiene un tiempo de respuesta que aumenta linealmente cuando aumenta la carga. La aplicacin es capaz de procesar cada vez ms volumen si se aaden recursos adicionales de hardware de forma lineal. Para cada servicio debe proyectarse su escalabilidad, es decir, tener planeado la adopcin de nuevas caractersticas o nuevos requerimientos que puedan ser soportados por la arquitectura definida en principio. Servicio en un nodo Varios nodos El servicio debe ser completamente escalable. El grupo de recursos puede estar en lnea a travs de varios nodos, de forma que se puedan ejecutar diversas instancias del servicio simultneamente.

QoS Con la implantacin de calidad de servicio (QoS), es posible ofrecer ms garanta y seguridad para las aplicaciones avanzadas, una vez que el trfico de estas aplicaciones pasa a tener prioridad en relacin con aplicaciones tradicionales. As, una faja de ancho de banda, dentro del canal de comunicacin, es reservada para que, en el caso de congestionamiento, determinados tipos de flujos de datos o aplicaciones tengan prioridad en la entrega.

La calidad del servicio toma importancia en la prestacin del servicio de streaming para aligerar la descarga y ejecucin de audio y vdeo en la web lo cual permite que esta tarea se realice de una manera ms rpida y que podamos ver y escuchar su contenido durante la descarga.

Como parte del diseo de la arquitectura deben estimarse los recursos del servidor necesarios para la prestacin de los servicios, de acuerdo a si se desea hacer una implementacin por zonas

Uso de la CPU Uso de memoria RAM Espacio de disco Red (Direccin IP e interfaz de red de la zona global) Cantidad de peticiones por segundo Tiempo para responder una peticin (Depende de la cantidad de peticiones concurrentes) Velocidad de transferencia Peticiones fallidas

Para asignar los recursos necesarios para la prestacin de cada servicio es prioritario realizar el plan de pruebas de rendimiento y a posteriori al desarrollo asignar los recursos para la prestacin ptima del servicio.

Tipo de Servidor Web Para la definicin del servidor Web ms adecuado para el servicio se deben tener en cuenta las siguientes mtricas:

Tipo de portal que se va servir (Estticos, Dinmicos, Dinmicos con BD) Cantidad de peticiones por segundo Velocidad de transferencia requerida Latencia mnima para ptimo funcionamiento

Para ello se van a asignar unos pesos que tienen un valor entre -10 y 10, que indican el tipo de servidor Web que se debe de usar. Valor negativo para Apache y positivo para Lighthttpd. Al final se suman los pesos de cada mtrica y el valor final determina cual es el tipo de servidor Web que se debe usar.

Tipo de Web Galera de fotos Blog Streaming de audio y video Aplicacin Web Pgina con contenido esttico Request por segundo(esperadas) 1 a 20 21 a 40 41 o ms Velocidad de transferencia Galera de fotos (0 kB) Blog (0 kB) Portal con Joomla (0 kB) Streaming de audio y video (0 kB) Aplicacin Web (0 kB) Pgina con contenido esttico (0 kB) Latencia Crtica (< 1ms - 100ms) Baja (100ms - 200ms) Baja Media (200ms - 400ms) Media (500ms) Alta Media (500ms -

Pes o 8 -2 -9 -9 10

-10 0 10

4 0 2 5 -2 0

10 8 5 0 -5

1000ms) Alta ( > 1000ms) -8

Si la suma de los pesos da un nmero negativo el tipo de servidor Web que se debe instalar es Apache, si la suma de los pesos da como resultado un nmero positivo el servidor Web recomendado es Lighthttpd. Dentro de las mtricas para medir el servicio se platean pruebas de desempeo donde se mide la velocidad del servidor para cargar archivos estticos, archivos dinmicos sin base de datos y archivos dinmicos con base de datos. Para esto se deben usar los siguientes archivos:

Archivo Esttico
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Webserver test</title> </head> <body> This is a webserver test page. </body> </html>

Archivo dinmico sin base de datos

echo <html><head><title>Php</title></head><body>; for($i=0;$i < 50; $i++) { echo Numbers $i: . rand()*rand(); } echo </body></html>; ?>

Archivo dinmico con base de datos

<html> <head><title>Php+MySQL</title></head> <body> $link = mysql_connect("localhost", "USERNAME", "PASSWORD"); mysql_select_db("DATABASE"); $query = "SELECT * FROM TABLENAME"; $result = mysql_query($query); while ($line = mysql_fetch_array($result)) { foreach ($line as $value)

{ } print "$value\n"; } mysql_close($link); ?> &lt;/body&gt; &lt;/html&gt;

A partir de estos archivos se generarn las pruebas de estrs haciendo uso de ab (Software especializado de Apache para realizar pruebas de estrs) y del software de monitoreo de recursos Munin. La arquitectura que se propone debe permitir alcanzar a mediano plazo los requerimientos de latencia, concurrencia, escalabilidad y tolerancia a fallos. Cuando la arquitectura para el servicio est diseada, esta requiere ser emulada en un ambiente de pruebas controlado y realizar una prueba de estrs.

7. SERVICIOS BAJO VIRTUALIZACIONES

Como resultado del estudio de requerimientos de la comunidad universitaria y en general los servicios establecidos desde la seccin Web se definieron ciertos servicios web los cuales son clasificados como se muestra a continuacin dependiendo las consideraciones sobre virtualizaciones como sigue, se debe tener en cuenta las siguientes consideraciones:

Migraciones:

Registro y control (SV) Vicerrectora administrativa (SV) Vicerrectora acadmica (SV) Planeacin (SV) Licitaciones y contratacin (SV) Relaciones internacionales (SV) Ilex (SV) Revistas (SV)

Desarrollos:

Vicerrectora de investigaciones (SV) Vicerrectora de responsabilidad social y bienestar universitario (SV) Biblioteca (SV) Acreditacin (SV)

Mantenimiento:

Auditorios (SV) Programas (SV) Comunicaciones (SV)

Servicios Web propuestos del Estudio de requerimientos de la Comunidad Universitaria:

Conferencias y actividades acadmicas. (SV)

Espacio para temas especficos acadmicos y cientficos. (SA) Blog, contenidos acadmicos categorizados a cargo de profesores (SA)(SD) (CB) Espacio para publicar contenidos, previa autorizacin. (SA) Biblioteca digital. (SA) Cursos virtuales gratis. (SA)(SD)(CB) Contenidos de cursos virtuales gratis, disponibles para descargas. (SA) Enlaces de tecnologa, revistas (SA) Aulas interactivas con posibilidad de acceso, permite entrar sin estar registrado. (SA)(SD) Espacio para informacin exclusivo de estudiantes. (SV) Dependiendo el enfoque puede ser (CB) Pagina exclusiva para informacin del rector. (SV) Informacin de Becas (SA) Informacin de prcticas y empleo (SA) Informacin de deportes, agenda deportiva, zonas recreativas del campus (SA) Informacin de contacto de profesores (SA) Chat de contacto, con profesores (SA) Agenda cultural (SA) Informacin de eventos (SV) Pagina de complementos web, para estar informado (SA) Un sitio con actividades de aprendizaje interactivo (SA)

Otras propuestas de servicios:

Libros electrnicos (SA) Encuestas en lnea de carcter informativo que permita conocer la comunidad que vista (SA) Sitio de la imagen institucional (SV) Sitio de ubicacin geogrfica. Nota: si es para cumplir directriz de gobierno en linea (SV) si es un aplicativo de recorridos virtuales (SA) Sitio emisora (SV)(SD)(CB)

Sitio de preguntas frecuentes (SV) Sitio con informacin regional y de la ciudad (SA) Sitio Web de polticas o consideraciones legales (SV)

8. CONSIDERACIONES FINALES
8.1 Optimizaciones de la Arquitectura Web a Futuro
En esta seccin se partir de que ya se han establecido los diferentes sistemas que permiten la optimizacin de los servicios, y la arquitectura establecida es ptima para las aplicaciones actuales. Poseidon, corriendo en un solo servidor El portal y los servicios web empezaron alojados sobre un solo servidor, cuya arquitectura se vea similar a la siguiente:

Sin embargo una vez el trfico empieza a incrementarse se cae pronto en una contesin de recursos por parte de cada uno de los servicios de software del servidor. El servidor web Apache y el servidor de base de datos MySQL intentan acaparar todo el servidor para ellos mismos, por lo cual mientras ambos estuvieran sobre el mismo servidor deberan luchar por los recursos (CPU, RAM). Perseo, separando la base de datos En el cambio de Poseidon a Perseo la primera optimizacin de fondo que se realiz fue la separacin de la base de datos del mismo servidor, evitando as la lucha de recursos mencionada. Ahora bien, este cambio requiere que a nivel de aplicaciones se realicen los cambios para que apunten al nuevo servidor, as pues las aplicaciones que apunten a localhost o a una direccin IP deben apuntar a Poseidon (quien hasta el momento es el servidor de base de datos).

Tambin un cambio significativo consisti en la implementacin de un balanceador de carga para distribuir el procesamiento entre dos replicas de Perseo. Esto permite que se mejore el rendimiento de las aplicaciones.

Adicionalmente es importante contemplar no solo un servidor de base de datos sino un clster que por medio de balanceo de carga y replicacin atienda las peticiones. Consideraciones de optimizacin en este punto: Si bien el desarrollo de servicios web con direcciones IP quemadas dentro del cdigo es una prctica de programacin poco recomendada la infraestructura de la Universidad es estable, por lo que puede establecer polticas para los espacios de direccionamiento internos, un pool de direcciones para servidores de bases de datos y otro pool para servidores web. Si se establecen direcciones IP dentro del cdigo se evita al servidor web realizar bsquedas DNS para las conexiones con el servidor de base de datos agregando latencia (aunque sea minscula) a la ejecucin del cdigo. Ahora bien, establecer direcciones dentro del cdigo es una forma. Otra alternativa es conservando los nombres de host en la aplicacin, pero en la tabla de direccionamiento interno de cada servidor web asignar a los nombres de host la direccin IP correspondiente al servidor de base de datos. Perseo, separando el contenido esttico

Una de las principales recomendaciones de rendimiento expuestas por GT-Metrix y Yahoo es el uso de un CDN (Content Delivery Network). Una red de distribucin de contenido (CDN) es lo que suelen usar las grandes compaas de Internet para agilizar la distribucin de archivos estticos (imgenes, hojas de estilo, javascripts, multimedia...). Las CDNs permiten tener contenidos replicados en mltiples servidores por todo el mundo, acelerando la descarga de los mismos de cara a los clientes, puesto que stos siempre se sirven desde la ubicacin ms cercana al usuario. En el caso de la Universidad, si bien disponer de varios servidores en el mundo dedicados solo para alojar archivos estticos no es viable en funcin de la mejora del rendimiento, si es posible disponer de un solo servidor dedicado exclusivamente a los archivos estticos. Esta mquina adicionalmente debe tener un servidor web no tan robusto como Apache sino un servidor ligero y optimizado para contenido esttico.

Consideraciones de optimizacin en este punto: Segn las pruebas realizadas sobre el rendimiento de servidores web para archivos estticos, NGINX es el servidor que mayor cantidad de archivos puede servir con la menor cantidad de recursos frente a otros sistemas. Este servidor de archivos estticos o tambin denominados media debido a que generalmente son archivos multimedia, debe tener un nombre de host propio (sugerimos media.utp.edu.co) para que los nuevos servicios tengan un soporte nativo a estos contenidos. Estos archivos estticos preferiblemente dentro de servidor deben conservar la estructura propuesta en estudios anteriores:

/media.utp.edu.co /Proyecto /css /js /ima /video /docs Cache, no se debe procesar lo ya procesado Una vez se ha separado el procesamiento, las bases de datos y el contenido se debe considerar agilizar la respuesta de los servicios haciendo uso de memorias cache. Estos servidores se encargan de comprobar si la solicitud del cliente ha sido servida ya en algn momento y se encuentra en su memoria la respuesta. En caso positivo el mismo se encarga de servir al cliente la informacin, evitando as el paso hasta el servidor web y que este realice las consultas o procesos junto con el servidor de base de datos. Esta cache de informacin se debe realizar a nivel de aplicacin (cache de informacin obtenida ya sea de base de datos o como resultado de procesamiento) y a nivel de archivos estticos que se sean de frecuente uso.

Escalamiento

Implementacin de balanceo de carga, redundancia y clster Una vez finalizada la fase de separacin de las lgicas en procesamiento, base datos, contenido y memoria temporal es cuando realmente empieza el proceso de escalamiento. Pues como tal dejarn de aadirse recursos dedicados a establecer ms capas ya que los recursos se destinarn para promover el crecimiento de las capas ya establecidas. Para esto se hace uso de los balanceadores de carga quienes se encargan de distribuir el uso de los recursos de cada unas de las capas. Estos recursos adicionales entonces se involucran como replicas de los servidores ya existentes. Por ejemplo dos servidores web, dos servidores de bases de datos, quienes contienen la misma informacin, cuando entra en funcionamiento el balanceador de carga, ste distribuye los clientes entre ellos manteniendo el trabajo que tiene cada uno de forma uniforme lo que incrementa el rendimiento.

Es importante notar que la implementacin del clster de base de datos, balanceo de carga y servidores web solo es necesaria cuando el rendimiento de cada servidor individual empieza a degradarse en funcin de los usuarios que est atendiendo. Para determinar el rendimiento de los servicios se ha establecido un plan de pruebas (Anexo). Ahora bien, no es posible hacer un estimativo del punto en que es necesario el despliegue del clster pues la respuesta de rendimiento va directamente ligada al rendimiento de las aplicaciones y servicios instalados en el servidor.

Consideraciones de optimizacin en este punto: Prioridad de memoria RAM antes que procesadores veloces. Procesadores rpidos no necesariamente indican un buen rendimiento de los servicios que se encarguen a la arquitectura, especialmente debido a que el 90% del tiempo se destina a la espera de salida o entrada en disco. Una posible salida es implementar discos ms rpidos, sin embargo en costos es mucho ms barato comprar mayor memoria RAM. Si se dispone entonces de varios servidores, el primer lugar para poner la memoria RAM se encuentra en el servidor de base de datos. Si es posible, se debe obtener suficiente memoria RAM para completar el servidor. Un caso de xito de esta implementacin - La base de datos de LJWorld.com - incluye ms de medio milln de artculos de prensa que data de 1989 - est por debajo 2GB. A continuacin, el segundo lugar indicado para memoria RAM es el servidor Web. La situacin ideal es que el servidor web nunca tuviera que recurrir a swap. El escalamiento vertical debe prevalecer sobre el horizontal Se debe notar que con el paso del tiempo algunos equipos del clster pueden empezar a considerarse obsoletos o de menor rendimiento que los equipos actuales, ahora bien, en el momento de mejorar el clster se debe agregar nuevo hardware sin con ello remplazar el antiguo. Estos equipos adicionales aunque no tan potentes como los nuevos agregan poder de procesamiento al clster de equipos ms actuales.

8.2 Optimizaciones a nivel de Software

Es muy importante que se adopten las siguientes sugerencias para la puesta en marcha de aplicativos escalables, debido a que la escalabilidad no solo se da en el tipo de hardware usado tambin se da en el mbito de todas las fases que cumple un desarrollo formal de software. Se recomienda tambin que se llenen los formatos sugeridos por el grupo de arquitectura web. Fase de Anlisis

Oriente el anlisis a una arquitectura de software como MVC, esta permite separar las capas lgicas de su aplicacin similar a como lo hacen los modelos de escalamiento planteados para la universidad

Fase de Diseo

Adapte el diseo de las aplicaciones a la arquitectura web que se encuentre en el momento establecida en la Universidad

Si el servicio que se est planteado debe comunicarse con otros aplicativos se deben establecer Apis de comunicacin, esta API debe ser estable y evitar sus cambios a menos que se considere la retrocompatibilidad por lo cual se debe establecer desde el principio las direcciones de acceso a ella.

Acerca del API se debe considerar:

Adopcin de protocolo de autentificacin en API oauth (http://oauth.net/) Determinar el acceso de usuarios externos a un lmite de peticiones por hora Algunos aplicativos son de permanencia, en caso tal se debe pensar en ellos con una visin de permanencia de varios aos para tomar decisiones acerca de:

Si la aplicacin va a almacenar muchos datos se debe optar por una base de datos no relacional tipo mongodb (http://www.mongodb.org/). Si el aplicativo es permanente el acceso a las url debe establecerse para que no sean cambiadas. La utilizacin de una autentificacin centralizada de usuarios en los aplicativos (http://forgerock.com/openam.html)

Fase de Desarrollo Uso de cache en el desarrollo (http://memcached.org/)

Recomendaciones de configuracin del memcache http://www.facebook.com/note.php?note_id=39391378919&ref=mf Tener en cuenta las siguientes reglas en las vistas de las paginas http://developer.yahoo.com/performance/rules.html Uso de imgenes como sprites (http://www.kabytes.com/programacion/tutorial-basico-sobre-css-sprite/) Optimizacin de las consultas a base de datos (http://boozox.net/mysql/20consejos-para-mejorar-tu-mysql-que-quizas-no-conocias/) Cuando se intenta cargar archivos con un tamao mayor a 20MB el servidor realiza una interrupcin para leer el archivo, esto lo realiza para todos los procesos que estn corriendo en mquina, y hasta que no termine de leer el archivo l no suelta el recurso. Lo que se recomienda es que se lean segmentos de archivo de 1024 kilobytes as no se interrumpen los otros procesos.

Fase de pruebas A cada mdulo se le debe hacer una prueba de carga, esto con el fin de detectar cuellos de botella de los aplicativos. A lo largo del estudio se estableci un formato de pruebas, cada servicio debe contar con el diligenciamiento de ste como soporte al proceso de desarrollo e implementacin. En la fase de inicio de produccin: Monitoreo constante de los aplicativos para detectar si se necesita apartar ms recursos.

Fase de produccin Como recomendaciones de implementacin de los servicios se deben tener en cuenta los requerimientos propios de cada uno y los resultados de las pruebas. Sin embargo si el servicio cumple con unos criterios se pueden establecer ciertas optimizaciones. Si el servicio hace uso de PHP debe adems utilizar eAccelerator (acelerador de PHP). Cada vez que un script PHP se accede, PHP generalmente analiza y compila las secuencias de comandos. Cuando se instala eAccelerator, ste optimiza el cdigo de bytes compilado y lo cachea. Al tener accesos posteriores al archivo se tendr acceso a la cach la cual fue generada. Esto evita que se compile cada archivo cuando es abierto y optimiza el tiempo de ejecucin hasta en un 40%. Requerimientos: php4 or php5 autoconf automake libtool m4 make

Configuraciones en los servidores: La configuracin por defecto de Apache o Lighttpd debe modificarse para optimizar al mximo el nmero de solicitudes por segundo. Esta configuracin debe ajustarse realizando pruebas de forma similar a como se realiz en la seccin de Pruebas Apache Vs Lighttpd.

8.2.1 Buenas prcticas en Fase de Desarrollo

Tomando como base http://developer.yahoo.com/performance/rules.html recomendaciones: Minimizar nmero de peticiones HTTP

el se hacen las

documento siguientes

La mayor cantidad del tiempo que utiliza el usuario al ingresar a un sitio se destina en la descarga de los componentes de la pgina: Hojas de estilo, imgenes, scripts o flash. Reducir el nmero de componentes de la pgina reduce el nmero de peticiones y por lo tanto disminuye el tiempo que tardar en cargar la pgina. Para esto una alternativa es simplificar el diseo de la pgina o utilizar tcnicas sencillas que permitan tener un diseo rico pero minimizando el nmero de peticiones, para ello se puede hacer uso de Sprites CSS, mapas de imagen, o combinar todos los javascript bajo un slo archivo. Aadir cabecera http://developer.yahoo.com/performance/rules.html#expires Hay dos aspectos a esta regla:

Expires

Para los componentes estticos: Implementar "Never expires" Para los componentes dinmicos: Utilizar un encabezado adecuado segn los cambios que pueden sufrir el sitio

Comprimir con Gzip El tiempo necesario para la transferencia de una solicitud HTTP y la respuesta a travs de la red puede reducir de forma significativa por las decisiones adoptadas en el servidor. Es cierto que la velocidad del usuario final de ancho de banda, el proveedor de servicios de Internet, la proximidad a los puntos de interconexin de cambio, etc. estn fuera del control del equipo de desarrollo. Pero hay otras variables que afectan a los tiempos de respuesta. En esta recomendacin la compresin reduce los tiempos de respuesta al reducir el tamao de la respuesta HTTP. A partir de HTTP/1.1, el navegador, indica su posibilidad de aceptar la compresin de la cabecera Accept Encoding (gzip, deflate) Si el servidor web, ve a esta cabecera en la solicitud, puede comprimir la respuesta usando uno de los mtodos indicados por el cliente. El servidor web, notifica al navegador, a travs de la cabecera Content-Encoding (gzip) en la respuesta y enva el contenido comprimido. Colocar los CSS al principio

Disponer las hojas de estilo en el HEAD permite que la pgina sea dibujada progresivamente. Esto es especialmente importante para las pginas con mucho contenido y para los usuarios en las conexiones a Internet ms lentas. Colocar los Script al final Una caracterstica de la descarga de scripts es que no permite realizar descargas paralelas hasta que esta sea finalizada. La especificacin HTTP/1.1 sugiere que los navegadores no descarguen ms de dos componentes en paralelo por nombre de host. Las imgenes si pueden descargarse de varios nombres de host, permitiendo que ms de dos descargas se produzcan en paralelo. Mientras que un script se est descargando, sin embargo, el navegador no inicia ningn tipo de descarga, incluso de hosts diferente. Hacer que los JavaScripts y CSS sean archivos externos (no dentro del cdigo) Si JavaScript y CSS estn entre lneas en los documentos HTML se descargan cada vez que se solicita el documento HTML. Esto reduce el nmero de peticiones HTTP que son necesarias, pero aumenta el tamao del documento HTML. Por otro lado, si el cdigo JavaScript y CSS estn en archivos externos en cach por el navegador, el tamao del documento HTML se reduce sin aumentar el nmero de peticiones HTTP. Configurar los Etags Etiquetas (ETags) son un mecanismo que los servidores web y navegadores utilizan para determinar si el componente en la cach del navegador coincide con la del servidor de origen. (Un componente puede ser: imgenes, scripts, hojas de estilo, etc.). ETags se agreg al estndar para proporcionar un mecanismo para la validacin de las entidades que es ms flexible que la fecha de ltima modificacin. Las anteriores son solo algunos puntos de sugerencia, para mayor informacin se debe consultar el documento base: http://developer.yahoo.com/performance/rules.html

8.3 Estadsticas de servidores

Para la recoleccin de informacin estadstica acerca del uso del recurso se estudiaron diversas herramientas, en busca de utilizar la que mayor informacin brindar y permitiera obtener histricos e informes. Se estuvo recopilando informacin y se implementaron varias herramientas gratuitas o de software libre que permitieran recolectar estadsticas de uso de CPU y memoria RAM en servidores.

A continuacin se describen las ventajas y desventajas de las herramientas analizadas para recoleccin de la informacin estadstica: Nagios: Fcil de instalar, no hace uso de base de datos, no genera grficos. Hyperic: Instalacin compleja, hace uso de java, consume mucho CPU y memoria RAM. Cacti: Instalacin fcil, usa base de datos MySQL, complejo de usar, no presenta muchas opciones de grficas, aunque se pueden agregar con plugins. Pandora FMS: Parecido a Cacti, complejo de usar. Munin: Fcil instalacin, no requiere base de datos, presenta grficas de uso de CPU, memoria, disco duro, procesos de apache y consultas a base de datos.

No tiene pantalla de logueo, no guarda historial por ms de un mes, no tiene grficos detallados por horas (pero es posible implementarlo). Del anlisis se concluye que la mejor herramienta para el monitoreo de estadsticas para el servidor Poseidon es Munin por su fcil instalacin, manejo y flexibilidad a la hora de agregar nuevas caractersticas. Munin: Es un programa que permite monitorizar uno o varios equipos. Adems, presenta la informacin a travs de un servidor web, est hecho en perl y permite el uso de plugins, lo cual lo hace realmente verstil. Tambin muestra una gran cantidad de informacin mediante unas grficas creadas con la librera (biblioteca library) grfica RRDtool. Instalacin Bajo Solaris: http://munin-monitoring.org/wiki/SolarisInstallation Bajo Linux: http://www.n1mh.org/weblog/2006/01/30/monitorizando-redes-conmunin/

8.4 Pruebas de Apache vs. Lighttpd sobre Wordpress (MediaWiki y Atesa)

Basados en el mtodo propuesto por http://webserverhacks.com/performancetests/wordpress-lighttpd-vs-apache-httpd-perfomance-test/ Las pruebas de rendimiento de Apache vs. Lighttpd se realizo bajo las siguientes condiciones: Maquina Host para pruebas HP Compact dc58000

Procesador Intel Core 2 Duo E8400 @3.00 Ghz 4 Gb Memoria Ram Sistema Operativo Window Vista SP 1

Sobre esta mquina se corre la maquina virtual con las siguientes caractersticas:

1 procesador x86 Memoria 1024 Gb Sistema Operativo OpenSolaris 2009.6 con instalacin por defecto --> Se descarta debido a problemas Sistema Operativo Debian Recopilacin de datos con Munin

Primera prueba Las primeras pruebas se plantearon bajo una instalacin de OpenSolaris, pero al momento de la instalacin de Munin, el sistema solicit paquetes por medio de FTP y debido a que las conexiones FTP estn bloqueadas desde afuera no se logro realizar la instalacin. Por lo tanto se opta por la instalacin de Debian que gracias a su instalacin por paquetes agiliza el proceso. La pgina de carga ser un post Wordpress Metodologa Para cada prueba se realizo una copia de la imagen de la instalacin base para conservar las mismas caractersticas sobre cada prueba. A cada servidor se le instalo lo siguiente: Prueba 1

Servidor Apache: se configur con mod_rewrite, Mysql como servidor de bases de datos. Servidor Lighttd: con Mod_Magnet basado en Tempe.st method. Este usa Lighttpd en conjunto con el modulo Mod_Magnet , que es para Lighttpd una alternativa a Apaches mod_rewrite y .htaccess . Mysql como servidor de bases de datos. Servidor Nginx: Nginx sin Mod_rewrite. Mysql como servidor de bases de datos. Prueba 2

Servidor Apache: se configur con mod_rewrite, Mysql como servidor de bases de datos. Adicionalmente con fastcgi y eacelerator Servidor Lighttd: con Mod_Magnet basado en Tempe.st method. Este usa Lighttpd en conjunto con el modulo Mod_Magnet , que es para Lighttpd una alternativa a Apaches mod_rewrite y .htaccess . Mysql como servidor de bases de datos. Adicionalmente con fastcgi y eacelerator

Datos a servir Para la prueba de ambos servidores se realizo una instalacin de Wordpress 3.1 con el plugin de Buddypress, Wordpress Super Cache plugin y Super Cache Glib Compression (Php.ini zlib.output_compression = 9). Adicionalmente la informacin carga est compuesta por: HTML: 57 kb CSS: 42 kb Jquery: 116 kb Imagenes: 759 kb Total: 974 kb Script para prueba Se utilizo el siguiente script para cada prueba. La primera prueba es de 100 request con 5 usuarios concurrentes, luego 100 request con 10 usuarios concurrentes y finalmente 100 request con 50 usuarios concurrentes, cada prueba se realiza tres veces y se tabulan los resultados. A estos resultados se les adjuntan las grficas de uso de recursos de Munin. (Resultados de las Pruebas, Anexo N3).
#!/bin/bash if [ -n "$1" ] then cont=1 for N in 100 do for C in 5 do if [ $N -gt $C ]; then echo echo "Benchmarking... $cont ($N HTTP requests, simulating $C concurrent users)" echo "Benchmarking... $cont ($N HTTP requests, simulating $C concurrent users)" >> $2.log echo "Comando usado: ab -n $N -c $C $1" >> $2.log ab -n $N -c $C $1 >> $2.log echo "" >> $2.log echo "" >> $2.log echo "Sleeping 5 seconds..." ; sleep 5 cont=$(($cont+1)) echo fi done done else # display error message on wrong usage echo echo "Usage: script [hostname to benchmark with http:// and trailing /] [output file .png] "

fi

echo "e.g: ./script http://example.com/ /home/myhome/graph.png " echo

8.5 Servidor Web

Bajo las pruebas de rendimiento que se realizaron de Apache VS Lighttpd sobre Wordpress (MediaWiki y Atesa) se proponen los siguientes servidores web. Servidor web El servidor web que hasta el momento se ha utilizado de forma habitual es Apache, el cual es un servidor robusto para aplicaciones que tienen alto trfico y requieren de alto grado de disponibilidad. Sin embargo como parte del estudio de arquitectura se presenta un servidor web alterno. Cherokee De las caractersticas ms interesantes que se aprecio de este servidor web fue su correcto funcionamiento para pocas solicitudes concurrentes (<20), tambin para cantidades significativas de peticiones siempre se responde a los clientes a diferencia de Apache que con la configuracin por defecto rechaza a solicitudes concurrentes. Cherokee adems tiene facilidad de administracin, pues tiene una interfaz web que permite ajustar todas las caractersticas del servidor sin necesidad de detener el servicio. Finalmente est orientado a la escalabilidad del recurso pues permite que los intrpretes de scripts que sean necesarios sean ejecutados desde dispositivos distintos al local. Servidor archivos estticos (lighttpd) Lighttpd es un servidor web ligero especialmente diseado para servir gran cantidad de archivos estticos. Este servidor esttico debe responder las solicitudes preferiblemente bajo un dominio determinado (usar un (sub)dominio para contenido esttico). Usar un (sub)dominio para contenido esttico Segn las condiciones del servidor, un servidor web (comnmente en la Universidad se ha utilizado Apache) solo puede atender simultneamente a un nmero limitado de clientes. Cuando un servidor web no puede mantener todas las peticiones de un sitio por s solo, una buena forma de aliviar la carga en este, es utilizar un (sub)dominio

adicional en un servidor aparte (O tambin este servidor puede estar sobre el mismo dispositivo pero haciendo uso de un servidor ligero). En este se hospeda todo el contenido esttico, como: Archivos relacionados a la plantilla: imgenes, archivos de javascript y hojas de estilos Imgenes usadas para complementar el contenido Archivos complementarios como pdf, mp3, videos o cualquier otro archivo que no sea generado dinmicamente La idea principal es contar con un segundo servidor que utilice muy pocos recursos y que responda con los encabezados (headers) apropiados para que cada cliente mantenga estos archivos en su cach local. Al hacer esto, se pueden reconocer algunas ventajas: Menor carga para el servidor web

La mejor optimizacin se logra si se cuenta con un servidor adicional para contenido esttico, esto permite quitar carga del servidor principal, encargado de generar las pginas dinamicas. Este otro servidor debe ser ms sencillo que el principal, la sugerencia del estudio segn las pruebas de rendimiento son Lighttp o NGnix. Para lograr este balanceo de carga se debe en el cdigo hacer los llamados de los archivos estticos a este subdominio. Por supuesto al llegar a tener un trfico mucho mayor se llegar a necesitar un balanceo de carga real, con un proxy en frente de los servidores web, y mover el contenido esttico a un CDN profesional como Amazon S3/CloudFront o similares. Libre de cookies

Cuando se enva una cookie al usuario, su navegador la enviar junto a todas las peticiones, sean pginas o imgenes. Esto es un problema, ya que har que las peticiones/paquetes sufran mayor fragmentacin. Yahoo hizo un estudio sobre el impacto del tamao las cookies y el incremento en el tiempo de respuesta del servidor, de all se concluye que es mejor reducir al mnimo posible el tamao (si usas un CMS esto es complicado), o an mejor que los recursos que no necesiten de estas estn en un dominio aparte, libre de cookies. Descargas paralelas

La especificacin del HTTP/1.1 sugiere que cada navegador limite el nmero de descargas simultneas a dos, para un mismo host. Si se utiliza un dominio adicional, el cliente podr realizar dos descargas paralelas adicionales, reduciendo el tiempo necesario para cargar el sitio. Tampoco significa que se deba agregar varios subdominios con tal de tener muchas descargas paralelas, el

incremento en consultas DNS y uso de conexiones adicionales degrada la ventaja de que se hagan en paralelo.

8.5.1 Sistema Operativo

La eleccin del sistema operativo en el servidor web puede conservarse segn las polticas actuales de la seccin de administracin de la red. Teniendo en cuenta las siguientes recomendaciones: Configuraciones importantes en el sistema operativo Actualmente las instalaciones de nuevas libreras o caractersticas al sistema operativo se realizan descargando el software correspondiente y luego realizando el proceso de compilacin. Proceso de compilacin Ventajas de compilar las aplicaciones: El software se compila optimizado para el dispositivo por lo que en la mayora de los casos, funcionar/cargar ms rpido que uno precompilado. Se obtiene mejor uso de los recursos. Puedes desactivar opciones del programa para que no estn disponibles, bien sea porque no se necesitan o tardan en cargarse. Desventajas de compilar las aplicaciones: Tarda mucho ms tiempo para obtener un programa ya que el proceso de compilar requiere 100% el uso del CPU. Y cuando hay disponibles actualizacin de los paquetes hay que volver a compilar el paquete de nuevo. No todos los programas muestran mejoras al compilarse (Funcionan igual que un pre compilado). Ocupa el doble de espacio en el disco, el paquete con los cdigos fuentes y el binario compilado (Esto es opcional ya que se puede borrar los cdigos fuentes una vez generado el binario).

Los costos son mayores puesto que el destinar el personal especializado para realizar esta labor consume tiempo que puede ser utilizado en otras labores ms importantes. Software pre-compilado El nmero de opciones disponibles en la fase de configuracin se multiplica en cada versin, con software pre-compilado solo es necesario especificar las opciones que realmente necesiten configurarse. La instalacin tarda menos tiempo. Solo es necesaria la ejecucin de un comando y el sistema descarga e instala la aplicacin. No es necesario sacar de servicio los dispositivos durante algn tiempo mientras se realizan las instalaciones. Desventajas Pueden instalarse servicios y aplicaciones no necesarias junto con la aplicacin principal El software no necesario consume recursos de procesador y almacenamiento. Esto es un factor importante a considerar en un servidor de alto rendimiento (aunque tambin se debe definir exactamente qu cantidad de recursos se estn consumiendo) En general no hay necesidad de que los administradores del servidor compilen su propio sistema operativo. Anteriormente, las aplicaciones concentraban un gran esfuerzo en exprimir los ciclos de cada operacin debido al reducido poder de procesamiento disponible, as pues procuraban eliminar la mayora de los mdulos no necesarios del ncleo. Ahora bien, si la ganancia que se obtiene es del diez por ciento en rendimiento del sistema y se necesita un ingeniero dedicado durante una semana, entonces, suponiendo que un servidor cuestan menos que tres meses de un ingeniero dedicado a esta labor, se est perdiendo tiempo y dinero. Slo cuando se llega a un nivel de optimizacin del sistema en el cual ese tiempo se ahorrara en dinero la opcin de compilar el sistema operativo puede llegar a ser considerable. En general para casi todas las aplicaciones, las compilaciones por defecto funcionan bien. Hay un par de casos especiales en que pueda necesitar el soporte de un ncleo especfico (como el uso de Physical Address Extension (PAE), o kernel HTTP server).

Conclusin acerca del software compilado o precompilado

Debe utilizarse un gestor de paquetes, el gestor sugerido en el caso de utilizarse un sistema operativo: Solaris/Open Solaris: IPS Gestin de software + paquetes Instalacin y actualizacin online Verificacin y chequeo por dependencias Herramienta grafica Compatible con el modelo anterior SVR4 Permite creacin de repositorios locales Crear y administrar varios entornos de arranque en el sistema

9. CONSIDERACIONES FINALES

En la tarde del 30 de Septiembre de 2010, el servidor esttico Lighttpd, comenz a servir el dominio http://media.utp.edu.co, esto permite en primer lugar agilizar la carga del contenido (dado que lighttpd es ms ligero que Apache) y en segundo lugar permite la descarga del contenido de forma paralela gracias a que se encuentra en otro dominio. La especificacin del HTTP/1.1 sugiere que cada navegador limite el nmero de descargas simultneas a 2, para un mismo host. Si se utiliza un dominio adicional, el cliente podr realizar 2 descargas paralelas adicionales, reduciendo el tiempo necesario para cargar el sitio. Tampoco significa que se deba agregar varios subdominios con tal de tener muchas descargas paralelas, el incremento en consultas DNS y uso de conexiones adicionales degrada la ventaja de que se hagan en paralelo. Con el uso del servidor ligero, el tiempo de carga de la pgina mejoro segn GTMetrix un 3%, y pas de cargar en 6 segundos a 1,92 segundos aproximadamente, el reporte entregado por GTMetrix puede detallarse a continuacin:

Paso a Perseo Una vez la pagina principal paso a ser atendida por el servidor web Perseo, el rendimiento aumento un 6%.

Implementacin de Expire Headers al lighttpd Finalmente siguiendo las recomendaciones de desarrollo, se implementaron las cabeceras de expiracin sobre el Lighttpd aumentando el rendimiento en un 2%.

Criterio de rendimiento Rendimiento (Performance) bajo Yslow

YSlow analiza cualquier pgina web y genera una calificacin para cada regla definida. Si la pgina tiene aspectos mejorables, la GTmetrix ofrece una lista de sugerencias con los cambios. Desde esta vista, se puede ver una lista de todos los componentes incluidos en una pgina web, as como su tipo, URL, fecha de expiracin, estado del gzip, tiempo de carga, tamao y ETag. Tambin permite ver las cabeceras de respuesta HTTP para cualquier componente. Bajo este aspecto el ltimo punto de optimizacin que se sugiere es la utilizacin de una red de entrega de contenido o CDN. Estas redes entregan el contenido esttico segn la ubicacin geogrfica de quien lo solicita, pero para efectos de la arquitectura web actual, es un punto que puede pasarse por alto. Conclusin final Desde el paso a Lighttpd, hasta el uso de las cabeceras sobre el mismo, el aumento del rendimiento de la pgina principal fue del 13%.

Comparacin del rendimiento de la pgina frente a otras universidades Tomando como base de comparacin las tres universidades que se encuentran al frente del ranking de webometrics: Universidad Nacional de Colombia, Universidad de Antioquia y Universidad de los Andes, se presenta a continuacin las comparaciones de rendimiento (ver grafico).

Universidad Tecnolgica de Pereira frente Universidad Nacional: Yslow: 32%+ PageSpeed: 15%+ Universidad Tecnolgica de Pereira frente Universidad de antioquia: Yslow: 20%+ PageSpeed: 7%+ Universidad Tecnolgica de Pereira frente Universidad Nacional: Yslow: 13%+ PageSpeed: 7%+

ANEXO N1 FORMATOS DE DESCRIPCIN DE SERVICIOS ACTUALES

Blog UTP

Tipo ___ Infraestructura ___Administrativo _X_ Negocio ___ Apoyo

Descripcin Un blog, o en espaol tambin una bitcora, es un sitio web peridicamente actualizado que recopila cronolgicamente textos o artculos de uno o varios autores, apareciendo primero el ms reciente, donde el autor conserva siempre la libertad de dejar publicado lo que crea pertinente. Sin embargo los Blog de la UTP deben ajustarse a las condiciones de publicacin establecidas por el rea de desarrollo web. Habitualmente, en cada artculo de un blog, los lectores pueden escribir sus comentarios y el autor darles respuesta, de forma que es posible establecer un dilogo. No obstante es necesario precisar que sta es una opcin que depende de la decisin que tome al respecto el autor del blog. El uso o tema de cada blog es particular, los hay de tipo: periodstico, empresarial o corporativo, tecnolgico, educativo, polticos, personales. En la UTP la principal razn de estos blog es para la difusin de contenido acadmico.

Consumidores Este servicio est orientado a: Estudiantes: Como espacio de expresin y medio para la apropiacin del portal universitario Profesores: Difusin de contenidos acadmicos y contacto con estudiantes Comunidad universitaria en general (Administrativos, grupos de investigacin, dependencias de la universidad): Espacio para publicacin de informacin Requerimientos Este servicio requiere de lo siguiente: PHP versin 5.3 o superior http://www.php.net/downloads.php#v5

 MySQL versin 4.1.2 o superior http://www.mysql.org/ Wordpress 3.0 http://wordpress.org/download/ Apache versin 2.0 o superior http://httpd.apache.org/ Debe incluir mod_rewrite Servicio Media Servicio Cach

Responsables Las dependencias encargadas de dar soporte a este servicio son: rea de desarrollo web: Establece las polticas de publicacin, gestin de contenidos, control de usuarios y aspecto grfico. En general todo lo relacionado a la administracin del sistema del blog, que en este caso es wordpress. Adicionalmente en el rea de desarrollo web, debe existir una persona encargada de dar soporte a los usuarios y procurar el correcto funcionamiento de los blog. (Blog manager) Administracin de la red: Soportan todo el hardware y software necesario para el funcionamiento del blog, desde la administracin del servidor hasta el espacio en disco asignado. Tambin es su responsabilidad la actualizacin y mantenimiento del sistema operativo y los aplicativos citados en el apartado de requerimientos (excepto wordpress). Riesgos Este servicio puede enfrentar los siguientes riesgos: Nombre: Tipo de riesgo: ____ Red Descripcin del riesgo: Encargado afrontarlo: ____ Software ____ Administrativo

Wiki UTP

Tipo

___ Infraestructura ___Administrativo

_X_ Negocio

___Apoyo

Descripcin Un wiki, o una wiki, es un sitio web cuyas pginas web pueden ser editadas por mltiples voluntarios a travs del navegador web. Los usuarios pueden crear, modificar o borrar un mismo texto que comparten. WikiUTP es un espacio en el que profesores, estudiantes y toda la comunidad de la Universidad Tecnolgica de Pereira, adems del pblico en general puede aportar ideas y conocimiento. Se pretende ayudar al mejoramiento de la calidad acadmica de toda la comunidad universitaria mediante este espacio de fcil acceso para su consulta y edicin. Consumidores Este servicio est orientado a: Estudiantes: Como enciclopedias colaborativa con informacin til sobre su universidad Profesores: Espacio para publicacin de contenido acadmico Comunidad universitaria en general (Administrativos, grupos de investigacin, dependencias de la universidad): Espacio para publicacin de informacin pertinente y propia a la universidad Requerimientos Este servicio requiere de lo siguiente: PHP versin 5.1 o superior http://www.php.net/downloads.php#v5 Debe incluir librera estndar (SPL) Debe incluir Expresiones Regulares (Compatible con Perl) MySQL versin 4.1.2 o superior http://www.mysql.org/ MediaWiki 1.15.4 o superior http://www.mediawiki.org/wiki/MediaWiki/es Apache versin 2.0 o superior http://httpd.apache.org/ Servicio Media Servicio cach Responsables Las dependencias encargadas de dar soporte a este servicio son: rea de desarrollo web: Establece las polticas de publicacin, gestin de contenidos, control de usuarios y aspecto grfico. En general todo lo relacionado a la administracin del sistema del wiki, que en este caso es

MediaWiki. Adicionalmente en el rea de desarrollo web, debe existir una persona encargada de dar soporte a los usuarios y procurar el correcto funcionamiento del wiki. (Wiki manager) Administracin de la red: Soportan todo el hardware y software necesario para el funcionamiento del wiki, desde la administracin del servidor hasta el espacio en disco asignado. Tambin es su responsabilidad la actualizacin y mantenimiento del sistema operativo y los aplicativos citados en el apartado de requerimientos (excepto MediaWiki).

Riesgos Este servicio puede enfrentar los siguientes riesgos: Nombre: Tipo de riesgo: ____ Red Descripcin del riesgo: Encargado afrontarlo: ____ Software ____ Administrativo

Portal Institucional

Tipo ___ Infraestructura ___Administrativo _X_ Negocio ___Apoyo

Descripcin El portal institucional es la principal herramienta de publicacin, generacin de contenidos e informacin de la Universidad. Es el punto de partida para la mayora de servicios que presta la universidad por medio de la web como inscripcin de materias, estudiantes, cursos, blogs, wiki,

contrataciones entre otros. Para este aplicativo actualmente uno de sus principales requerimientos es mejorar su posicionamiento dentro del ranking de universidades webometrics. Consumidores Este servicio est orientado a: Estudiantes Profesores Comunidad universitaria en general (Administrativos, grupos de investigacin, dependencias de la universidad) Agentes externos (Otras universidades, personas, empresas, entidades pblicas)

Requerimientos Este servicio requiere de lo siguiente: Apache () Versin > 2.0 Servidor HTTP. Este servidor debe servir los archivos que se encuentran en el dominio http://www.utp.edu.co Mdulos Necesarios core mod_authn_file mod_authn_default mod_authz_host mod_authz_groupfile mod_authz_user mod_authz_default mod_auth_basic mod_dbd mod_include mod_filter mod_log_config mod_env mod_setenvif mod_ssl prefork http_core mod_mime

mod_dav mod_status mod_asis mod_cgi mod_cgid mod_dav_fs mod_negotiation mod_dir mod_actions mod_userdir mod_alias mod_rewrite mod_so mod_php5 mod_wsgi mod_deflate mod_expires mod_headers PHP (http://php.net) Version >= 5.2.3 Extensiones curl dom oci8 gd apxs2 zlib ldap mysql mysqli pgsql sockets ftp openssl http://php.net/pcre debe estar compilado con enable-utf8 y enable-unicode-properties para las funciones UTF-8. http://php.net/iconv es requerido para la traduccin UTF-8. http://php.net/mcrypt es requerido para la encripcin. http://php.net/spl es requerida por las libreras de core de kohana. Responsables Las dependencias encargadas de dar soporte a este servicio son: rea de desarrollo web: Proporciona todo el soporte a las aplicaciones (excepto los que se dirigen a app.server de los cuales est a cargo divisin de sistemas). Tambin del diseo, contenidos, informacin,

soporte a usuarios y todo lo relacionado con la pagina principal bajo el dominio www.utp.edu.co Administracin de la red: Soportan todo el hardware y software necesario para el funcionamiento de la pgina, desde la administracin del servidor hasta el espacio en disco asignado. Tambin es su responsabilidad la actualizacin y mantenimiento del sistema operativo y los aplicativos citados en el apartado de requerimientos. Riesgos Este servicio puede enfrentar los siguientes riesgos: Nombre: Tipo de riesgo: ____ Red Descripcin del riesgo: Encargado afrontarlo: Portal Atesa de Occidente ____ Software ____ Administrativo

Tipo ___ Infraestructura ___Administrativo _X_ Negocio ___Apoyo

Descripcin El portal de Atesa de occidente es una pgina contratada de un cliente externo al rea de desarrollo web de la Universidad Tecnolgica de Pereira. Consumidores Los principales usuarios del servicio son los clientes de la empresa ATESA Requerimientos Este servicio requiere de lo siguiente: PHP versin 5.1 o superior http://www.php.net/downloads.php#v5 MySQL versin 4.1.2 o superior http://www.mysql.org/ Lighttpd (http://www.lighttpd.net) Responsables Las dependencias encargadas de dar soporte a este servicio son:

rea de desarrollo web: Proporciona al cliente (Atesa) soporte para su aplicativo en aspectos como diseo e informacin publicada. Administracin de la red: Soportan todo el hardware y software necesario para el funcionamiento de la pgina, desde la administracin del servidor hasta el espacio en disco asignado. Tambin es su responsabilidad la actualizacin y mantenimiento del sistema operativo y los aplicativos citados en el apartado de requerimientos. Riesgos Este servicio puede enfrentar los siguientes riesgos: Nombre: Tipo de riesgo: ____ Red Descripcin del riesgo: Encargado afrontarlo: ____ Software ____ Administrativo

ANEXO N2 FORMATO DOCUMENTACIN DE NUEVOS SERVICIOS

CENTRO DE RECURSOS INFORMTICOS Y EDUCATIVOS FORMATO DOCUMENTACIN DE SERVICIOS WEB

Nombre: Fecha de Creacin: (dd/mm/aaaa): __ /__ /____

ID Servicio: Fecha de Modificacin: (dd/mm/aaaa): __ /__ /____

Versin: Historial de Documentacin:

Estado: __ Activo __ En desarrollo __ Retirado

1. Nombre del Servicio Se define un nombre representativo del Servicio Web que se documentar. 2. Objetivo General Se plantea el objetivo general que pretende cumplir el diseo del servicio que se est documentando donde ste se plantee de forma clara y precisa. 3. Objetivos Especficos Descripcin de varios objetivos especficos que tienen como meta definir estrategias que lleven al cumplimiento del objetivo general. 4. Tipo de Servicio ___ Infraestructura ___ Negocio ___ Apoyo ___ Administrativo

Nota: Para determinar el tipo de un servicio, se debe tener en cuenta que los Servicios de Negocio son servicios core de la Universidad, son vitales y propios del negocio, por ejemplo la Pgina principal de la universidad; los Servicios Administrativos son servicios que soportan los procesos de organizacin de la Universidad, por ejemplo Redmine; los Servicios de Apoyo son servicios que dentro del contexto de las aplicaciones proporcionan servicios a otros servicios. Es importante resaltar que la ausencia de estos servicios de apoyo no debe afectar a los aplicativos que los utilicen. Un ejemplo de estos servicios es el Memcached. Los Servicios de Infraestructura son servicios que dan soporte a nivel de todos los servicios de la Universidad,

tales como logging, auditora, seguridad, por ejemplo OpenAM. 5. Descripcin del Servicio Se describe el servicio con todas las caractersticas fundamentales que den una visin a los usuarios y desarrolladores del servicio definido. Se proporcionan todos los rasgos representativos del servicio para dar claridad sobre lo que se quiere brindar a los usuarios. 6. Justificacin del Servicio Se da un respaldo o una teora que fundamente la creacin del Servicio, es decir, la justificacin es la explicacin de por qu este servicio es definido, requerido y desarrollado en la Web. 7. Usuarios del Servicio Deben definirse los usuarios a los que est orientado este servicio, y porque es til este servicio para ellos, es decir, que prestaciones brindar el uso de este servicio y a quien va dirigido. 8. Lista de requerimientos Funcionales No Funcionales Evaluacin del servicio

Nota: La lista de requerimientos es la primera caracterizacin definida para especificar el funcionamiento del servicio, y as desarrollarlo de acuerdo al propsito que debe cumplir. Los requerimientos pueden ser funcionales que son las caractersticas necesarias para que el servicio funcione como debera y los requerimientos no funcionales aunque no determinan la prestacin del servicio si lo garantizan. Para especificar los requerimientos no funcionales debe completarse el siguiente formato de Especificacin de Requerimientos, donde se le da un peso a cada requerimiento para cada uno de los servicios. PESO/SERVICIO REQUERIMIENTOS Confiabilidad Disponibilidad Rendimiento Seguridad Escalabilidad Total (Peso de 1 a 5) (Peso de 1 a 5) (Peso de 1 a 7) (Peso de 1 a 5) (Peso de 1 a 5)

Para determinar el peso de un requerimiento para el servicio debe tenerse en cuenta la informacin que se cita a continuacin donde se define la equivalencia de cada peso del

requerimiento para el servicio.

CONFIABILIDAD: Capacidad del servicio para cumplir una funcin requerida, en unas condiciones y tiempo dados. Peso 1: El servicio no se ve enfrentado a cargas de estrs por lo que se garantiza el cumplimiento de su funcin continuamente. Peso 2: Peso 3: Este servicio se ve enfrentado a cargas de estrs slo en ciertos perodos de tiempo Peso 4: Peso 5: El servicio puede verse enfrentado a cargas de estrs durante largos perodos.

DISPONIBILIDAD: Uso adecuado del tiempo requerido por el usuario para que el sistema est disponible. Peso 1: Este servicio no afecta ningn proceso, en caso de incidentes puede considerarse en un ltimo lugar para su restablecimiento. Peso 2: No aplica Peso 3: Este servicio debe estar disponible en el menor tiempo posible, sin embargo su ausencia no afecta procesos importantes para el negocio. Peso 4: No aplica Peso 5: Este elemento debe estar disponible todo el tiempo pues de l dependen otros servicios importantes.

RENDIMIENTO: Practicidad en el rendimiento y cumplimiento de los tiempos de respuesta estimados para la ejecucin en lnea de procesos del sistema Peso 1: Servicio que no tiene requerimientos significativos en el uso de procesador, disco o memoria. Peso 2: Servicio que requiere un acceso constante a memoria. Peso 3: Servicios que requieren un uso constante de procesador. Peso 4: Servicio que requieren un uso constante de acceso a disco. Peso 5: Requiere uso constante de memoria y procesador. Peso 6: Requiere uso constante de procesador y acceso a disco. Peso 7: Este servicio debe aprovechar al mximo los recursos HW/SW y trabajar en el mejor tiempo de respuesta posible.

SEGURIDAD: Confidencialidad de los datos en su transmisin y almacenamiento, supliendo las necesidades del sistema y evitando intrusiones no autorizadas, adems de la prevencin de eventos que comprometan dicha seguridad a largo plazo. Peso 1: En caso de que el servicio se vea comprometido, no se afectara ningn proceso. La informacin procesada en este servicio no es sensible. Peso 2: Peso 3: Del servicio dependen otros servicios que, en el caso de ser afectados los comprometera. Peso 4: El servicio procesa y almacena informacin que no debe ser comprometida en ningn

momento. Peso 5: Este es un servicio que siempre debe estar protegido pues de el dependen otros servicios y procesa o almacena informacin sensible.

ESCALABILIDAD: La escalabilidad como propiedad deseable de un sistema, indica su habilidad para extender el margen de operaciones sin perder calidad, o bien manejar el crecimiento continuo de manera fluida y la preparacin para hacerse ms grande sin perder calidad en los servicios ofrecidos. Peso 1: "El servicio puede ejecutarse en un solo nodo no est preparado el servicio para el uso de clsteres" Peso 2: No aplica Peso 3: El grupo de recursos del servicio puede estar en lnea desde varios nodos. Peso 4: No aplica Peso 5: El servicio debe ser completamente escalable. El grupo de recursos puede estar en lnea a travs de varios nodos, de forma que se puedan ejecutar diversas instancias del servicio simultneamente. El grupo de recursos a prueba de fallos que aloja la direccin compartida est disponible en un solo nodo cada vez. Todos los nodos que alojan un servicio escalable usan la misma direccin compartida para alojar el servicio. 9. Estrategias de Mejora 1. Metas a corto plazo Planes contingencia

2. Metas a mediano plazo Planes contingencia

3. Metas a largo plazo Planes contingencia

Nota: Se defienden unas metas medibles a corto, mediano y largo plazo; estas metas deben estar orientadas a brindarle satisfaccin al cliente o usuario del servicio y sobre la evaluacin de cada una de ellas se define un plan de contingencia que mitigue los efectos del no cumplimiento de las metas y brinden una solucin a la ausencia de este requerimiento del usuario. 10. Responsables Se determina el cargo de la persona que es responsable de dar soporte al servicio documentado o en su defecto la dependencia que brinda el soporte y est encargada de su monitoreo. 11. Plan de Riesgos Este servicio puede enfrentar los siguientes riesgos: Nombre riesgo: Tipo de riesgo: ____ Red ____ Software ____ Administrativo

Descripcin del riesgo:

Encargado afrontarlo:

Nota: El plan de riesgos busca listar los posibles riesgos que se pueden presentar en la prestacin del servicio, documentando las caractersticas que anteriormente se citaron de cada uno de los riesgos que se puedan considerar. 12. Modelos de Casos de Uso El modelado de los casos de uso se utiliza para representar el comportamiento del sistema o del servicio que se presta desde el punto de vista de los usuarios. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar. 13. Diseo Arquitectnico de Software Modela que muestra la estructura del software y la forma en que se comunica con otros sistemas y se muestra desde el punto de vista del servicio que se define. 14. Diagrama de Clases Muestra la forma y el medio de comunicacin de los componentes que determinan el funcionamiento del servicio, especificando la API de cada uno de stos componentes. 15. Diagrama de E/R A travs de este diagrama se define la estructura de la Base de datos, sus tablas y las relaciones entre ellas, describe el comportamiento de los datos del Servicio. 16. Manual de Usuario Se crea un documento que explique el funcionamiento del Servicio al usuario final. 17. Video Tutorial de Uso Se crea un video que explique el funcionamiento del Servicio al usuario final. 18. Mapa del Sitio Un listado tipo rbol que muestra toda la estructura del sitio con todos sus links para darle una visin global del servicio al usuario. 19. Anexos Se deben definir como documentos anexos los documentos que sirven para dar soporte, justificar

o ampliar la informacin que sustenta la documentacin del servicio.

ANEXO N3 RESULTADOS PRUEBA APACHE VS. LIGHT

Pruebas Light con eAccelerator (100 Peticiones)

Blog Unidad de medida [usuarios concurrent es] 5_1 Request s per second Promedio Time per request Promedio Transfer rate Promedio Usuarios concurrentes 5_2 5 2,32 5_3 10_1 10_2 10 2,07 10_3 50_1 50_2 50 2,36 50_3

[# Request /sec] [# Request /sec] [ms] [ms] [Kbytes/se c] [Kbytes/se c]

2,15

2,26

2,18

2,24

2,4

2,28

2,243333333 2,163333333 2,346666667 464,33 441,67 458,33 446,14 416,98 424,36 439,27 1 464 3 6 483 7 9 6 6 456,5326667 462,5166667 426,877 532,1 475,4 489,68 3 519,99 501,05 3 514,78 550,77 541,2 522,83 513,9333333 497,0866667 538,2666667

Wiki Unidad de medida [usuarios concurrent es] Usuarios concurrentes 5_1 5_2 5 57,5 8 5_3 10_1 10_2 10 57,4 7 10_3 50_1 50_2 50 58,39 50_3

Request s per second

[# Request /sec] 58,45

54,33

57,51

57,61

56,63

55,9

Promedio Time per request Promedio Transfer rate Promedio

[# Request /sec] [ms] [ms] [Kbytes/se c] [Kbytes/se c]

56,78666667 17,10 18,40 8 17 7 17,62766667 26,09 25,7 24,25

57,53 17,38 7 17 17,382 25,6 25,67 5 25,71 25,67666667 17,35 7

56,97333333 17,65 17,12 17,88 7 6 8 17,557 25,27 26,06 24,95

25,34666667

25,42666667

Comparativa

Nginx (100 Peticiones) Blog

Unidad de medida [usuarios concurrente s] Requests per second Promedio Time per request Promedio Transfer rate Promedio [# Request /sec] [# Request /sec] [ms] [ms] [Kbytes/sec] [Kbytes/sec] Usuarios concurrentes 5_1 5_2 5_3 10_1 5 1,52 10_2 10 1,59 10_3 50_1 50_2 50 1,65 50_3

sin resultados

1,53

1,61

1,6

sin resultados sin resultados

1,546666667 658,66 655,64 8 630 4 648,1863333 364, 348,68 4 350,29 354,4566667

1,62 619,2 607,58 626,43 3 2 6 617,7493333 370,8 9 366,69 369,56 369,0466667

Wiki
Unidad de medida [usuarios 5_ concurrentes] 1 Usuarios concurrentes 5_2 5_3 10_1 5 13 10_2 10 13,1 4 10_3 50_1 50_2 50 13,08 50_3

Requests per second Promedio Time per request Promedio Transfer rate Promedio

[# Request /sec] [# Request /sec] [ms] [ms] [Kbytes/sec] [Kbytes/sec]

sin resultados

10,48

12,94

13,15

12,20666667 sin resultados sin resultados 76,9 95,37 3 76 5 82,81233333 5,79 5,85 4,67 5,436666667

13,05666667 77,30 76,42 76,05 3 7 1 76,59366667 5,76 5,83 5,86 5,816666667

Archivos Estticos
Imagen de 312 KB 100_ 100_ 1 2 100_3 12,59 12,48 12,49 12,52 12,59 12,57 12,53 12,56333333 12,58 12,43 12,44 12,48333333

Apache Lighttpd Nginx

Imagen de 20 KB
100_1 100_2 100_3 1542,36 1557,24 1561,32 1553,64 2799,18 2806,76 2817,29 2807,743333 2829,73 2831,85 2831,73 2831,103333

Apache Lighttpd Nginx

ANEXO N4 CONSULTA DE HERRAMIENTAS PARA RECOLECCIN DE ESTADSTICAS DE SERVIDORES

Durante 5 das se estuvo recopil informacin y se implementaron varias herramientas gratuitas o de software libre que permitieran recolectar estadsticas de uso de CPU y memoria RAM en servidores. Las herramientas que se analizaron fueron: Nagios Hyperic Cacti Pandora FMS Munin

A continuacin se describe las ventajas y desventajas de cada herramienta. Nagios: Fcil de instalar, no hace uso de base de datos, no genera grficos. Hyperic: Instalacin compleja, hace uso de java, consume mucho CPU y memoria RAM. Cacti: Instalacin fcil, usa base de datos MySQL, complejo de usar, no presenta muchas opciones de grficas, aunque se pueden agregar con plugins. Pandora FMS: Parecido a Cacti, complejo de usar. Munin: Fcil instalacin, no requiere base de datos, presenta grficas de uso de CPU, memoria, disco duro, procesos de apache y consultas a base de datos. No tiene pantalla de logueo, no guarda historial por ms de 1 mes, no tiene grficos detallados por horas (pero es posible implementarlo).

Del anlisis se concluye que la mejor herramienta para el monitoreo de estadsticas para el servidor Poseidon es Munin por su fcil instalacin, manejo y flexibilidad a la hora de agregar nuevas caractersticas.

DEFINICIONES

BIBLIOGRAFA

1. The IT Infrastructure Library, An Introductory Overview of ITIL V 3, version 1.0, Service Design, 2007 2. ITIL V3 foundation Complete Certification Kit, 2009 edition, Study Guide Book and Online Course, The Art of Service Pty Ltd 2009 3. Scalable web architectures common patterns and approaches, http://www.slideshare.net/techdude/scalable-web-architectures-commonpatterns-and-approaches 4. Architecture of Heroku applications, http://heroku.com/how/architecture 5. Replicacin y alta disponibilidad de PostgreSQL http://linuxsilo.net/articles/postgresql-pgpool.html con pgpool-II,

6. Aproximacin de optimizacin de rendimiento pgina principal Yahoo, http://www.slideshare.net/nzakas/performance-yahoohomepage 7. Arquitecturas web, http://www.royans.net/arch/ 8. Test de rendimiento Apache contra otros servidores web, http://webserverhacks.com/performance-tests/wordpress-lighttpd-vs-apachehttpd-perfomance-test/ 9. Pruebas de rendimiento de http://es.wikipedia.org/wiki/Pruebas_de_rendimiento_del_software software,

10. Aceleradores de script PHP, http://ocaoimh.ie/lighttpd-fastcgi-php-andeaccelerator/ 11. Sistemas de cache, http://systemadmin.es/2008/12/uso-de-memcachedcomo-cache-de-contendio-de-apache-para-soportar-el-efecto-barrapunto 12. Definicin de servidor web proxy, http://www.linuxparatodos.net/portal/staticpages/index.php?page=19-0-comosquid-general