Análisis del Desempeño y Escalabilidad de Frameworks Web

UNIVERSIDAD NACIONAL AUTÓNOMA DE HONDURAS Facultad de Ingeniería Departamento de Ingeniería en Sistemas

Análisis del Desempeño y Escalabilidad de Frameworks Web TESIS PARA OBTENER EL TITULO DE INGENIERO EN SISTEMAS PRESENTADO POR: CARLOS ALBERTO FLORES GIRÓN ASESORADO POR: ING. RICARDO LÓPEZ

Tegucigalpa, Honduras, Diciembre de 2013

Rectora: Dra. Julieta Castellanos Vice-Rectora de Asuntos Académicos: Dra. Rutilia Calderón Decano de la Facultad de Ingeniería: Ing. Mónico Oyuela Jefe del Departamento de Ingeniería en Sistemas: Ing. Héctor Guevara

Análisis del Desempeño y Escalabilidad de Frameworks Web

Para Jorge Esquivel

Análisis del Desempeño y Escalabilidad de Frameworks Web

Contenido CONSTRUCCIÓN DEL OBJETO DE ESTUDIO ................................................................................................. 2 Planteamiento del Problema .......................................................................................................... 3 Objetivos de la Investigación .......................................................................................................... 6 Objetivo General ......................................................................................................................... 6 Objetivos Específicos ................................................................................................................... 6 Justificación ..................................................................................................................................... 6 MARCO TEÓRICO .................................................................................................................................... 8 Plataforma y Arquitectura............................................................................................................... 9 Hardware ..................................................................................................................................... 9 Software .................................................................................................................................... 10 Aplicaciones Web ...................................................................................................................... 15 HTTP .......................................................................................................................................... 16 Framework ................................................................................................................................ 20 Framework de Aplicaciones Web .............................................................................................. 22 Pruebas de Rendimiento ............................................................................................................... 26 Actividades Básicas de las Pruebas de Rendimiento................................................................. 26 Línea de Base............................................................................................................................. 28 Benchmarking............................................................................................................................ 28 El Contexto de Proyecto ............................................................................................................ 29 Efectuando Pruebas de Carga, Rendimiento y Estrés ............................................................... 29 Diseñando Las Pruebas y el Ambiente Adecuados ................................................................... 30 Concurrencia, Escalabilidad y Rendimiento Específico ............................................................. 31 Tiempo de Respuesta ................................................................................................................ 32 La Utilización del Servidor ......................................................................................................... 33 Crear un Panorama Completo ................................................................................................... 33 Identificar los KPI del Servidor y La Red .................................................................................... 35 El Proceso de Análisis .................................................................................................................... 36 Principios de Datos de Rendimiento de Software ........................................................................ 36 MARCO METODOLÓGICO ...................................................................................................................... 39 Enfoque ......................................................................................................................................... 40 Tipo de Estudio .............................................................................................................................. 40

Análisis del Desempeño y Escalabilidad de Frameworks Web Hipótesis ........................................................................................................................................ 40 Variables ........................................................................................................................................ 40 Método de Recolección de Datos ................................................................................................. 41 Población y Muestra...................................................................................................................... 41 ANÁLISIS DE LOS DATOS ........................................................................................................................ 42 Grupo de Control........................................................................................................................... 43 Grupo 1.......................................................................................................................................... 43 Resultados de Rendimiento de los Frameworks ........................................................................... 44 Rendimiento de Discos Duros ....................................................................................................... 46 Rendimiento de Servidor Web ...................................................................................................... 46 CONCLUSIONES Y RECOMENDACIONES .................................................................................................... 47 Bibliografía ........................................................................................................................................ 49 ANEXOS ............................................................................................................................................... 50

ÍNDICE DE FIGURAS Figura 1 Pila de Software................................................................................................................... 11 Figura 2 Arquitectura Monolítica ...................................................................................................... 13 Figura 3 Arquitectura Cliente Servidor.............................................................................................. 13 Figura 4 Arquitectura de 3 Capas ...................................................................................................... 15 Figura 5 Ejemplo de aplicación de proxy........................................................................................... 19 Figura 6 Ejemplo de configuración de prueba de rendimiento ........................................................ 34 Figura 7 Gráfica Rendimiento JSON .................................................................................................. 44 Figura 8 Gráfica Rendimiento Consulta Simple ................................................................................. 45 Figura 9 Gráfica de Rendimiento de consulta múltiple..................................................................... 45

ÍNDICE DE TABLAS Tabla 1 Métodos de Mensajes HTTP ................................................................................................. 18 Tabla 2 Resultados Grupo de Control ............................................................................................... 43 Tabla 3 Resultados Grupo 1 .............................................................................................................. 43

Análisis del Desempeño y Escalabilidad de Frameworks Web

INTRODUCCIÓN El Internet se hizo popular a principios de los años 90. Diferentes sitios web, que se ejecutan en servidores HTTP y basado en el lenguaje HTML del oficial, eran la cara que veían los visitantes. Y hubo discusión acerca de la posibilidad de almacenar y realizar cálculos en los datos en los sitios web, pero no fue posible hacer este tipo con archivos estáticos como HTML. Ahora el Internet es un lugar muy diferente, ha evolucionado, han aparecido nuevas tecnologías que permitieron efectuar muchos cálculos de maneras que no se habían soñado durante la concepción de la Web. Actualmente gran cantidad de los servicios que utilizamos se encuentran enlazados al Internet de alguna manera, han permeado cada parte de nuestras vidas y algunos los encontramos imprescindibles para efectuar nuestras labores diarias. Detrás de estos servicios tan convenientes existe una gran variedad de tareas que se ejecutaron para lograr su creación. El análisis de los sistemas de información utilizados, el diseño de los mismos, su programación y su puesta en marcha. Sin embargo, hay una tarea que usualmente se deja al azar y que la mayor parte de los desarrolladores no observan hasta que crea un problema, El Rendimiento. Durante esta investigación se pretende observar el impacto una de las prácticas de programación más populares en la actualidad, la utilización de frameworks, influye en el Rendimiento de las aplicaciones Web que día a día se utilizan.

1|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web

CAPÍTULO I

CONSTRUCCIÓN DEL OBJETO DE ESTUDIO

2|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Planteamiento del Problema Las aplicaciones web están por todos lados, desde un simple widget que nos muestra el clima en nuestro celular, hasta los web services que permiten que efectuemos transacciones multimillonarias con solo oprimir un botón. En la actualidad estas actividades son tan habituales que nadie se detiene a pensar que en realidad esta funcionalidad es efectuada por un programa en un servidor remoto. La llamada “Cloud Revolution” no es más que el retorno del poder computacional a los grandes servidores centralizados, que permiten que dispositivos con menores capacidades y un menor consumo energético. En su mayoría son las aplicaciones web las que han permitido este regreso a la computación centralizada. Pero ¿Qué es una aplicación web? Es una página Web (XHTML o una variante del mismo + CSS) o conjunto de páginas web que se envía a través de HTTP que utilizan procesamiento del lado del servidor o del lado del cliente (por ejemplo, JavaScript) para proporcionar una experiencia “parecida a una aplicación” dentro de un navegador web. Las aplicaciones web son distintos de contenido Web simple ya que incluyen elementos ejecutables a nivel local que se encargan de la interactividad y el estado persistente. (World Wide Web Consortium, 2010) Normalmente cuando una aplicación web se ralentiza, se utiliza como excusa la mala calidad de la conexión a internet, el bajo rendimiento del equipo en el que se está utilizando, usualmente no se toma en cuenta la carga de trabajo que el servidor este experimentando en el momento en que se realiza la petición de la aplicación. Actualmente, las empresas viven y mueren por las aplicaciones de red y servicios web. Debido a la creciente complejidad de estos programas, y a la presión para desplegar de forma rápida, muchos profesionales no se toman el tiempo para asegurarse de que se desempeñarán bien y escalarán efectivamente (Molineaux, 2009). Esto es aún más cierto cuando se utilizan frameworks, que a cambio de ofrecernos agilidad en el desarrollo de dichas aplicaciones, sacrificamos mucho control en forma de abstracción de los diversos procesos que se llevan a cabo en un programa, ya que un framework web se considera un esqueleto de una aplicación en la que los desarrolladores conectar su código y proporciona la mayor parte de la funcionalidad común. Está construido a partir de una colección de objetos pertinentes, organizadas en clases, por lo que el marco puede ser reutilizado, ya sea su diseño o código. (Gamma, Helm, Johnson, & Vlissides, 1994).

3|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Las aplicaciones de bajo desempeño generalmente no entregan su beneficio previsto para la organización. Es decir, crean un costo neto de tiempo, dinero, y la pérdida de prestigio de los usuarios de la aplicación y por lo tanto no pueden ser considerados activos seguros. Si una aplicación no está ofreciendo beneficios, su existencia está sin duda sobre terreno inestable, por no hablar de la de los arquitectos, diseñadores, programadores y probadores. (Molineaux, 2009) Muchas veces se toma mucho tiempo en intentar incrementar el rendimiento de una aplicación simplemente cambiando los algoritmos utilizados en la misma pero a veces también es necesario verificar que el hardware en el que se está ejecutando el programa sea el adecuado, generalmente es muy difícil de cuantificar ya que el hardware de servidor es normalmente muy costoso y se requiere realizar pruebas en diversas configuraciones para llegar a una conclusión y dichas configuraciones usualmente no están disponibles. El HTTP es un protocolo a nivel de aplicación de petición/respuesta que utiliza la semántica extensible y cargas de mensajes de auto-descriptivos para la interacción flexible con los sistemas de información de hipertexto basadas en la red. (Internet Engineering Task Force, 2013). Por esto es importante observar el comportamiento de las aplicaciones con diversos programas de servidor HTTP, tarea que rara vez se efectúa. También es necesario ver que muchas veces, las aplicaciones web son concebidas únicamente con el desempeño en mente y no en su escalabilidad, lo cual a futuro puede traer consecuencias no esperadas originalmente. El desempeño mide que tan rápido y eficiente un sistema de software puede realizar determinadas tareas de computación, mientras que la escalabilidad mide la tendencia del rendimiento al aumentar la carga. Hay dos tipos principales de tareas de computación que se miden utilizando diferentes parámetros de rendimiento. Para tareas del tipo OLTP (procesamiento de transacciones en línea) que consisten en actividades interactivas de usuario, la métrica del tiempo de respuesta se utiliza para medir la velocidad de un sistema puede responder a las peticiones de los usuarios interactivos, mientras que para las tareas por lotes no interactivas, la métrica de rendimiento se utiliza para medir el número de transacciones que un sistema puede completar en un período de tiempo. Rendimiento y escalabilidad son inseparables el uno del otro. No tiene sentido hablar de escalabilidad si un sistema de software no funciona. Sin embargo, un sistema de software puede rendir, pero no escalar. (Liu, 2009) 4|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Finalmente, es importante tomar en cuenta estas interrogantes 

