Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Primer Cuatrimestre de 2009 Concerns y Tácticas de Performance Buenos Aires, 20 de Abril de 2009 Cátedra de Ingeniería de Software II FCEN UBA,

2 Conceptos Generales PERFORMANCE December 1995; Mario Barbacci Mark H. Klein Thomas A. Longstaff Charles B. Weinstock; Technical Report CMU/SEI-95-TR-021 ESC-TR , Quality Attributes 2

3 Performance Es la habilidad del sistema para ejecutar en forma predecible dentro del perfil de desempeño definido. Performance vs Speed Existe la noción que mala performance puede ser resuelta a través de procesadores más poderosos y canales de comunicacion con mayor ancho de banda Mas rápido puede ser mejor pero insuficiente para garantiza cumplir con contratos donde hay requerimientos temporales. El objetivo de computación veloz es minimizar el tiempo promedio de respuesta para ciertos servicios, mientras que el objetivo de computación en tiempo real es alcanzar metas individuales de tiempo para cada servicio. December 1995; Mario Barbacci Mark H. Klein Thomas A. Longstaff Charles B. Weinstock; Technical Report CMU/SEI-95-TR-021 ESC-TR , Quality Attributes 3

4 Concerns Tiempo de Respuesta Turnaround Time Responsiveness Throughput Thinking Time Predictability Peak load Scalability

5 Tiempo de Respuesta (latencia) Tiempo que transcurre entre que se emitió el requerimiento y se recibe la respuesta del servicio. Esto puede referirse a una transacción entre un usuario y un sistema o a un evento interno. Responsiveness En sistema interactivos, el nivel de respuesta individual de cada interacción y como en su conjunto contribuyen a la productividad (impacto en usability) Turnaround time Medimos una transacción individual, usualmente cuando tenemos procesos complejos con requerimientos individuales de performance 5

6 Ejemplo La entrega se realiza a los 25 cajeros en promedio dentro de una ventana de tiempo que no debe superar 30 minutos Esta actividad presenta tres ventanas entre las 7.30 y 8.00 hs, y 11 hs y y hs. Ejemplo peak load :1200 tiendas, que dentro de las tres ventanas generan cada una 25 transacciones dentro de los 30 minutos.

7 Throughput Cantidad de requerimientos que el sistema puede atender dentro de una ventana de tiempo definida. Usualmente cuando el tiempo de respuesta es mas pequeño el throughput aumenta, sin embargo la relación es mas compleja: Bajo 10 usuarios concurrentes el tiempo promedio de respuesta es de 2 segundos. Bajo 100 usuarios concurrentes el tiempo promedio de respuesta es de 4 segundos. Bajo 500 usuarios concurrentes el tiempo promedio de respuesta es de 4 segundos. Predictability Además del throughput y el promedio de tiempo de respuesta debemos identificar el tiempo máximo de respuesta tolerable para el usuario. Jitter se denomina a la variación del tiempo de respuesta con respecto al promedio. 7

8 Ejemplo la oficina de ventas requiere conocer el dinero disponible en banco y realizar una predicción del dinero que será depositado la central requiere emitir un reporte que indica el dinero disponible estimado El tiempo de respuesta esperado para la emisión de este reporte no debe superar los dos minutos Ejemplo response time : no debe superar los dos minutos.

9 Throughput Thinking Time : El tiempo que transcurre entre eventos productos de la necesidad de procesamiento del cliente. El nombre viene de relevar el tiempo que requiere el usuario como mínimo para poder generar una nueva transacción. Al usuario le demora 1 segundo poder ingresar una nueva transacción Bajo el escenario anterior de 10 usuarios y 2 segundos de tiempo de respuesta, podemos tener un event rate de 200 transacciones por minuto. (1 s (thinking) + 2 s (turnaround) = 3 s/transacción) 9

10 Tiempo de respuesta Throughput Peak load: El tiempo de respuesta individual de cada transacción empeora a medida que la cantidad de transacciones aumenta. knee Punto en el cual el sistema está no disponible 10 Workload

11 Capacity Schedulable utilization: Representa la máxima carga que el sistema puede soportar sin cambiar su nivel de servicio. Los escenarios de performance deben contemplar comportamiento bajo sobrecarga. Es simple realizar ataques a un sistema que no controla el event-rate dejándolo no disponible si esto aumenta su nivel de vulnerabilidad. Scalability Capacidad del sistema de adaptarse a mayores cargas de trabajo. Vegetative Transient (bursty traffic) 11

12 Escenarios de Performance Portion of Scenario Source Stimulus Artifact Environment Response Response Measure Possible Values One of a number of independent sources, possibly from within system Periodic events arrive; sporadic events arrive; stochastic events arrive System Normal mode; overload mode Processes stimuli; changes level of service Latency, deadline, throughput, jitter, miss rate, data loss

