Resumen - Patrones

UNA COMPARACIÓN DE IMPLEMENTACIONES DE JABÓN Y DESCANSO DE UN MARCO MEDIO DE INTERPCIÓN DE INTERACCIÓN BASADO EN EL SERVICIO 4.1 Prueba de solicitud sincrónica Uno de los principales objetivos del componente del controlador es consultar constantemente al administrador de complementos para un conjunto global de dispositivos activos conectados a esa máquina, de modo que pueda usar la información de perfil de su dispositivo para determinar para qué aplicaciones son adecuadas. Dado que no hemos analizado ningún esquema de almacenamiento en caché para este marco, tenemos la garantía de que dicho escaneo por parte del controlador conlleva múltiples consultas a un servidor de Portal remoto para la aplicación, dispositivo o incluso los perfiles de usuario aplicables cada vez que detecta un nuevo dispositivo. Esta prueba intenta modelar una serie creciente de solicitudes de perfil sincrónicas que emanan de un solo host a un servidor de Portal remoto para determinar cómo se realiza cada implementación en estas condiciones. Como antes, la métrica integral para esta prueba es la latencia de ida y vuelta promedio para cada conjunto de solicitudes síncronas, y se mide utilizando el mismo método empleado en la prueba de referencia del servicio.

Figura 8: Prueba de solicitud síncrona de portal: latencias de cliente La latencia de la implementación basada en SOAP siempre sirve como el límite superior para su contraparte REST (Figura 8). Sin embargo, la disparidad entre las implementaciones es relativamente minúscula hasta la prueba de "100 solicitudes de clientes síncronos". En este punto, la latencia promedio de la solicitud del cliente SOAP era casi el doble que la del cliente REST. Esta discrepancia es probablemente un artefacto de la implementación de la biblioteca de Axis2 (Apache Software Foundation 2008) que alimenta al cliente basado en SOAP (además del servidor de servicios web del Portal) o también es posible que haya una gran cantidad de tráfico de red ulterior cuando esto ocurre. prueba se ejecutó repetidamente; Así, sesgando los resultados medios. En cualquier caso, el cliente REST parecía capaz de procesar de forma flexible numerosas solicitudes de servicio HTTP síncronas mientras se tendía hacia arriba de una manera estrictamente lineal. Por otro lado, el diagrama muestra claramente las tendencias del cliente SOAP hacia arriba de manera exponencial a medida que avanzaban las pruebas.

4.2 Prueba de complejidad de la aplicación Hasta ahora, los perfiles de aplicación insertados, actualizados, recuperados y eliminados del modelo de datos del Portal del lado del servidor para cada una de las pruebas anteriores han sido de naturaleza bastante simplista. Se anticipa que las aplicaciones "del mundo real" serán generalmente órdenes de magnitud más grandes que las aplicaciones falsas "Tetris" y "VT Dungeon Crawler" modeladas en el conjunto de pruebas del Portal. Como tal, creemos que es importante modelar las acciones de aplicación y los contextos de una variedad de aplicaciones populares del mundo real para determinar el impacto general de estos perfiles potencialmente masivos y si su rendimiento se desvía considerablemente de los perfiles de aplicaciones que hemos visto. Utilizando en las pruebas anteriores. Elegimos examinar los perfiles de las aplicaciones, en particular, porque generalmente serán más grandes que sus homólogos de perfil de dispositivo y de perfil de usuario. Además, los perfiles de usuario son esencialmente solo asignaciones entre los componentes del dispositivo y las acciones de la aplicación, por lo que los perfiles completos de la aplicación generalmente serán de mayor tamaño. Por lo tanto, para los fines de esta prueba, se utilizaron tres tipos de perfil de aplicación: pequeño, mediano y grande. El perfil pequeño es la aplicación de Tetris que usamos en el banco de pruebas de servicio y las pruebas de solicitud síncrona que contiene cuatro acciones de la aplicación (rotar en el sentido de las agujas del reloj, rotar en el sentido contrario a las agujas del reloj, mover hacia abajo, mover hacia la izquierda / derecha) y un contexto. Este perfil representa una versión ficticia y genérica de Tetris (The Tetris Company 2009), un juego de rompecabezas bidimensional que involucra la manipulación de secuencias decrecientes de tetrominos (Gardner 1988). El perfil contiene la cantidad base de acciones requeridas. Para el perfil de aplicación medio, implementamos las acciones y contextos de aplicación de HalfLife. Este juego fue el progenitor de los videojuegos de disparos en primera persona (FPS) contemporáneos y, se puede argumentar, sirvió como el arquetipo de todos los juegos de FPS que se lanzaron después. Aparte de ciertas variaciones específicas del juego, el esquema de control (y, posteriormente, las acciones / contextos de las aplicaciones) para Half-Life demuestra acciones que son bastante universales dentro del género FPS. Estas acciones les permiten a los usuarios navegar dentro de un entorno tridimensional simulado (generalmente usando un mouse y un teclado, en tándem), interactuar con varios elementos ubicados dentro de este entorno y manipular el arsenal de armas variadas del usuario desde una perspectiva de primera persona. Finalmente, el gran perfil de la aplicación representa acciones y contextos de la aplicación del popular MMORPG (World of Warcraft (Blizzard Entertainment, Inc. 2009) de World of Warcraft). En este momento, World of Warcraft (WoW) es el MMORPG más popular que existe y se juega en todo el mundo por millones de personas. Proporciona una gran cantidad de acciones para permitir que la personalización del usuario supere su base de usuarios increíblemente grande (y diversa).