¿Cuál es el rendimiento esperado de una aplicación web desarrollada con el framework que se utiliza?



¿Qué tan escalable es el framework que está usando?



¿Cuánta memoria consume una aplicación?



¿Requiere discos de mayor velocidad?



¿El servidor HTTP utilizado es el correcto?



¿Debería virtualizar el hardware?

5|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Objetivos de la Investigación Objetivo General Analizar el desempeño y escalabilidad de Frameworks para desarrollo de aplicaciones web en diversos entornos de producción en lenguajes de programación populares para mostrar los aspectos que deben compensarse para evitar las pérdidas de rendimiento que puedan ser causadas por el alto nivel de abstracción. Objetivos Específicos 

Observar el impacto de los discos de estado sólido en la carga de trabajo de un servidor web típico.



Identificar los casos en los que se debe cambiar de aplicación de servidor HTTP para obtener un mejor rendimiento.



Mostrar los recursos del sistema que son más utilizados durante las cargas de trabajo típicas de una aplicación web utilizada por un Smartphone o dispositivos similares.

Justificación Como se evidenció anteriormente, en la actualidad gran parte de las funciones de los sistemas de información a nivel mundial se ejecutan en la arquitectura cliente-servidor, se puede observar que normalmente los diseñadores de sistemas que serán utilizados por una gran cantidad de usuarios de manera simultánea no tienen control sobre el lado del cliente, pero si pueden tomar las decisiones acerca de la arquitectura de la plataforma en que desarrollarán las aplicaciones. El hecho de equivocarse en la arquitectura escogida o no configurar correctamente las diversas partes de software que se utilizan en una aplicación web, pueden implicar grandes problemas en la usabilidad y estabilidad de un sistema de información. Las pruebas de desempeño son indispensables para manejar ciertos riesgos de negocios. Por ejemplo si un sitio web no puede manejar el volumen de tráfico que recibe, sus clientes comprarán en otro lugar. Más allá de identificar los riesgos obvios, las pruebas de rendimiento pueden ser una manera útil de detectar otros problemas potenciales. Aunque dichos ensayos no reemplazan otros tipos de pruebas, pueden revelar información importante relevante para la usabilidad, funcionalidad, seguridad e imagen corporativa que es difícil de obtener de otras maneras (Liu, 2009).

6|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Las pruebas de rendimiento son actividades complejas que no pueden ser convertidas en “pruebas únicas para todos”. Proyectos, entornos, criterios de aceptación, negocios, tecnologías, implicaciones legales y habilidades y herramientas disponibles simplemente vuelven cualquier noción de universalidad irrealista. (Meier, Farre, Bansode, Barber, & Rea, 2007). Cuando se habla de una aplicación, se refiere a la suma de todo, ya que una aplicación está compuesta de muchas partes y componentes. En un alto nivel se puede definir como la aplicación de software junto al panorama del software. Este último incluye los servidores requeridos así como la infraestructura de red que permite que todas las partes de la aplicación se comuniquen. Si alguna de estas áreas tiene problemas, la aplicación y sus usuarios sufren (Liu, 2009). Claro que existen algunos sacrificios que deben hacerse para lograr un buen rendimiento, pero los beneficios deben ser tangibles para poder realizarlos. El diseño y desarrollo de un programa de computadora puede incluir miles de decisiones, cada una representando una compensación que realizar. En las decisiones difíciles, cada alternativa tiene consecuencias positivas y negativas significativas. En las compensaciones, esperamos obtener un resultado cerca de lo óptimo a la vez que minimiza lo malo (Souders, 2009). Finalmente, el propósito principal de esta investigación es cuantificar las diversas variables que influyen en el rendimiento de una aplicación web escrita con un framework, dada la inexistente o escasa información acerca de la manera en que las diferentes partes del hardware influyen en el desempeño de dichas aplicaciones, permitiendo a los interesados tomar decisiones informadas acerca de la plataforma que utilizarán, así como arrojar información acerca de la configuración optima de dicho software. La motivación de la investigación es crear un instrumento que permita a los desarrolladores de aplicaciones web comprender las decisiones que toman al utilizar frameworks, estimar los costos monetarios en los cuales incurrirán al implantar su nuevo sistema de información debido a la inversión de infraestructura que necesitan, así como arrojar pistas acerca de cómo mejorar el rendimiento y escalabilidad de una aplicación ya existente mientras se indica cales son los factores más influyentes en el rendimiento de dichos frameworks.

7|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web

CAPÍTULO II

MARCO TEÓRICO

8|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Plataforma y Arquitectura Hardware El rendimiento que un sistema de software usualmente depende en la velocidad cruda del hardware en el cual se ejecuta, la cual se determina mayormente por el poder de la unidad central de proceso de la computadora. La escalabilidad que el sistema demuestra depende de la escalabilidad de la arquitectura de hardware subyacente. Muchas veces la lentitud que un usuario experimenta es causada por el uso de hardware de bajas especificaciones. En la actualidad se denota una marcada tendencia a utilizar virtualización a gran escala para realizar las actividades que antes se efectuaban directamente en hardware para obtener el mayor rendimiento, ahora se realizan en máquinas virtuales para asegurarse de desperdiciar la menor cantidad de recursos. Como dimensionar el Hardware Dimensionar hardware para un soporte lógico se trata de establecer una fórmula cuantitativa, empírica describiendo la función que una plataforma específica del hardware es capaz de dar, o para un dado requisito de desempeño, qué plataforma del hardware sería requerida para lograrlo. Tal línea directiva de dimensionamiento sería sumamente práctica para los clientes para decidirse qué hardware para adquirir, o para un proveedor del software para la localización de averías el cliente que los escalamientos de función le causaron por hardware más débil que lo esperado. (Liu, 2009) Para lograr una línea directiva efectiva de dimensionamiento, se debe intentar optimizar y afinar el software bajo prueba para la mejor función posible y dejar el hardware como el único factor que determina la función del software. Usualmente el rendimiento específico del software sigue siendo dominado por el poder de la CPU del servidor de la base de datos y el servidor de aplicaciones. La fórmula de dimensionado debe encontrarse luego de ejecutar las pruebas para recomendar al cliente o usuario los verdaderos requisitos según sus necesidades. Al hardware que no es apto usualmente se le atañe el bajo rendimiento específico, el cual puede ser mejorado al utilizar el hardware que predice la fórmula de dimensionado.

9|Página

Análisis del Desempeño y Escalabilidad de Frameworks Web Software Procesamiento Multi-hilo Ante todo, un hilo es diferente a un proceso en la informática. Un proceso es un programa auto sostenible, mientras los hilos típicamente creados dentro de un proceso sin cruzar los límites de ese proceso. El procesamiento multi-hilo es una de las tecnologías más importantes del software para fomentar la función y la escalabilidad de todos los tipos de software. En lo deja multitareas ser ejecutados simultáneamente o paralelamente para aprovechar bien el hardware con CPU múltiples. Incluso en sistema de usuario como una PC, el procesamiento multi-hilo puede dar la impresión de simultaneidad para un usuario final cambiando de decisión entre las tareas diferentes suficientemente rápido. El procesamiento multi-hilo es indispensable para software empresarial. El software empresarial típicamente funciona con computadoras del multiprocesador, que son diseñadas para manejar programas hilados o los programas múltiples. (Shklar & Rosen, 2009) Desarrollo de Alto Nivel Una parte de los lenguajes de programación más de alto nivel populares en los 1970s y 1980s incluyen FORTRAN, COBOL, C, y C++. Lo primero tres es método orientado lenguajes de programación, mientras que C++ es un lenguaje de programación orientado a objetos. Los programas escritos en estos lenguajes están habilitados para llamar a las bibliotecas para las funciones comunes como E/S. que son pusieron ejecutable siendo compiladas y entonces armadas en el código de máquina. Su forma ejecutable es llamada binaria, que es ejecutada con la coordinación de sistemas operativos. Así es que el método de desarrollar tal software consiste en lo siguiente: 

Codificar la lógica de un programa en un lenguaje de programación de alto nivel



Compilar el programa desarrollado con acoplarse para las bibliotecas para llamarse



Ensamblar el programa desarrollado en el código de máquina



Manejar el programa desarrollado en hardware específico con la asistencia de un sistema operativo específico.

La dependencia de un programa en otra formas el software stack como se muestra en Figura 1. Aparentemente, el rendimiento de un programa de software desarrollado en lenguajes de alto nivel

10 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web no depende no sólo cómo fue la diseñado e implementado, sino que también en el funcionamiento del compilador o interprete, el ensamblador, el sistema operativo, y el hardware. Con hardware dado y sistema operativo, uno a menudo puede lograr mejor rendimiento con los programas escritos en los lenguajes de programación de alto nivel aplicando opciones diversas de optimización del compilador el proceso de compilación. Los compiladores fueron diseñados e implementados para producir el

Figura 1 Pila de Software

rendimiento óptimo para los programas que compilan apuntándole a hardware subyacente específico. Con el advenimiento de Java en los 1990s, otra idea revolucionaria fue introducida, es decir, la máquina virtual Java (JVM). JVM fue diseñado para cruzar los boquetes entre sistemas operativos diferentes abstrayendo programas diversos de tiempo de ejecución medios ambientes. (Liu, 2009) La idea de JVM estaba extendida para sistemas virtuales que pueden ser configurados con software de virtualización llamado hypervisor. Este nivel de virtualización le deja echar a andar aplicaciones múltiples en sistemas que manejan múltiplo en un solo sistema físico. Esto introduce otro estrato de software de virtualización en la pila del software. API Los programas de software se construyen en forma de capas. Las capas diferentes constituyen componentes diversos, que consisten adicionalmente en subcomponentes. Los acercamientos a capas tienen la ventaja de línea divisoria de las aguas y vencen. Sin embargo, los estratos diferentes necesitan comunicarse entre sí correctamente, que son hechos posibles exponiendo colecciones de funciones comunes como API. Es importante comprender lo siguiente: 

Una API es una especificación abstracta acerca de las funciones básicas provistas para construir software que necesita para usarlo.



El software que provee la funcionalidad descrita por una API se dice ser una implementación del API. Una implementación de la API es presentada a usuarias tan una parte de un juego

11 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web de desarrollo del software (SDK). Un SDK no contiene no sólo la implementación de una API, sino que también los documentos y el código toma muestras sobre cómo usar los API. 

Las rutas de acceso para API deben especificarse cuando llamando a los programas es compilado y construido.