13 ARQUITECTURA Y PERFORMANCE Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission. 13

14 Software Components & Efficiency Conservar los componentes pequeños Idealmente cada componente debería prestar un único servicio y tener un único propósito en el sistema. Esto va en contra del re-uso puesto que los componentes off-the-shelf suelen incluir mucha funcionalidad por diseño y ser bastante extensos En muchos casos la inversión en optimización de uso de memoria y recursos es alta con lo cual compensan esta limitante. 14

15 Conservar los componentes pequeños Ejemplo IS2000 El Imager se encarga solo del fitro aplicado a las imágenes raw que entrega el Framer. Esto permite poder implementar algunos filtros por hardware e incluso asignar infraestructura puntual para optimizar cada filtro particular 15

16 Software Components & Efficiency Conservar interfaces simples y compactas El componente debería exponer solo los servicios que tienen que ser visibles desde el exterior. Interfaces generalizadas para diversos usos y escenarios, para diversidad de potenciales clientes, la eficiencia podría verse comprometida. Es posible que se requiera usar el componente con diferentes tipos de adaptador para especializarlo en diferentes contextos. Alternativamente podemos reducir la interfaz publica al denominador común y realizar conversiones internas si aplica. Otra posibilidad es incorporar conectores con responsabilidad de conversión. Contrariamente, una interface pelada hasta los huesos puede impactar negativamente en cuanto a eficiencia. pipe-and filter en sistemas basados en Unix donde los filters se apoyan en ASCII data streams (untyped) para maximizar reusabilidad, requieren que el componente (filter) continuamente haga conversión a datos tipados impactando performance. Conservar interfaces simples y compactas podría impactar negativamente en la re-usabilidad del componente. 16

17 Software Components & Efficiency Habilitar múltiples interfaces a la misma funcionalidad (contraparte de la anterior) Los componentes podrían necesitar proveer servicios a múltiples clientes ejecutando en diversas plataformas codificando bajo diferentes estándares. En estos casos el arquitecto podría optar por implementar esto vía múltiples componentes que replican funcionalidad de otro componente. En general esto dañaría la performance del sistema. Una excepción sería que la instancia de componente replica tenga optimizaciones propias de la plataforma. Otra opción es utilizar un wrapper del componente usando un conector adaptor que realice las conversiones necesarias (el adaptor introducirá detrimento de performance) Una tercera opción es construir un componente tal que nativamente exporte múltiples interfaces. Esta solución tiene el peligro de estar sobredimensionando el componente (su interfaz) en casos donde finalmente no sea requerido contar con múltiples interfaces. 17

18 Habilitar múltiples interfaces a la misma funcionalidad 18

19 Software Components & Efficiency Separar componentes de procesamiento de componentes de gestión de datos El reducir las consideraciones de diseño del componente a la gestión de datos da mayor libertad para optimizarlo (análogamente si es de procesamiento). En sistemas data-intensive, esta separación permite disponer de los datos con mayor facilidad requeridos por otros componentes clientes de la Arquitectura. 19

20 Software Components & Efficiency Acerca de la separación de datos de meta-datos Podría no estar claro a priori cómo los datos son estructurados y deben ser usados. Podríamos requerir descubrir esto en runtime y por esto ser necesaria la separación. Separar los datos de los metadatos reduce el requerimiento de memoria y transferencia en las invocaciones entre componentes que ya realizaron un acuerdo en cuanto a la estructura de la información. Cada vez que un paquete es enviado desde un proceso a otro no sería necesario redundar en enviar la información de descripción de los datos. Por otro lado, mantener datos y metadatos separados podría requerir mayor procesamiento para computar la identificación de proceso requerido acorde a la definición en los metadatos. 20

21 Software Connectors & Efficiency Los conectores encapsulan todas las prestaciones vinculadas a interacción del sistema, gran parte de las propiedades deseables del sistema se vincularán a la correcta selección de los conectores. La variedad de servicios que el conector puede ofrecer, pueden ir desde el nivel mínimo de servicios requeridos hasta servicios complejos y que consuman recursos del sistema e introduzcan latencia. 21

22 Software Connectors & Efficiency Consideraciones para seleccionar connectors Entender las necesidades de interacción Identificar todos los atributos relevantes de la interacción Seleccionar conectores candidatos Identificar los compromisos que implica cada candidato Analizar las propiedades resultantes del attachment entre los conectores y los componentes 22

23 Software Connectors & Efficiency Clases de servicio provistas Comunicación Transmisión de datos entre los componentes. Coordinación Transmisión de control entre los componentes. Conversión Transforman la interacción requerida por un componente por la interacción provista por otro. Infraestructura (Facilitation). Servicios extendidos de scheduling, load balancing, y otras necesidades de interacción más compleja requerida por los componentes. Cada conector provee al menos una de las clases de servicios listados 23