Para cada tipo de perfil (pequeño, mediano y grande), se envían una serie de cinco solicitudes de servicio "Obtener perfil de aplicación" para cada implementación del componente de transmisión de datos y se registra su latencia promedio y el tamaño total del paquete para cada solicitud. Estas métricas se capturan de la misma manera que la prueba de referencia del servicio.

Figura 9: Prueba de complejidad de la aplicación del portal: latencia (izquierda) y tamaño del paquete (derecha) De manera interesante, la Figura 9 (izquierda) muestra que la implementación de SOAP tiene una latencia grabada ligeramente más pequeña para la solicitud de recuperación del perfil de la aplicación de Tetris más pequeña y una latencia mucho mayor para la solicitud de World of Warcraft más grande. A la inversa, la implementación de REST produjo latencias similares para todas las solicitudes dentro de los 50 milisegundos de cada una. Esto es especialmente sorprendente teniendo en cuenta los tamaños de paquete registrados en la Figura 9 (derecha). En todos los casos, los tamaños de los paquetes están dominados en última instancia por la carga útil XML que llevan y no por el encapsulado de paquetes HTTP o las trampas relacionadas con la arquitectura (como el sobre SOAP, etc.). Dicho esto, muestra claramente que solo existe una pequeña diferencia en el tamaño de los paquetes para los perfiles de aplicación pequeños, medianos y grandes. Esto lleva a la conclusión de que el gran aumento en la latencia para las solicitudes de perfiles de aplicaciones medianas y grandes se origina en la biblioteca SOAP subyacente utilizada en la implementación SOAP del componente de transmisión de datos: Axis2. Una vez más, la implementación de REST demuestra ser la mejor opción. A pesar de que el perfil de aplicación grande es casi 40 veces más grande que el perfil más pequeño, la implementación del componente de transmisión de datos REST produjo un aumento muy leve y lineal en la latencia en proporción a los tamaños de transacción de paquetes subyacentes. Por el contrario, la latencia de la implementación de SOAP aumentó exponencialmente en proporción al tamaño de la transacción del paquete. 4.3 Análisis de los resultados de la prueba El marco SOAP de Axis2 se eligió, por varias razones, para servir como la implementación de SOAP para la arquitectura que sustenta el componente de transmisión de datos del Portal. El principal de estos motivos es el hecho de que, a partir de la lista mantenida por el W3C de todas las implementaciones SOAP 1.2 registradas anteriores y presentes, el proyecto Apache Axis es el único que aún está activamente desarrollado, es de código abierto con una licencia no restrictiva e

implementado en un montón de diferentes lenguajes de programación (incluyendo tanto Java como C / C ++). Además, los comentarios de la comunidad y varios estudios (Davis y Parashar 2002) indican que Axis2 es más rápido que sus pares, en términos de la latencia general del procesamiento de mensajes SOAP. Como tal, se usó para representar la implementación prototípica de SOAP en la serie de pruebas. Al analizar los resultados de las solicitudes síncronas y las pruebas de complejidad de la aplicación, las latencias en las que incurrió la implementación SOAP del componente de transmisión de datos se etiquetaron efectivamente como artefactos derivados del marco Axis2 subyacente. Si tomamos en cuenta que la disparidad de latencia promedio entre las implementaciones del componente de transmisión de datos REST y SOAP fue desproporcionada con respecto a la disparidad de tamaño de mensaje promedio, entonces una conclusión lógica es que la estructura subyacente de Axis2 es la culpable de la latencia de SOAP desproporcionadamente alta. Al profundizar en la documentación de Axis2, observan que existe un proceso canalizado para cada mensaje SOAP saliente en el que "el remitente crea el mensaje SOAP [,] los manejadores del Eje realizan las acciones necesarias en ese mensaje [, y] el remitente de transporte envía el mensaje" ( Apache Software Foundation 2008). En otras palabras, este marco es responsable de serializar el mensaje SOAP saliente en XML, pasar el resultado a través de una serie de manejadores no especificados y, finalmente, transmitir el mensaje XML resultante a un servidor SOAP remoto a través de HTTP. Este enfoque combinado parece ser un culpable probable del notable incremento en la latencia de ida y vuelta promedio cuando se utiliza el marco Axis2. Compare esto con la implementación de REST, en donde se crea un paquete HTTP saliente, se adjunta una carga útil XML pertinente para un servicio web determinado, y este paquete se transmite inmediatamente a una URL específica de REST. 5. Conclusión Como resultado de las pruebas, podemos afirmar definitivamente que la implementación de REST del componente de transmisión de datos demostró ser más eficiente en términos de ancho de banda de red utilizado cuando se transmiten solicitudes de servicio a través de Internet y la latencia de ida y vuelta incurrida durante estas solicitudes. . El conjunto de servicios web habilitado por el componente de transmisión de datos se adhiere estrictamente al patrón CRUD, en el que los servicios permiten crear, leer, actualizar o eliminar perfiles del repositorio de datos del lado del servidor. La implementación de REST fue mucho mejor para este modelo de conjunto de servicios web en comparación con el comportamiento similar al RPC empleado por la implementación de SOAP y, en general, produjo resultados mucho mejores cuando el componente se probó en diferentes escenarios específicos de dominio.