Computación Empresarial La arquitectura del software incluye dos partes principales de información sobre el software: 1. Los componentes del software que constituyen un sistema entero para proveer ciertas funciones en el nivel del sistema. 2. Cómo comunican los componentes mutuamente cumplir con el sistema funciona. En el software empresarial, las funciones del sistema están divididas en tareas diversas: 1. Almacenamiento, recuperación, y manipulación de datos. 2. Aplicar la lógica del negocio, que está también conocido como la lógica aplicativa. 3. Opcionalmente se exhiben los datos a través de interfaces de usuario. Basado en cómo son estas tareas implementadas en software, la arquitectura del software de la empresa ha experimentado una serie de evoluciones desde el principio del software en los 1960s con el advenimiento de computadoras. Arquitectura Monolítica (Liu, 2009) La arquitectura monolítica fue el producto del tiempo de las mainframes. En un sistema de mainframe, todos los recursos de cómputo son ensamblados en un solo sistema auto contenido. Todas las funciones del software como datos y la lógica aplicativa residen en el mismo sistema de la computadora central. El acceso del usuario para el sistema es provisto de terminales, como se muestra en Figura 2.10.las funciones como los datos y la lógica aplicativa residen en el mismo sistema de la computadora central. El acceso del usuario para el sistema es provisto de terminales, como se muestra en Figura 3.

12 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

Figura 2 Arquitectura Monolítica

Cliente Servidor Los sistemas de mainframe fueron poderosos, pero caros y difíciles para mantener. Así que pasó el tiempo, especialmente con el advenimiento de la PC (la computadora personal) la era con su economía de escala logró producción maciza directa, una nueva generación de arquitectura del software, la arquitectura del cliente/servidor, emergió, como se muestra en Figura 4. Con arquitectura del cliente/servidor, las funciones del sistema son divididas su parte lógica; una parte de la lógica aplicativa y datos es desplegada en un servidor más poderoso, y una parte de la lógica aplicativa es utilizada en menos poderosos y mucho más baratos conjuntamente con la interfaz de usuario. (Shklar & Rosen, 2009) La arquitectura cliente/servidor es conocida como arquitectura de dos capas, ya que hay un límite claro entre el cliente y el servidor. Los servidores del correo electrónico y los servidores de archivos son ejemplos claros de la arquitectura cliente/servidor.

de Aunque

sea relativamente viejo, la arquitectura del cliente / servidor aún se utiliza ampliamente.

Figura 3 Arquitectura Cliente Servidor

13 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Tres Capas El siguiente paso natural es continuar separando los datos, la lógica e interfaz de usuario en tres capas separadas, independientemente utilizables, y esa es la arquitectura de capas hileras, como se muestra en Figura 5. Una arquitectura de tres capas típicamente consiste en una capa de datos con servidores de la base de datos, una capa de lógica aplicativa con servidores de aplicaciones, y la capa de la interfaz de usuario que consiste en clientes internos que pueden ganar acceso al servidor de aplicaciones ya sea directamente a través de las aplicaciones del cliente sin pasar a través de un Servidor Web o de un Servidor Web. (Shklar & Rosen, 2009) La arquitectura escalonada está definida desde el punto de vista de la implementación y operación para alcanzar los requisitos de rendimiento y de escalabilidad. Uno puede instalar todas las tres hileras en un físico que el monaguillo trabaja a máquina para los propósitos de desarrollo, pero todavía es llamada arquitectura de tres hileras por las opciones separables de implementación de todas las tres hileras. Las aplicaciones de la Internet como las aplicaciones de Web y los sitios Web de comercio electrónico son botones de muestra de la arquitectura de tres hileras. Por ejemplo, casi cada compañía tiene un sitio Web por el que los usuarios pueden navegar averiguar los servicios y productos que provee y que también el registro para más servicio privilegia y accesos restringidos. La infraestructura tras las cámaras que mantiene de una aplicación de la Internet consiste en lo siguiente: 

Una capa frontal corriendo en uno o más servidores Web que le reencauzan al usuario las peticiones y proveen contenido estático.



Una capa intermedia ejecutándose en uno o más servidores de aplicaciones, eso maneja dinámicas peticiones contentas y específicas en usuario como usuario de recolección perfilan



Una capa trasera corriendo en uno o más servidores de base de datos que maneja y le provee el acceso a los datos.

14 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

Figura 4 Arquitectura de 3 Capas

Aplicaciones Web Las aplicaciones web actualmente conforman la manera más común de interacción con los servicios electrónicos de las compañías. No solo proveen información e interactúan con los usuarios sino que también recolectan y actualizan información, mantienen controles de acceso y soportan transacciones en línea (Shklar & Rosen, 2009). El ejemplo más común de este tipo de aplicaciones es un sitio de compras en línea, donde los visitantes revisan catálogos, buscan artículos que desean comprar y colocan sus ordenas a través de una interfaz segura que cifra la información personal. Para habilitar esta funcionalidad se requiere del desarrollo no únicamente de un programa, sino de una plataforma que sea capaz de servir a los usuarios que actualmente la utilizan (Liu, 2009), sino que también adaptarse a un mayor flujo de visitantes sin afectar la experiencia del usuario. Las aplicaciones web están construidas utilizando tecnologías estándar de Internet. Funcionan en cualquier navegador web y pueden ser desarrolladas utilizando las herramientas que sean de la preferencia del desarrollador (Mozilla Foundation, 2014). Algunas características que separan las aplicaciones web de los sitios web son: son auto-contenidas, no siempre requieren de la interfaz del navegador para funcionar completamente y se pueden construir para funcionar fuera de línea. Actualmente las aplicaciones web también forman el procesamiento del lado del servidor de muchas de las aplicaciones que se utilizan en dispositivos móviles, esto lo hacen al utilizar tecnologías que se conocen como Web Services, que son sistemas de software diseñados para 15 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web apoyar la interacción de máquina a máquina sobre una red interoperable. Tiene una interfaz descrita en un formato procesable por computadoras según la definición de W3C (World Wide Web Consortium, 2004). Cabe mencionar que ahora las aplicaciones web con las que se relacionan los usuarios día a día son una mezcla de sitio web tradicional con Web Services, esto ha sido creado como tendencia desde la época de web 2.0. Estos programas están conformados de varias capas y protocolos que en su mayoría han sido estandarizados para poder brindar un servicio normalizado sin importar el agente que se utilice para ejecutar la aplicación o consumir el servicio. Entre todos los protocoles sobresale el de uso más común, HTTP y su contraparte cifrada HTTPS. Pero este protocolo únicamente define la comunicación entre el cliente y el servidor, por lo tanto es un intermediario, aun hay que tomar en cuenta el lenguaje de programación en el cual se ha desarrollado la aplicación, el gestor de base de datos donde se almacenan los datos, la manera en que se ejecuta la aplicación, ya sea directamente mediante CGI, o como un agregado al servidor HTTP. HTTP El Protocolo de Transferencia de Hipertexto, HTTP por sus siglas en inglés, es el protocolo que los programas utilizan para comunicarse en la World Wide Web, hay muchas aplicaciones para este protocolo pero la más famosa es la conversación en dos vías entre los navegadores y los servidores web (Gourley, Totty, Sayer, Aggarwal, & Reddy, 2002). HTTP es un protocolo de interfaz genérico para los sistemas de información. Está diseñado para ocultar los detalles de cómo se implementa un servicio mediante la presentación de una interfaz uniforme a los clientes que es independiente de los tipos de recursos proporcionados. Del mismo modo, los servidores no necesitan ser conscientes del propósito de cada cliente: una petición HTTP puede ser considerado de forma aislada en lugar de ser asociado con un tipo específico de cliente o una secuencia predeterminada de pasos de la aplicación. El resultado es un protocolo que puede utilizarse eficazmente en muchos contextos diferentes y para los que las implementaciones pueden evolucionar de forma independiente con el tiempo. (Internet Engineering Task Force, 2013) HTTP utiliza protocolos fidedignos de transmisión de datos, lo cual permite al desarrollador de aplicaciones y al usuario no preocuparse por la integridad de la información requerida. De esta manera es posible enfocarse en la funcionalidad cuando se crea o utiliza una aplicación web. 16 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web HTTP también está diseñado para su uso como un protocolo de intermediación para la traducción de la comunicación hacia y desde los sistemas de información que no son HTTP. Los Proxis y Gateway HTTP pueden proporcionar acceso a los servicios de información alternativas al traducir sus protocolos diferentes en un formato de hipertexto que se pueden ver y manipular por los clientes de la misma forma que los servicios HTTP. (Internet Engineering Task Force, 2013) Una consecuencia de esta flexibilidad es que el protocolo no puede ser definido en términos de lo que ocurre detrás de la interfaz. En su lugar, se a la definición de la sintaxis de la comunicación, la intención de la comunicación recibida, y el comportamiento que se espera de los beneficiarios. Si se considera que la comunicación de forma aislada, acciones, entonces el éxito debe ser reflejado en los cambios correspondientes en la interfaz observable proporcionada por los servidores. Sin embargo, ya que múltiples clientes pueden actuar en paralelo y tal vez en propósitos cruzados, no se puede exigir que tales cambios sean observables más allá del alcance de una sola respuesta. (Internet Engineering Task Force, 2013) El protocolo establece una serie de reglas y elementos requeridos para la comunicación, se analizarán a continuación los más relevantes para el rendimiento. Clientes y Servidores Web El contenido del internet se aloja en los servidores web, los cuales hablan HTTP, estos servidores alojan los datos y los proveen cuando son requeridos por los clientes HTTP. Dichos clientes envían peticiones HTTP a los servidores y estos últimos retornan los datos en respuestas HTTP. Juntos, los clientes y servidores HTTP conforman los componentes básicos de la web. Un cliente HTTP es un programa que establece una conexión a un servidor con el fin de enviar una o más solicitudes de HTTP. Un servidor HTTP es un programa que acepte conexiones con el fin de atender las solicitudes HTTP mediante el envío de las respuestas HTTP. (Internet Engineering Task Force, 2013). Los términos cliente y servidor se refieren sólo a los roles que estos programas llevan a cabo para una conexión determinada. El cliente más común es un navegador web y el servidor más común son los que se utilizan en sitios web del internet. Sin embargo es muy fácil caer en la trampa de pensar que todos los clientes HTTP son navegadores web y que todos los servidores son únicamente programas que se utilizan en sitios web, clientes comunes de HTTP incluyen electrodomésticos, balanzas, programas de actualización de firmware, aplicaciones móviles y dispositivos de 17 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web comunicación en una multitud de formas y tamaños. De igual manera, servidores HTTP de origen incluyen unidades de automatización del hogar, componentes de red configurables, máquinas de oficina, cámaras de tráfico entre otros. Recursos Un recurso web es la fuente del contenido del internet. En su forma más simple, estos son archivos estáticos que se encuentran en el sistema de archivos del servidor web. Pero también pueden ser programas de software que pueden generar contenido a petición. Transacciones Los clientes utilizan transacciones HTTP para comunicarse con los servidores web, una transacción HTTP consiste en un comando de petición enviado del cliente al servidor y de un resultado de respuesta que es enviado de vuelta al cliente desde el servidor. (Gourley, Totty, Sayer, Aggarwal, & Reddy, 2002)