24 Software Connectors & Efficiency Forma en que brindan los servicios de interacción Procedure call Event Data access Linkage Stream Arbitrator Adaptor Distributor 24

25 Procedure call 25

26 Event 26

27 Data Access 27

28 Linkage 28

29 Stream 29

30 Arbitrator 30

31 Caso Client-Server Client call Server Donde deberíamos resolver el problema de time out de call? CLIENT = (call->wait->continue->client). SERVER = (request->service->reply->server). CLIENT_SERVER = (CLIENT SERVER) /{call/request, reply/wait}. CLIENT = (call->calling), CALLING = (wait->continue->client timeout->client ). Wrapper Client adaptor call Server 31

32 Adaptor 32

33 Distributor 33

34 Software Connectors & Efficiency Utilice conectores que hagan broadcast con cuidado. El sistema podría poseer mayor flexibilidad en el caso de usar conectores que son capaces de entregar información por broadcast. Sin embargo, esta flexibilidad puede ser a costa de la seguridad y eficiencia del sistema Dada una interacción que involucre a mas de dos componentes, podríamos tentarnos con usar broadcast para implementarla. Los componentes no estaban involucrados en la interacción, deben descartar el paquete, y los canales de comunicación se cargarían innecesariamente. Conectores multicast mantienen mapeo explicito entre los componentes que participan de una interacción de este tipo. También podemos considerar mecanismos de publishsubscribe (asynchronous) para resolver estos casos si el mapeo es en runtime. 34

35 Software Connectors & Efficiency Hacer uso de conectores asincrónicos cuando sea posible. El uso de conectores sincrónicos hace que todos los componentes que interactúan deban alinear el tiempo de sus procesos. La sincronización hace que el tiempo global sea el peor tiempo del conjunto. Si el componente puede iniciar la interacción y continuar su proceso hasta ser notificado esta contención de recursos por el sincronismo no sucede. Cuando la cantidad de componentes es grande, el conector tiene que mapear los clientes que iniciaron cada request con las notificaciones de finalización, esto agrega complejidad computacional al conector siendo nocivo para la performance. 35

36 Software Connectors & Efficiency Use transparencia de localización juiciosamente Transparencia de localización protege a los componentes de un sistema distribuido de los detalles de despliegue. Esto permite diseñar los componentes como si las interacciones fueran locales. Esto promueva la adaptabilidad y redeployment de los mismos. Las interacciones remotas son mucho mas lentas (40 veces o aún más), con lo cual aunque haga transparente la localización no así lo sería el impacto. Esto hace que para conseguir transparencia total deba planear en base al peor caso (localización remota siempre) 36

37 Use transparencia de localización Juiciosamente 37

38 Configuración de Arquitectura & Efficiency Conservar cerca componentes que interactúan frecuentemente El numero de indirecciones a través de las cuales uno o más componentes se comunican afecta la eficiencia de la interacción. Prefetching y caching pueden mejorar este problema. Anticipamos la información requerida por el componente y reducimos la latencia por la espera de la info cuando se la requiere. 38 Shaw, M. and Garlan, D. Software Architecture: Perpectives on an Emerging Discipline. 242 pgs., Prentice Hall, 1996.

39 Configuración de Arquitectura & Efficiency Seleccionar y ubicar cuidadosamente los conectores en la arquitectura. Un conector puede brindar una gran variedad de servicios a la Arquitectura. Un mismo conector podría estar brindando diferentes servicios a diferentes conjuntos de componentes interactuantes. En general los conectores soportaran un superset de las necesidades de interacción reales requeridas, el resto de los servicios no serán usados pero sí consumirán recursos. Por esta razón debemos seleccionar conectores que brinden el mínimo conjunto de servicios requeridos según requiere cada interacción. Componentes que soportan múltiples interfaces (puertos) colaboran en optimizar este punto. 39

40 Configuración de Arquitectura & Efficiency Considerar el impacto (negativo) en eficiencia de seleccionar estilos adecuados Ejemplos Interacciones asincrónicas como publish-subscribe podrían no ser efectiva si existen requerimiento de tiempo real; Grandes sistemas de estilo repository podrían no ser adecuados para satisfacer restricciones de memoria; Sistemas que procesan streams de datos podrían ser diseñados usando event-based architectures, pero la transformación de los streams en eventos discretos acarrea penalidades de computación; 40

41 TÁCTICAS PARA PERFORMANCE 1997; Software Architecture in Practice; Len Bass, Paul Clements, Rick Kazman 41

42 Tactics

43 Tactics Resource demand/consumption Computational efficiency Computational overhead Manage Event Rate Control Frecuency of Sampling Resource arbitration Scheduling Dispatching Priority assignment: fifo, deadline of request, semantic importance Resource Management Concurrency Increase availability Maintain multiple copies of computation and data