GET PUT DELETE POST HEAD

Enviar recurso nombrado desde el servidor Almacenar datos desde el cliente en un recurso nombrado del servidor Eliminar un recurso nombrado en el servidor Enviar datos del cliente a una aplicación de Gateway del servidor Enviar solo los encabezados HTTP de la respuesta para el recurso nombrado

Tabla 1 Métodos de Mensajes HTTP

Mensajes Los mensajes HTTP son secuencias de caracteres simples, orientadas a líneas. Cada mensaje consiste en tres partes: Línea de inicio, que indica que hacer para una petición o que paso durante una respuesta; Encabezado, consisten en un nombre y un valor separados por dos puntos; Cuerpo, es el contenido opcional que contiene los datos del servidor, el cuerpo puede contener cualquier cantidad de datos binarios arbitrarios. Conexiones HTTP al ser un protocolo de capa de aplicación simplemente utiliza TCP/IP para efectuar sus conexiones, por lo tanto cada petición HTTP tiene una carga sobre el servidor físico hacia el que se efectúan las conexiones. Componentes Arquitectónicos de la Web Existen otros componentes que sirven como parte de la arquitectura de Internet, las más importantes son las siguientes: 

Proxis: Intermediarios HTTP que se colocan entre los clientes y los servidores. 18 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web 

Caches: Almacenes que guardan copias de páginas web populares cerca de los clientes.



Gateway: Servidores Web especiales que conectan a otras aplicaciones.



Túneles: Proxis especiales que envían ciegamente todas las comunicaciones HTTP.



Agentes: Clientes web cuasi-inteligentes que hacen peticiones HTTP automatizadas.

De los anteriores es de importancia definir directamente los Proxis, ya que como se verá más adelante, Ngnix se utiliza más frecuentemente como un Proxy HTTP entre la aplicación y el navegador web. Proxy Los proxis HTTP son a la vez servidores web y clientes web. Como los clientes deben enviar peticiones a los proxis, estos últimos deben manejar apropiadamente las peticiones y conexiones como un servidor web. Al mismo tiempo el mismo proxy envía peticiones a los servidores web, por lo que deben comportarse como clientes. Los proxis tienen diversos usos, (Gourley, Totty, Sayer, Aggarwal, & Reddy, 2002) pueden servir como filtros de censura, controladores de acceso a documentos, firewalls de seguridad, web cache, sustituto, enrutadores de contenido, transcodificador o anonimizador. El enfoque de esta investigación es sobre el proxy sustituto, los cuales se hacen pasar por servidores web, estos son llamados sustitutos o proxis reversos, reciben peticiones reales pero a diferencia de los servidores web, pueden iniciar comunicación con otros servidores para localizar de manera dinámica el contenido pedido.

Figura 5 Ejemplo de aplicación de proxy

Los proxis reversos usualmente se pueden utilizar para aumentar el rendimiento de servidores web lentos para contenido común. En esta configuración los sustitutos se llaman frecuentemente

19 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web aceleradores de contenido. Los sustitutos también pueden ser utilizados en conjunto con funcionalidad de enrutadores de contenido para crear redes distribuidas de contenido replicado en demanda. Framework Un armazón del software es un conjunto de código fuente o bibliotecas que le proveen la funcionalidad común a una clase entera de aplicaciones. Mientras una biblioteca usualmente proveerá un pedazo específico de funcionalidad, los armazones ofrecerán un alcance más amplio que son todo a menudo usados por un carácter de imprenta de aplicación. En vez de reescribir comúnmente usó lógica, un programador puede palanquear un armazón que provee a menudo usado la funcionalidad, limitando el tiempo requerido para construir una aplicación y reduciendo la posibilidad de introducir nuevos errores. (Gamma, Helm, Johnson, & Vlissides, 1994) Por ejemplo, un framework de aplicaciones web puede proveer el manejo de sesión del usuario, el almacenamiento de datos, y un sistema de plantillas. Un framework de aplicaciones de escritorio puede proveer funcionalidad de la interfaz de usuario y widgets (los elementos comunes de la Interfaz Gráfica del Usuario). Casi todos los frameworks controlan al menos algún aspecto del flujo de ejecución de una aplicación. Hay muchos tipos diferentes de frameworks, incluso dentro de una clasificación de aplicaciones. Algunos ofrecen poco más que las rutinas individuales de utilidad dentro de una concha antiácida de una aplicación. Los otros ofrecen lo que es casi una aplicación completa y requieren organización estricta del código fuente y otras reglas. Escoger el mejor armazón para un proyecto a menudo requiere que un programador se balancee cuánto la funcionalidad que obtienen del armazón en contra de la flexibilidad con el que ellos quedan. Ventajas Los framework de aplicación ofrecen una colección variada de ventajas: 

El código que ya se ha construido, ha probado, y usado por otros programadores aumenta la fiabilidad y reduce el tiempo de desarrollo. En una corporación esta reutilización de código eficazmente ahorra dinero.



Los equipos de desarrollo del software pueden ser separados entre esos que programan el framework y los que programan la aplicación completa final. Esta separación de tareas permite a cada equipo enfocar su atención en metas más específicas y usar sus fuerzas 20 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web individuales. Por ejemplo, los programadores que son expertos en interfaz de usuario que diseño podrían trabajar en la aplicación del cliente mientras los expertos de seguridad prueban y fortalecen el framework en el cual la aplicación se construye. 

Los frameworks pueden proveer características de seguridad que son a menudo requeridas para una clase común de aplicaciones. Esto provee cada aplicación escrita en el framework sacar provecho de la seguridad añadida sin el tiempo extra y el costo de desarrollarla. Los ejemplos incluyen a la gerencia segura de sesión y a librarse de aporte de la base de datos.



Al manejar “tareas de bajo nivel” los frameworks pueden asistir con la modularidad. La lógica comercial, por ejemplo, puede quedarse en la aplicación mientras las tareas mundanas de conectividad de la base de datos y el manejo de inicio de sesión del usuario pueden ser manejadas separadamente en el framework.



Los frameworks a menudo ayudan a implementar reglas y mejores prácticas específicas en la plataforma. Un framework GUI de Escritorio, por ejemplo, automáticamente puede construir barras de herramientas y botones comunes para el sistema operativo local. Un framework de aplicación Web puede ayudar cifrando contraseñas del usuario o pago yendo en procesión.



Los frameworks pueden ayudar programando diseñar patrones y mejores prácticas generales. Por ejemplo, muchos frameworks son diseñados según el patrón MVC.



Mejoras para un framework puede incrementar la funcionalidad de la aplicación sin más programación por el desarrollador aplicativo de cierre. Si, por ejemplo, un framework de comercio electrónico ofrece un nuevo método de pago, esa opción automáticamente puede hacerse disponible para el usuario final sin más programación por el desarrollador de la aplicación.

Desventajas Puede haber consecuencias negativas para usar un armazón: 

El rendimiento puede degradarse cuando el código común es usado. Esto a veces ocurre cuando un framework debe revisar en busca de los escenarios diversos en los cuales se usa para determinar una ruta de acción. También puede ocurrir con código generalizado que no es optimizado para una situación específica. La degradación de rendimiento, sin embargo, se compensa a menudo con la velocidad realzada de desarrollo y la calidad de la aplicación final. 21 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web 

Los frameworks a menudo requieren un entrenamiento significativo para utilizar eficazmente y correctamente (o sea algunos tienen una alta curva de aprendizaje). Por eso los framework específicos muy a menudo se vuelven más valiosos para los programadores individuales cuando son usados repetidamente. Con cada nuevo proyecto usando el mismo framework, la curva de aprendizaje se vuelve menos problema y aumenta la productividad.



La funcionalidad que necesita rodear alrededor de las deficiencias en un framework puede causar más problemas de programación que desarrollar la funcionalidad completa en primer lugar. Los buenos framework proveen utilidad y estructura al todavía dejar bastante flexibilidad para no ponerse en medio del camino del programador. Algunos frameworks son tan rígidos y altamente estructurados que escogerlos para un proyecto inapropiado puede ser desastroso. Ésta no es una falla del framework, pero algunos son generalmente más adecuados y flexibles que otros. Esto debe ser cuidadosamente considerado por quienes escogen un framework.



Los errores y problemas de seguridad en un framework pueden afectar cada aplicación usando ese framework. Por eso debe ser probado y parchado separadamente o además del producto del software de cierre.

Framework de Aplicaciones Web Un framework de aplicaciones web es un tipo de framework específicamente diseñada para ayudar a los desarrolladores a construir aplicaciones Web. Estos frameworks típicamente le proveen la funcionalidad de fondo común a la mayoría de aplicaciones de trama, como la persistencia de usuario de sesión de la gerencia, de datos, y los sistemas de plantillas. Usando un framework apropiado, un desarrollador a menudo puede ahorrar una cantidad significativa de tiempo construyendo un sitio Web. (DocForge, 2013) Características Cada framework es diferente, pero muchos proveen una colección variada de características útiles. Usando un framework, un desarrollador evita tener que reimplementar estas mismas características para cada aplicación de trama crean. La Persistencia de Datos Una característica central de todas las aplicaciones web es su necesidad para almacenar información y construir las páginas web de basadas en información almacenada. A diferencia de un set de páginas estáticas, la mayoría de páginas de trama aplicativas son dinámicamente generadas de 22 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web datos persistentes. (Una excepción notable es almacenar en cache páginas dinámicas para mejorar el rendimiento.) Por ejemplo, en un sistema gestor de contenido básico, un editor publicista escribirá un artículo en una página web administrativa, con campos múltiples para cuerpo del artículo, el título, el escritor, etcétera. Esa página más tarde será dinámicamente generada cuando un usuario pide el artículo de aplicación de Internet. Esto deja cada artículo ser estilizado de la misma forma y deja a un editor publicista editar contenido sin saber HTML o tener que editar archivos directamente en un servidor. Obviamente cada aplicación web tiene sus necesidades para las estructuras exactas de datos para continuar. Un framework puede ayudar en la persistencia de datos con una colección variada de características: 

Una API consistente para ganar acceso a sistemas múltiples de almacenamiento de datos



El almacenamiento automático o simplificado y la recuperación de objetos de datos, como con ORM.



La estructura comercial del objeto de fondo, tan todos los datos, incluso a través de sistemas múltiples, tendrá una interfaz básica consistente.



Los realces de función, como almacenar en cache por encima del estrato de la base de datos



La integridad de los datos revisa, como validar relaciones o los campos requeridos afirmativos son llenados.



Construcción de consultas SQL.

Gestión de Sesión y Autenticación del Usuario Los sitios Web públicos estáticos típicamente pueden tratar a cada visita tan completamente anónimo. Las aplicaciones de Web, sin embargo, a menudo requieren cuentas del usuario y la persistencia de información a través de los puntos de vista de la página. Algunos servidores Web y marcos de ejecución proveen persistencia básica de sesión, pero la gestión de cuentas de usuario y la lógica específica de la aplicación necesitan forjarse encima de ella. Los frameworks pueden proveer cuentas genéricas de usuario, a veces extensibles, así es que las personas pueden registrarse, entrar en el sistema, y pueden reestablecer contraseñas. También pueden proveer la gestión de cuentas usuario para administradores.

23 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Seguridad A veces las páginas de aplicaciones web deben ser visibles para los usuarios autenticados. Los frameworks automáticamente pueden comprobar y pueden requerir autenticación antes de generar una página. Por ejemplo, pueden ayudar al desarrollador en edificador y procesando una forma de entrada en el sistema o pueden conectarse a un servidor LDAP. Una vez que un usuario final sea autenticado, un armazón puede revisar los permisos específicos en busca de que el usuario. Estos permisos pueden ser manejados de diversos modos. Un armazón podría proveer basado en papeles control de acceso, o cualquiera de una colección variada de otras características de seguridad. Estos son típicamente manejados por un desarrollador en código secreto o un administrador del sitio a través de una interfaz administrativa. Almacenamiento en cache Para mejorar el rendimiento de una aplicación web, los desarrolladores web a menudo almacenarán en cache cierto contenido así es que no necesite ser regenerado en cada petición de la página. Los frameworks le pueden ofrecer una interfaz común a almacenamiento del disco o de la base de datos de contenido almacenado en cache. Plantillas Las plantillas de la página web ayudan a mantener separada lógica comercial de lógica de despliegue, que son comúnmente consideradas práctica recomendable. Un armazón puede proveer uno o más sistemas de plantillas o más motores de interfaces consistentes para desarrolladores. Más a menudo el framework hará disponible campos definidos por el desarrollador o estructuras de datos dentro de plantillas. Inversamente un sistema de plantillas puede pedir datos de regreso a través del framework. El sistema de plantillas puede ser algo tan simple como reemplazo de palabra clave o puede ser lo suficientemente robusto para automáticamente generar contenido como campos de la forma de parámetros. Administrativa Interfaz Es muy común que sitios Web dinámicos necesiten una sección específicamente construida para administradores del sitio. Aquí el sitio puede ser configurado y los datos pueden estar alterados. Los administradores podrían crear cuentas de usuario, podrían manejar permisos, podrían cambiar contenido de la página, podrían generar informes, o cualquier otra cosa según se requiera. 24 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Los frameworks de aplicaciones Web pueden ayudar construyendo interfaces administrativas por mediante los siguientes métodos: 

Generando una estructura de navegación.



Proveyendo elementos comunes de la interfaz para formar campos, como un campo de cita con un calendario.



Generando páginas de edición listado de estructuras persistentes de datos; los desarrolladores a menudo definirán los dominios básicos o las interfaces deseadas y éstos serán incorporados en una página por el framework.

Implementación Todas las aplicaciones web toman peticiones HTTP individuales pide y constitución respuestas apropiadas. Éste puede ser manejado de diversos modos, algo dependiente en la plataforma del servidor. Probablemente el patrón del diseño más global popular de frameworks de aplicación web es Modelo-Vista-Controlador (MVC). El código inicial del framework, o la plataforma misma, evalúa el URL y pasa responsabilidad para el controlador aplicativo apropiado. El controlador entonces realiza algunas acciones necesarias con modelo de datos de la aplicación y entonces deja a la vista construir el contenido final de respuesta para ser dado por el navegador. Otra consideración del diseño de un framework es su flujo de ejecución. A menudo, todas las peticiones para una aplicación de la trama les es hecho pasar por un solo set de código provisto por un framework, como index.php en la raíz de una aplicación PHP. Este código es responsable de inicializar sesiones del usuario, conectividad de la base de datos, y cualquier otra cosa requerida en cada carga de la página. El control está entonces entregado al código específico en la aplicación responsable para generar el contenido particular pedido. Web.py de Python, por ejemplo, toma una lista de URLs y los nombres de clase que se proveyó por la aplicación para maniobrarlos. El acto de diseñar e implementar un framework de aplicaciones web completo puede ser una tarea compleja. Sin algunas metas claras, el desarrollo fácilmente puede ser fácilmente llenado con inconsistencias y exceso de código. Las preguntas a preguntar a comienzos de diseño del framework incluyen:

25 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web 

¿Qué dominio específico de problemas puede tejer aplicaciones hechas de este blanco del armazón? Si la respuesta es "todo" entonces a menudo un armazón ligero, discreto es probablemente más conveniente. Sin embargo, si un dominio de problemas puede ser dirigido a sectores específicos entonces el armazón puede incluir más funcionalidad específica a esas aplicaciones.



¿Qué nivel de modularidad proveerá el framework y mantendrá?



¿Qué reglas de desarrollo implementará el framework? Por ejemplo, ¿los desarrolladores aplicativos estarán obligados a seguir una cierta estructura del archivo? ¿Será algunos patrones del diseño de detalle estrictamente seguido?



¿Qué curva de aprendizaje existirá para que los desarrolladores aprendan el framework? Mientras más elaborada la API, mayores habilidades necesitarán los desarrolladores que lo usarán.

Pruebas de Rendimiento Las pruebas de rendimiento son investigaciones técnicas destinadas a determinar la capacidad de respuesta, el rendimiento, la estabilidad y/o la escalabilidad de un sistema bajo una carga de trabajo determinada (Meier, Farre, Bansode, Barber, & Rea, 2007). Las pruebas de rendimiento se llevan a cabo comúnmente para lograr lo siguiente: 

Evaluar la disponibilidad de la producción.



Evaluar los criterios de rendimiento.



Comparar las características de rendimiento de varios sistemas o configuraciones del sistema.



Encontrar la fuente de los problemas de rendimiento.



Ajuste del sistema Soporte.



Buscar niveles de rendimiento.

Actividades Básicas de las Pruebas de Rendimiento Las pruebas de rendimiento usualmente se hacen para ayudar a identificar los cuellos de botella, establecer líneas de base para pruebas futuras, documentar un esfuerzo de afinamiento de rendimiento, determinar el cumplimiento de metas de rendimiento y requisitos. El análisis de los resultados de las pruebas de rendimiento puede ser utilizado para estimar la configuración de hardware requerida para soportar la aplicación cuando se coloque en un entorno de producción. 26 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Según Microsoft (Meier, Farre, Bansode, Barber, & Rea, 2007), se consideran las siguientes etapas cuando se realizan pruebas de rendimiento de aplicaciones web. 1. Identifique el Medio Ambiente Experimental. Identifique el medio ambiente experimental físico y el medio ambiente de producción así como también las herramientas y recursos disponibles para el equipo experimental. El entorno físico incluye hardware, software, y configuraciones de la red. Tener una comprensión entorno experimental entero al principio permite un diseño experimental más eficiente y planificación y ayuda a identificar retos de prueba temprano en el proyecto. En algunas situaciones, este proceso debe ser vuelto a visitar periódicamente a todo lo largo del ciclo biológico del proyecto. 2. Identificar los Criterios de Aceptación de Rendimiento. Identificar el tiempo de respuesta, el rendimiento específico, las metas de utilización de recursos y las restricciones. En general, el tiempo de respuesta es una preocupación del usuario, el rendimiento específico es una empresa de negocios, y la utilización de recursos es una preocupación del sistema. Adicionalmente, identifique criterios de éxito de proyecto que no pueden ser captados por esas metas y esas restricciones; Por ejemplo, usar función experimenta para evaluar qué la combinación de ajustes de configuración dará como resultado las características de función más deseables. 3. Planificar y Diseñar Pruebas. Identificar escenarios claves, determinar variabilidad entre usuarios representativos y cómo simular esa variabilidad, definir datos de prueba, y establecer métrica para ser coleccionado. Consolidar esta información en uno o más modelos de uso del sistema para ser implementado, ejecutado, y analizado. 4. Configurar el Entorno Experimental. Preparar el entorno experimental, herramientas, y recursos necesarios para ejecutar cada estrategia a medida que las características y los componentes se hacen disponibles para la prueba. Hay que asegurar que el entorno experimental sea instrumentado para monitorear recursos cuando sea necesario. 5. Implemente la Distribución Experimental. Desarrolle las pruebas de ejecución de conformidad con el diseño experimental. 6. Ejecutar la Prueba. Correr y monitorear las pruebas. Validar las pruebas, los datos de prueba, y colección de resultados. Ejecutar pruebas validadas para análisis al monitorear la prueba y el medio ambiente experimental. 7. Analizar Resultados, Informar, y Probar de nuevo. Consolidar los datos accionariales de resultados. Analizar los datos tanto individualmente y como en conjunto. Priorizar las demás 27 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web pruebas y las volver a ejecutarlas según se necesite. Dentro de lo cuando todo lo que los valores métricos están acogió límites, ninguno de los umbrales determinados ha sido violado, y toda la información deseada ha sido coleccionada, usted ha terminado de probar ese panorama particular en esa configuración particular. Línea de Base La creación de una línea de base es el proceso de ejecución de un conjunto de pruebas para capturar datos de métricas de rendimiento para el propósito de evaluar la eficacia de los cambios posteriores a la mejora de rendimiento del sistema o de la aplicación (Meier, Farre, Bansode, Barber, & Rea, 2007). Las líneas base se pueden utilizar para saber si el rendimiento está mejorando o declinando y para encontrar desviaciones a lo largo de diferentes versiones. Un ejemplo, una aplicación de animación tridimensional mide su rendimiento de acuerdo a la cantidad de pantallas por unidad de tiempo que es capaz de dibujar, en el caso de aplicaciones es medir la cantidad de páginas web servidas por unidad de tiempo. De esta manera se puede observar que las líneas base se pueden crear para un sistema, componente o aplicación. A la vez permiten establecer referencias para futuras llevar un seguimiento de optimizaciones o regresiones de rendimiento. Sin embargo estas métricas deben ser creadas únicamente cuando se comprende completamente el comportamiento de la aplicación al momento que la línea de base es creada. Benchmarking Este es el proceso mediante el cual se compara el rendimiento de un sistema contra una línea de base que haya sido creada por quien está efectuando la evaluación o contra un estándar que ha sido endorsado por alguna organización (Liu, 2009). En el caso de una aplicación web, seria efectuar una serie de pruebas que cumplen con las especificaciones de una prueba de rendimiento de la industria, luego se pueden comparar dichos resultados contra otros sistemas o aplicaciones que también calcularon su puntación para la misma prueba. Para que el proyecto de pruebas de rendimiento sea exitoso, las pruebas que se incluyen en el mismo deben ser relevantes al contexto del proyecto, lo que ayuda a enfocarse en aquellos puntos que son realmente importantes.