44 Resource Demand Las ráfagas de eventos son el origen de la demanda de recursos, el impacto que tiene en performance el arribo de evento es: Tiempo entre eventos. Consumo de recursos de cada evento. Esto nos divide las tácticas que tenemos para gestionar la demanda de recursos. 44

45 Resource Demand Reducir el consumo de recursos de cada evento. Incrementar la eficiencia computacional Reducir procesamiento repetido Calcular vs almacenar (ejemplo optimización consultas motor BD) Optimización algorítmica optimizar computo recurrente -> Profiling Reducir el overhead computacional Revisar el uso de intermediarios. (tradeoff con modificabilidad) Revisar servicios innecesario en los conectores (i.e. encryption - tradeoff con seguridad) 45

46 Resource Demand Reducir la cantidad de eventos procesados. Gestionar la frecuencia de sampling Sincronizar la velocidad de sampling con la posibilidad de procesamiento (basado en el role servidor) (Ejemplo gigabit network) Gestionar la tasa de evento generados. (basado en el role cliente) (Ejemplo protocolo TCP) Limitar el tiempo de ejecución Algunos procesadores desalojan el proceso por timeout. Controla el máximo numero de eventos encolados y por ende controla la longitud de los streams de eventos Routers y discard packet es un ejemplo de esto. 46

47 Resource Management Introducir Concurrencia El Blocked time es consecuencia de la serialización de procesos que presentan dependencias (de recursos o de dependencias entre procesos). Separar actividades que pueden ser concurrentes permite aumentar el throughput. Una vez que la concurrencia fue introducida el desafío es la asignación correcta de recursos a procesos (load balancing) para explotar esto al máximo. Mantener múltiples copias de computación y datos El propósito de replicar es reducir la contención de recursos. Si el recurso es un proceso que debe finalizar para atender el siguiente evento en el stream, la contención existe y está justamente en los recursos físicos requeridos para el proceso en espera. En modelos client-server esta separación libera parte de los recursos centrales del servidor. El uso de Cache permite por réplica reducir la contención del recurso de almacenamiento. Notar que adicionalmente, permite optimizar la performance de las sucesivas lecturas que suceden entre dos escrituras. Notar que al replicar datos introducimos problemas de sincronización que no son triviales. Incrementar la disponibilidad de recursos En algunos casos esta táctica es la mas recomendable y usualmente la más económica. Podemos reducir latencia a partir de procesadores más rápidos o simplemente procesadores adicionales, memoria adicional, y redes más rápidas. Debemos considerar el tradeoff cost/performance en estos casos. 47

48 Resource Arbitration Cada vez que hay contención de recursos hay necesidad de scheduling. La definición que haya hecho de clases de servicio tiene gran impacto en la estrategia de scheduling La misión de la políica de scheduling es prevenir starvation y promover fairness El proceso de scheduling tiene dos partes: Asignación de Prioridad Cada nuevo proceso que demanda recursos que están ocupados se le asigna una prioridad según sea la política de scheduling Dispatching Una vez que los recursos que un proceso está esperando quedan disponibles, los debo asignar e iniciarlo 48

49 Algunas Políticas de Scheduling First-in/First-out Las colas FIFO tratan a todos los requerimientos de recursos como iguales y los satisfacen por turnos. Un problema de esto es que un proceso podría estar trabado detrás de otro que se toma mucho tiempo para generar una respuesta. Esto afecta directamente el throughput. Si todos los procesos son iguales en el sentido de prioridad y de consumo de recursos, esto no es un problema Fixed-priority Asigna a cada requerimiento una prioridad y entrega los recursos siguiendo el orden de esta prioridad. Esta política asegura que los requerimientos con origen de mayor prioridad reciban mejor servicio, admitiendo que los requerimientos de menor importancia hagan que el origen de los mismos pueda estar trabado un tiempo arbitrariamente largo. Estrategias de priorización: Importancia semántica: Cada stream recibe una prioridad estática de acuerdo a características obtenidas del tipo de tarea. deadline monotonic: Asigna mayor prioridad a streams con menor deadline. Esto es muy útil para real-time systems. rate monotonic: Asigna mayor prioridad a streams con menor período de uso. Esto promueve el throughput. 49

50 Algunas Políticas de Scheduling (cont) Dynamic priority scheduling: round robin. Ordena los requerimientos y luego cada posibilidad de asignación que tiene, entrega el recurso al siguiente proceso en espera en este orden. Un modo especial de round robin es el cíclico donde las asignaciones suceden en intervalos de tiempo fijos. earliest deadline first: Asigna mayor prioridad basado en deadline más próximo. Static scheduling Se determinan los puntos de desaolojo de los procesos y la secuencia de asignación de recursos de manera offline. 50

51 Tactics

52 Fin