28 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web El Contexto de Proyecto Para que un proyecto de comprobación de rendimiento sea exitoso, ambos el acercamiento para probar función y la experimentación mismo debe tener importancia para el contexto del proyecto. Sin una comprensión del contexto de proyecto, la comprobación de rendimiento debe tener en la mira sólo esos artículos que el probador de función o el equipo experimental asume para ser importante, a distinción de esas que verdaderamente son importantes, frecuentemente principales para el tiempo desperdiciado, la frustración, y los conflictos. El contexto de proyecto no es nada más que esas cosas que son, o pueden llegar a ser eso, pertinentes para lograr éxito de proyecto. Esto puede incluir, pero no se limita a: 

La visión global del proyecto.



Los objetivos de comprobación de rendimiento.



Los criterios de éxito de función.



El ciclo de vida de desarrollo.



La duración del proyecto.



El presupuesto de proyecto.



Las herramientas disponibles y los medios ambientes.



La habilidad determinada del probador de función y el equipo.



La prioridad de preocupaciones detectadas de función.



El impacto comercial de utilizar una aplicación que actúa pobremente.

Efectuando Pruebas de Carga, Rendimiento y Estrés Microsoft clasifica las pruebas de ejecución pertenecientes a una de las siguientes tres categorías: 1. Comprobación de Rendimiento: Este tipo de experimento determina o valida la velocidad, la escalabilidad, y/o las características de estabilidad del sistema o la aplicación bajo prueba. La función se preocupa por lograr tiempos de respuesta, rendimiento específico, y los niveles de utilizaciones de recursos que el concurso los objetivos de función para el proyecto o el producto. 2. Comprobación de Carga: Esta subcategoría de pruebas de rendimiento está enfocada a determinar o validar las características de función del sistema o aplicación bajo las cargas de trabajo y los volúmenes de carga anticipados durante operaciones de producción.

29 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web 3. Experimentación de Estrés: Esta subcategoría de comprobación de rendimiento está enfocada a determinar o validar las características de función del sistema o la aplicación cuando se somete a las condiciones más allá de las previstas durante operaciones de producción. Las pruebas de esfuerzo también pueden incluir pruebas en las que se enfoca en otras condiciones estresantes, como memoria limitada, el espacio insuficiente del disco, o falla del servidor. Estas pruebas son diseñadas para determinar bajo condiciones una aplicación dejará de operar, cómo dejará de operar, y qué indicadores pueden ser monitoreados para dar aviso de un fracaso inminente. Diseñando Las Pruebas y el Ambiente Adecuados Molineaux dice que la aplicación de pruebas de rendimiento aún es una disciplina informal. La razón para esto es difícil de establecer, porque las pruebas de funcionalidad y regresiones han estado bien definidas por largos años. Hay una gran cantidad de literatura y una gran cantidad de opinión experta disponible en ese campo, y muchas compañías establecidas se especializan en la ejecución experimental y consultando. Para la comprobación de rendimiento, el contrario es cierto, al menos en materia de condiciones de referencia. Hay innumerables publicaciones que explican cómo afinar y optimizan una aplicación, pero muy poco acerca de cómo establecer de manera correcta dichas pruebas, por lo que muchas de las pruebas que se encuentran en la web, como las realizadas por TechEmpower (TechEmpower, 2013), tienen algunos sesgos o fallos en su implantación, o se limitan a mostrar métricas sin explicar el trasfondo de las mismas. Virtualización Un factor relativamente nuevo y con mucha influencia en el diseño del medio ambiente experimental es el surgimiento de tecnología de virtualización que deja instancias “virtuales” múltiples del servidor existir en un solo machine. VMWare ha sido el líder de mercado por algunos años, aunque esta posición esté ahora siendo puesta en duda por ofertas de otros vendedores como Microsoft con su tecnología virtual del servidor. Lo que importa es notar que la virtualización hace posible una simulación más cercana acerca del número y la especificación de servidores presentes en el medio ambiente en vivo.

30 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Si el medio ambiente en vivo también hace uso de virtualización entonces es mucho mejor. Si esto no es el caso entonces hay cosas a tener en mente al intentar simular servidores físicos utilizando servidores virtuales: Bus Físico vs Virtual La comunicación entre servidores virtuales compartiendo el mismo bus físico exhibirá características diferentes que servidores comunicándose sobre LAN o Red de Área Amplia. Aunque tal comunicación virtual puede usar virtuales Tarjetas de Interfaz de Red (NIC), no sufrirá (a menos que artificialmente insertados) problemas típicos de la red como la restricción de ancho de banda y los efectos de latencia. En un medio ambiente del centro de datos deberían estar pocos problemas de la red con servidores físicos, así es que éste no debería ser un problema. Sin embargo, si sus servidores físicos están conectados a una gran distancia por LAN o Red de Área Amplia, la sustitución de servidores virtuales de bus común en la prueba no será una representación verdadera de comunicación de servidor a servidor. Así mismo es mejor evitar utilizar servidores virtuales de distintas capas de aplicación en la misma máquina física. NIC virtual vs Físico Los servidores virtuales tienen tendencia a usar NIC virtuales. Esto quiere decir que, a menos que haya un NIC físico para cada servidor virtual, los servidores múltiples tendrán que compartir al mismo NIC físico. La tecnología actual NIC es bastante robusta, así es que se requiere bastante para sobrecargar una tarjeta. Sin embargo, canalizar varios servidores de tráfico de red at través de un solo NIC aumenta la posibilidad de sobrecarga. Concurrencia, Escalabilidad y Rendimiento Específico Concurrencia La concurrencia es probablemente el menos comprendido de los objetivo de rendimiento. Los clientes a menudo citarán algún número de usuarios concurrentes que la aplicación debe mantener sin darle bastante pensamiento a lo que en realidad se refiere. Molineaux indica “obtenga adecuadamente los requisitos de desempeño: Piense como un usuario,” sugiriendo que la concurrencia basada en una figura de una hora es un más realista. La concurrencia desde la perspectiva de una herramienta de comprobación de rendimiento es el número de usuarios activos generados por el software, que no equivale necesariamente al número de usuarios 31 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web concurrentemente ganando acceso a la aplicación. Poder proveer un nivel preciso de concurrencia depende muchísimo en el diseño de su código de transacciones. Molineaux también enfatiza que de concurrencia y escalabilidad derivamos metas de capacidad. Logrando los objetivos de escalabilidad demuestra una suficiente capacidad para que la aplicación rinda para el negocio. Aun igualmente importante está averiguando simplemente cuánto la capacidad adicional está disponible. En los términos de comprobación de rendimiento, “la concurrencia” se refiere a las siguientes dos áreas bien definidas. Los usuarios virtuales concurrentes El número de usuarios virtuales activos desde el punto de vista de su herramienta de comprobación de rendimiento. Este número es a menudo muy diferente del número de usuarios virtuales en verdad ganando acceso a la aplicación bajo prueba. Usuarios concurrentes de la aplicación El número de usuarios virtuales accediendo concurrentemente a la aplicación. Quiere decir que en verdad entró al sistema para la aplicación bajo prueba. Este número es la medida clave de cuántos usuarios virtuales están en un dado momento de tiempo. Tiempo de Respuesta Al alcanzar a la concurrencia del blanco (o el rendimiento específico), la aplicación debe dejar a los usuarios finales llevar a cabo sus tareas en una moda oportuna. Desde el punto de vista de un usuario final es mucho más perceptible; Por ejemplo, un tiempo de respuesta de 60 segundos para una aplicación de centro de llamadas puede ser perfectamente aceptable, pero el mismo tiempo de respuesta para una aplicación que intercambia acciones en la bolsa de valores lo volvería completamente inutilizable. También puede ser que el tiempo para completar una actividad como el intercambio de acciones es más importante que una indicación visual de éxito apareciendo en la PC del usuario final. Éste es a menudo el reto al migrar de una aplicación de consola a su reemplazo basado en web que tiene muchas funcionalidades pero no puede proveer la misma clase de respuesta instantánea. Es

32 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web en este momento en el cual el procesamiento asíncrono juega un papel muy importante de acuerdo a Microsoft y a Liu. La Utilización del Servidor En un modo similar, puede haber límites fijos en la cantidad de recurso del servidor que a una aplicación se le permiten usar. Esta información puede ser determinada sólo monitoreando los Indicadores Clave de Rendimiento (KPI por sus siglas en inglés) mientras los servidores están bajo carga. Obtener esta información confía apropiadamente saque determinado KPI hay muchos mediante los cuales se puede medir la utilización del servidor que puede ser monitoreada, sino en términos de objetivos de rendimiento lo más común es: 

La utilización de la CPU.



La utilización de memoria.



Las operaciones de entrada y salida de dispositivos de almacenamiento.



El espacio de almacenamiento.

En un mundo ideal poseeríamos el paisaje completo de la aplicación, pero en la vida real los servidores o red son controlados por proveedores externos. Esto nos obliga a reconsiderar el alcance de objetivos de rendimiento para que puedan ser determinados de una manera realista. Usted probablemente puede probar el centro de datos exhaustivamente, pero usted a menudo no puede hacer eso para el medio ambiente fuera del centro de datos, donde el tráfico aplicativo puede atravesar las manos de múltiples proveedores de servicio de Internet (ISPs) antes de alcanzar al usuario final. Usted lleva poco realmente el control encima cómo la función de su aplicación será afectada por acontecimientos en el espacio cibernético, pero usted puede asegurar que no hay cuellos de botella de función dentro del centro de datos. Crear un Panorama Completo La figura 6 muestra un ejemplo comprensivo de datos que se tomaron de un documento de pruebas de rendimiento diseñado para las pruebas de un documento real, la cual es provista en la exposición realizada por Molineaux, es importante detenerse a analizar sus partes. Observe que hay una sección en la figura para línea de base y una sección separada para carga simulada. La aplicación ya estaba manteniendo a 200 usuarios virtuales sin problema, y los datos estaban disponibles para determinar la tasa de transacción al día y por hora para la carga existente. 33 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Ésta

es

la

información

presentada en la

sección de la línea

de base y usado

como

objetivo para la

ejecución de las

el

primer

pruebas. La

sección

simulada de carga

especificó la carga

final del objetivo

para la prueba de

rendimiento, que

fue 500 usuarios

virtuales.

Una

parte importante

de

esta

carga aumentada

es asegurar que las

tasas

transacción

ejecución

de y

lograr

de

de

rendimiento

específico fueron

una extrapolación

realista de niveles

actuales.

Figura 6 Ejemplo de configuración de prueba de rendimiento

34 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Aquí hay una descripción de la figura: 

Número de Referencia: Secciones en el documento maestro que incluyen la transacción.



Transacción: nombre de la transacción.



Duración: La cantidad de tiempo en segundos que la transacción tarda para completar.



La tasa de transacción (por línea base). o

TPD: La tasa de transacciones al día.

o

TPH: La tasa de transacciones por hora.

o

Usuarios calculados (por línea de base).

o

Min VU: El número mínimo de usuarios virtuales para esta transacción.

o

Dist. %: Distribución de esta transacción como un porcentaje del número total de usuarios virtuales en esta prueba.

o

VU: El número de usuarios virtuales utilizados para esta Transacción basada en el Dist. %



Carga simulada (al aplicar los factores de carga tuvieron aplicación): o

TPH: La tasa de Transacción objetivo por hora.

o

VU: El número total de usuarios virtuales ubicados para esta Transacción.

o

Inicialización (hh:mm:ss): La tasa de inyección virtual del usuario para esta Transacción.

o

Paso (hh:mm:ss): La tasa de incremento para esta Transacción.

Identificar los KPI del Servidor y La Red Microsoft, Molineaux y Liu coinciden en que la identificación correcta de los KPI es vital para alcanzar un análisis preciso de las causas raíz de cualquier problema que pueda ocurrir durante la ejecución de las pruebas de rendimiento. Idealmente la monitorización es parte integral de la solución automatizada de pruebas que se está utilizando. Sin embargo cada capa de la aplicación requiere un set especializado de modelos de monitoreo que deben ser tomados en cuenta al momento de ejecución. En el caso de los servidores la capa superior es llamada por Liu como monitoreo genérico, que pueden ser las herramientas que el sistema operativo de equipo de cómputo trae consigo. La siguiente capa debe enfocarse en las tecnologías específicas que son parte del escenario de la aplicación, sean el servidor web, la aplicación misma, y finalmente los servidores de bases de datos.

35 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web La última capa comprende el servidor de aplicaciones y cambia el enfoque de las mediciones a los componentes y el rendimiento a nivel de métodos. Los KPI de la red se enfocan principalmente en el tiempo que los paquetes tardan en ser enviados por la red, presentación de los datos y la detección de errores que puedan ocurrir debido a los altos volúmenes de datos. A su vez se debe dedicar el suficiente tiempo al efectuar las pruebas, ya que muchos de estos KPI pueden variar en su medida al transcurrir cierto tiempo, exponiendo diversos problemas a la luz como la no liberación de recursos.

El Proceso de Análisis Existen dos maneras de efectuar el análisis, mientras las pruebas se ejecutan o al terminar las mismas: (Shklar & Rosen, 2009) 

Análisis en Tiempo Real: esencialmente se espera a que algo ocurra o que las pruebas terminen sin ningún incidente aparente, si un problema en realidad se presenta es responsabilidad de las herramientas de monitorización de reportar el punto donde ha ocurrido en el escenario de la aplicación. Como un mínimo absoluto mientras se observa la ejecución se debe observar el tiempo de respuesta para cada transacción, el perfil de inyección de carga así como el estado en el que el mismo se encuentra, monitoreo del estado de los diversos servidores que han sido colocados como parte de la configuración y un registro de todos los errores que han ocurrido así como de los umbrales de rendimiento que se han colocado como adecuados.



Análisis Post-Prueba: Toda la información que es recopilada en un análisis en tiempo real es almacenada en un repositorio de información para su análisis una vez que se ha terminado de efectuar las pruebas, lo cual vuelve este tipo mucho más conveniente al utilizar herramientas de prueba automatizadas.

Principios de Datos de Rendimiento de Software Liu propine los siguientes principios de datos de rendimiento del software que pueden ayudar a asegurar que las decisiones de compensación mejoren el rendimiento y la escalabilidad, permitiendo basarlas en datos de rendimiento correctamente recopilados. Las acciones basadas en la recolección inapropiada de datos de rendimiento no producirán los resultados pretendidos.

36 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Cuando la función colectora del software y la escalabilidad prueban datos, los siguientes principios deberían ser obedecidos: 

Principio 1: El Principio del Hardware. Las pruebas de rendimiento y escalabilidad son diferentes a las pruebas de garantía de calidad. El desarrollo y las pruebas de garantía de calidad son típicamente efectuados en sistemas muy inferiores, mientras la función y las pruebas de escalabilidad deberían ser transmitidas en sistemas de última tecnología. Hay dos razones principales para el requisito de destinar sistemas de alto rendimiento estas pruebas: o

Los sistemas inferiores exhiben muy comportamientos de rendimiento diferente y de escalabilidad que lo que los sistemas de última tecnología. Los problemas de rendimiento y escalabilidad detectados en los sistemas inferiores simplemente pueden ser causados por hardware inadecuado que podrían estar ausentes si los sistemas de última tecnología son usados.

o

Probar el rendimiento y escalabilidad de una aplicación requiere usar suficiente carga, que no puede ser factible con sistemas inferiores.

o

El principio general para escoger hardware correcto para probar el rendimiento y escalabilidad del software es que debería estar próximo a lo que el cliente usará en la producción, o al menos bastante más poderoso que lo que los sistemas acostumbraron para el desarrollo y experimenta.

o

Si el software a probar es de clase empresarial, no tiene sentido efectuar las pruebas de rendimiento en sistemas operativos de escritorio con la pila entera del software incluyendo la base de datos instalada en ella.



Principio 2: El Principio de la Plataforma. Aquí la palabra plataforma se refiere a una colección de sistemas de software por encima del estrato del hardware en del cual depende un programa de aplicación, por ejemplo, el sistema operativo, sistema de bases de datos, y algún otro tipo de sistemas de software personalizado. Si el software soporta Windows y UNIX, entonces las pruebas deberían ser efectuadas en ambos sistemas operativos. Asimismo, si el software soporta Oracle y SQL Server de Microsoft, entonces las pruebas deberían ser ejecutadas en ambos sistemas de bases de datos. Demasiadas permutaciones no deberían ser utilizadas como una excusa para limitar el rendimiento y la escalabilidad experimenta para una combinación de plataformas sólo.

37 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web 

Principio 3: Principio De Realidad. Los escenarios y cargas de trabajo experimentales deben reflejar cómo usarían sus clientes su producto. A veces, podría ser difícil saber exactamente cómo un sistema de software será usado realmente por los usuarios. Es aceptable comenzar con algunos panoramas hipotéticos, pero debería ser tomado como un proceso iterativo porque los escenarios deberían ser refinados con el paso del tiempo.



Principio 4: El Principio de Volumen. Aunque sea aceptable usar cargas de trabajo más leves para las pruebas de regresión de rendimiento, se debe asegurar usar volúmenes grandes de usuarios y datos son utilizados para revelar la escalabilidad y rendimiento verdaderos de un sistema de software en escenarios reales de uso. Tales pruebas son especialmente interesantes a los clientes, como quieren saber si el software que planifican comprar se cumplirá los requisitos del número de usuarios y el volumen de datos que manejan. Además, los datos en que depende su experimento deberían ser realistas. Los datos sintéticos podrían ser demasiado perfectos y a veces puede no revelar los problemas de funcionalidad rendimiento que sólo los usuarios reales pueden descubrir.



Principio 5: El Principio de Fiabilidad. Las pruebas de escalabilidad y rendimiento deberían ser reproducibles con fluctuaciones aceptables al utilizar condiciones experimentales exactamente iguales. El requisito de reproducibilidad no es absoluto en el sentido que permite un nivel razonable de fluctuaciones, que idealmente debería ser sólo algunos por cientos o menos. Esto ayuda a evitar interpretar factores poco deterministas como problemas de rendimiento y a crear alarmas falsas de rendimiento para seguir vías erróneas hacia la solución de un problema de función del software.



Principio 6: El Principio de Calidad. Este principio mide la calidad global de los resultados de prueba. En algunos casos, los resultados de prueba pueden satisfacer todos los principios precedentes pero no pueden ser de alta calidad. Por ejemplo, si las pruebas utilizan datos en reserva que no se reservarán en el ambiente de producción debido a demasiados usuarios o un volumen de demasiado grande de datos, entonces los resultados de prueba serían inválidos sin importar que tan bien se vean y qué tan reproducibles sean. Es difícil definir una medida de calidad en general para los datos de prueba de función y de escalabilidad, ya que es dependiente del software.

38 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

CAPÍTULO III

MARCO METODOLÓGICO

39 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Enfoque Se ha optado por un enfoque cuantitativo para obtener el comportamiento de las variables a evaluar durante el experimento, en el cual se observarán los diversos tiempos de respuestas a dos cargas de trabajo muy importantes y complementarias entre sí, lo que es la captura masiva de información y posteriormente el análisis de la misma.

Tipo de Estudio El presente es un estudio explicativo. El entorno de experimentación es a su vez un entorno de producción en el cual se controla en todo momento la cantidad de usuarios concurrentes que acceden a un sistema de información estable. Durante la ejecución del experimento se crearon dos grupos que trabajaron utilizando la misma aplicación desplegada de distinta forma.

Hipótesis H1: La aplicación de servidor web que ejecuta la aplicación influye de manera sensible en el rendimiento de una aplicación de servidor web. H2: Los discos sólidos tienen influencia en la ejecución en general de las aplicaciones no únicamente en las consultas efectuadas a las bases de datos.

Variables 

Software o

Definición Operacional: pila de aplicación que se utilizará para los escenarios de pruebas.



Hardware o

Definición Operacional: entorno físico para ejecución de la aplicación web que será probada.



Rendimiento de Peticiones CRUD básicas: o

Definición Conceptual: carga de trabajo observada por la aplicación mientras se capturan y editan los datos a analizar.



Rendimiento de Peticiones de análisis: o

Definición Conceptual: Tiempo en que se obtienen los resultados del análisis de información.

o

Definición Operacional: Tiempo de procesamiento dedicado a la generación de un reporte de análisis de la información.

40 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Variable Rendimiento

Indicadores de

Peticiones 

CRUD básicas

Sub-Indicadores Subprocesos iniciados

Tiempo de respuesta



Consumo de Memoria RAM Cantidad



Actividad de Disco Duro

de

Usuarios

Concurrentes

Rendimiento de Peticiones de 

Cantidad

análisis

concurrentes

concurrentes utilizados para la



Ejecución en diversos hilos

consulta



Consumo de memoria RAM



Tiempo de procesador



Cantidad de núcleos

de

consultas Cantidad

de

hilos

de

procesador utilizados

Método de Recolección de Datos Durante la ejecución del experimento se mantienen los diversos monitores de rendimiento del sistema, lo cual permite recolectar el estado parámetros clave de rendimiento del servidor durante la utilización de la aplicación web. Los parámetros a recolectar son los siguientes: consumo de memoria RAM, tiempo de procesador, cantidad de núcleos de procesador, número de conexiones concurrentes a la base de datos.

Población y Muestra La aplicación objeto de la prueba de rendimiento es una aplicación elaborada en Symfony 2.3 que cuenta con un módulo de captura de datos y un módulo de análisis numérico para inteligencia de negocios, la misma aplicación es desarrollada en Django 1.6.

41 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

CAPÍTULO IV

ANÁLISIS DE LOS DATOS

42 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Grupo de Control Durante las pruebas en este entorno, que consta de dos servidores Xeon R720, equipados con dos procesadores Intel Xeon E5-2695 a 2.40GHz de velocidad de reloj, uno con 3 discos Samsung SSD 830 configurados en RAID 5 y otro con 3 Discos SAS de 10000 rpm en igual configuración, con tarjetas Gigabit Ethernet, cuentan con 64GB de RAM. El servidor con los discos sólidos es el servidor de base datos. Los estímulos internos a estas pruebas fueron las variaciones entre la ejecución típica de php como mod-php5 y FPM en Ngnix para PHP y de mod-wsgi en apache contra uWSGI con Ngnix para django. En esta prueba se obtuvieron los siguientes resultados: Tabla 2 Resultados Grupo de Control

Framework

JSON serialization

Single query

Multiple queries

django-ngnix

9236

4228

533

django-apache

9143

4068

484

symfony2

6256

4606

893

symfony2-ngnix

6334

5507

1258

php

67849

40830

6074

wsgi

65755

38600

2572

Los datos anteriores muestran representan consultas por segundo, con una consulta por respuesta en el caso de Single Query y 20 consultas por respuesta en Multiple Query.

Grupo 1 Durante las pruebas en este entorno, que consta de dos servidores Xeon R720, equipados con dos procesadores Intel Xeon E5-2695 a 2.40GHz de velocidad de reloj, 3 Discos SAS de 10000 rpm RAID 5, con tarjetas Gigabit Ethernet, cuentan con 64GB de RAM. El estímulo en este caso, fue el cambio del servidor provisto de discos sólidos, por un servidor típico de base de datos, además de los otros estímulos utilizados en la prueba anterior. En esta prueba se obtuvieron los siguientes resultados: Tabla 3 Resultados Grupo 1

Framework

JSON serialization

Single query

Multiple queries

django-ngnix

8312

3805

455

django-apache

8228

3661

421

symfony2

5630

4145

788 43 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web symfony2-ngnix

5700

4956

1098

php

61064

36747

5466

wsgi

59179

34740

2314

Resultados de Rendimiento de los Frameworks En ambos grupos se mostró la reducción de rendimiento debida al mayor grado de abstracción que incluye la utilización de un framework, esto se puede observar con mejor detalle en la prueba de serialización JSON, la cual arroja resultados entre 7 y 10 veces superiores al utilizar constructos puros del lenguaje en lugar de las abstracciones observadas por el framework.

Serialización JSON 80000 70000 60000 50000 40000 30000 20000 10000 0

SSD

SAS

Figura 7 Gráfica Rendimiento JSON

Las pruebas de consultas de bases de datos muestran una realidad muy clara, la abstracción y facilidad de uso de los ORM viene con un precio muy alto respecto al rendimiento, mostrando reducciones de hasta un 75% del rendimiento en el caso de Python.

44 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

Consulta Simple 50000 40000 30000 20000 10000 0

SSD

SAS

Figura 8 Gráfica Rendimiento Consulta Simple

Consulta Múltiple 7000 6000 5000 4000 3000 2000 1000 0

SSD

SAS

Figura 9 Gráfica de Rendimiento de consulta múltiple

En Python esta reducción tan drástica se debe a la naturaleza de la pila de ejecución del mismo, en el cual se penaliza de manera exagerada las llamadas constantes a funciones, por lo cual el código que se escribió no fue optimizado al máximo, los constructos más elegantes de Django permiten realizar muchas cosas con una sola línea de código, pero por motivos de tiempo no fueron optimizados hasta ese punto. PHP por otro lado se vio limitado por la cantidad de capas de capas de abstracción utilizadas dentro del lenguaje ya que Doctrine, el ORM de Symfony 2, utiliza decoradores para efectuar mapeo objetorelacional. 45 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Rendimiento de Discos Duros Remitiéndose a las mismas gráficas anteriores se puede observar que los discos SAS tuvieron un rendimiento alrededor de un 10% inferior a los discos sólidos, sin embargo durante la ejecución de las pruebas se apreció que el gestor de base de datos utilizado no estaba utilizando más de un núcleo del procesador, lo cual influyó mucho en la cantidad de consultas que se podían procesar. Otro aspecto importante es que existe un incremento respetable al utilizar conexiones persistentes a la base de datos, lo cual indica que establecer una conexión es bastante costoso en cuanto a rendimiento. De especial consideración fue el lanzamiento de las consultas de análisis de datos mientras se estaban efectuando las consultas de creación, lectura y edición de manera concurrente, ya que las consultas de análisis se veían afectadas por el bloqueo a nivel de filas que efectuaban las consultas CRUD.

Rendimiento de Servidor Web Se puede notar con claridad el incremento de rendimiento que posee Ngnix sobre Apache, en su mayoría esto se debe a que Ngnix no posee una arquitectura de complementos sino que realiza la mayor parte de sus tareas llamando a scripts de FastCGI como ser uWSGI para Python y FPM para PHP. A pesar de esto, el modelo de hilos de Python y PHP influyo en la cantidad de respuestas que se podía entregar. Por esto durante todo el tiempo debido al diseño de las aplicaciones, se observó que se llevaba más tiempo ejecutando el código del mediante el ORM que en capas más inferiores de las aplicaciones. También se puede observar que donde más influye el tipo de servidor Web es durante las consultas a la base de datos, esto normalmente se debe a que Apache en su modo habitual de funcionamiento llama al complemento del lenguaje de programación y una vez que entrega la respuesta lo descarta, por lo cual debe iniciarse una conexión a la base de datos durante cada petición HTTP.

46 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

CAPÍTULO IV

CONCLUSIONES Y RECOMENDACIONES

47 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web 1. La correcta elección de la aplicación de servidor web que a utilizar entregará un aumento de rendimiento estimado entre el cinco y diez por ciento, sin importar el framework utilizado, debido a que gran parte de la carga de trabajo depende del establecimiento de conexiones al gestor de base de datos. 2. Durante la ejecución de una aplicación es de vital importancia que los gestores de bases de datos se encuentren separados físicamente de los servidores de aplicación, debido a la gran diferencia en la carga de trabajo que ambos presentan. 3. Los discos sólidos representan una mejora en las consultas en todo momento, pero su rendimiento se ve magnificado si el gestor de base de datos soporta de manera correcta un esquema de multiprocesamiento que permita utilizar más de un núcleo de procesador de manera eficiente. 4. La abstracción de los frameworks vienen con un costo importante, si bien permiten recortar el tiempo de desarrollo, gran parte de la abstracción que presentan influye mucho en la cantidad de hardware que se requiere para la ejecución de las aplicaciones desarrolladas con ellos. 5. La parte más crítica en el rendimiento de un framework es su ORM, por lo tanto es recomendable evitar el procesamiento de objetos puros en conjuntos de datos muy grandes, debido al alto costo de la conversión entre filas y objetos. Se recomienda, si el ORM lo soporta, utilizar un conjunto de instrucciones que permitan esquivar el mapeo objetorelacional cuando se vayan a efectuar operaciones sobre cantidades masivas de información. 6. La escalabilidad de Python se ve limitada por su Bloqueo de Interprete Global (GIL por sus siglas en inglés) el cual limita la ejecución de todo script a un solo núcleo si no se usan múltiples procesos, por eso es importante configurar a uWSGI con una cantidad mínima de procesos de trabajo según la cantidad de procesadores y núcleos disponibles.

48 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

Bibliografía Django Software Foundation. (2013, 11 10). Django - The Django Project. Retrieved from Django Project: http://djangoproject.com/ DocForge. (2013, 11 13). Web Application Framework - DocForge. Retrieved from DocForge Software Development Resources: http://docforge.com/wiki/Web_application_framework Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Gourley, D., Totty, B., Sayer, M., Aggarwal, A., & Reddy, S. (2002). HTTP: The Definitive Guide. Sebastopol: O'Reilly & Associates, Inc. Internet Engineering Task Force. (2013, Septiembre 25). Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Retrieved from Internet Engineering Task Force Data Tracker: http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ Liu, H. H. (2009). Software Performance and Scalability: A Quantitative Approach. Hoboken: John Wiley & Sons, Inc. Meier, J., Farre, C., Bansode, P., Barber, S., & Rea, D. (2007). Performance Testing Guidance for Web Applications. Redmond: Microsoft Corporation. Molineaux, I. (2009). The Art of Application Performance Testing. Sebastopol: O'Reilly Media. Mozilla Foundation. (2014, Julio 14). Mozilla Developer Network. Retrieved from Getting started with app development: https://developer.mozilla.org/en/Apps/Getting_Started Shklar, L., & Rosen, R. (2009). Web Application Architecture: Principles, Protocols and Practices. Chichester: John Wiley and Sons Ltd. Souders, S. (2009). Even Faster Websites. Sebastopol: O'Reilly Media, Inc. TechEmpower. (2013, 11 12). TechEmpower. Retrieved from http://www.techempower.com/benchmarks/ Tiobe Software. (2013, Octubre 1). Tiobe Programing Index. Retrieved from http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html World Wide Web Consortium. (2004, Febrero 11). Web Services Architecture. Retrieved from http://www.w3.org/TR/ws-arch/ World Wide Web Consortium. (2010, Diciembre 14). Mobile Web Application Best Practices. Retrieved from World Wide Web Consortium: http://www.w3.org/TR/mwabp/

49 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

ANEXOS

50 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Hardware en el que se ejecutaron las pruebas

51 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web Monitores de Rendimiento durante las pruebas

52 | P á g i n a

Análisis del Desempeño y Escalabilidad de Frameworks Web

53 | P á g i n a