Capacity planning

Entendiendo y caracterizando la carga de trabajo

Benchmarcks
Modelos de desempeo a nivel de sistemas
Modelos de desempeo a nivel de componenetes
Modelos de desempeo Web

Andrs H. guila Gaete

Entendiendo y
caracterizando la
carga de trabajo
(Workload)

Introduccin
El funcionamiento de un sistema distribuido con muchos
clientes, servidores y redes dependen fuertemente en las
caractersticas de su carga. As, el primer paso en algn
estudio de evaluacin de funcionamiento debe entender y
caracterizar la carga de trabajo.
La carga de trabajo de un sistema puede ser definido como un
conjunto de todas las entradas que el sistema recibe de su
ambiente durante algn periodo de tiempo
Uno debe construir un modelo de Workload que capture las
caractersticas ms relevantes (tiempo de llegada y
terminacin, tiempo de cpu, N de operaciones I/O, etc.).

Introduccin
Los modelos de carga de trabajo (Workload) exponen
varias ventajas sobre cargas de trabajo actual o
rastros. Es posible cambiar parmetros del modelo
para reflejar cambios del sistema o en el actual
Workload.
Las caractersticas y parmetros que describirn la
carga de trabajo depende del objetivo del estudio.
Por ejemplo; si uno quiere estudiar el costo-beneficio
para crear un servidor Proxy para un sitio Web,
entonces las caractersticas de carga de trabajo
necesarias para el estudio son las frecuencias de
referencia de documentos, concentracin de
referencias, tamao de documentos y tiempos de
interreferencia.

Caracterizacin
Los pasos comunes para seguir cualquier proyecto de
caracterizacin de carga de trabajo incluyen:
1.

2.

3.

4.
5.
6.

La especificacin de un punto de vista de lo cual la carga de

trabajo ser analizada.
Determinar del conjunto de parmetros que capturan las
caractersticas ms relevantes de la carga de trabajo para el
objetivo del estudio.
Supervisin del sistema para obtener los datos de funcionamiento
crudo.
Anlisis y reduccin de datos de funcionamiento.
Construccin de un modelo de carga de trabajo.
La verificacin que la caracterizacin captura toda la informacin
de funcionamiento importante.

Caracterizacin de
procesos de Workload
Actual
Workload

a
b
s
t
r
a
c
c
i

Caracterizacin
de procesos
Modelo
workload

Planificacin
de la capacidad

Los niveles de descripcin

de trabajo
Vista de
negocios

Vista
Tecnolgica

descriptores

Modelo
de
negocio

Caractersticas
del negocio

Modelo
funcional

Programas,
aplicaciones
y funciones

Modelo
de
recursos

Arquitectura
Del sitio
y demanda
de servicios

Mtrica
Externa

Mtrica
Interna

Modelo de
Workload

un modelo workload es una representacin que imita el

workload real bajo estudio. El modelo debe ser representativo
y compacto.
Los modelos Workload pueden ser clasificados en dos
categoras, de acuerdo con la forma en que se construy:

Modelos naturales: se construyen usando componentes bsicos del

workload como construccin de bloques o el uso de la ejecucin de
las trazas del workload real.
Modelos artificiales: no hace uso de cualquier componente bsico o
del trabajo real. Se clasifican en ejecutables y no ejecutables.

Una Metodologa de
caracterizacin de
Workload

Es necesario mencionar los pasos necesarios para construir un

modelo Workload para ser utilizado como insumo para
construir modelos analticos. Nuestro enfoque se centra en los
recursos orientados a la caracterizacin del Workload.
1.
2.
3.
4.
5.

6.

Eleccin de un punto de vista de anlisis.

Identificacin de los componentes bsicos.
Eleccin de la caracterizacin de parmetros
Coleccin de datos
Particionando el Workload

Utilizacin de recursos

Aplicaciones

Objetos

Orientacin geogrfica

Funcional

Unidades de organizacin

Modalidasdes (interactiva, transaccin, continua)

Clculo de parmetros de clase

Promedio

Clustering

Anlisis de datos
Medidas de distancia
Ampliacin de tcnicas
Algoritmos de clustering

Web Workloads
Hay un cuerpo significativo de trabajo sobre la caracterizacin
del workload del trfico web. Unas de las caractersticas
consideradas tratan con distribuciones de tamao de archivo,
distribucin de popularidad de archivo, autosemejanza en
trafico Web, lugar de referencia, y solicitud de usuarios y
patrones.
Adems del estudio de la metodologa de caracterizacin del
workload, es importante revisar algunas propiedades
encontradas en el anlisis del actual trafico Web. Es decir, la
presencia del poder ley y la naturaleza de las rfagas del
trfico.

Power-Laws
Son expresiones de la forma y*x^ donde es una constante
y x e y son las medidas de inters. Se ha demostrado que
estas power-laws pueden ser usadas para describir
propiedades de la topologa de Internet.
Otra power-law es Zipfs Law que es la relacin entre la
frecuencia de ocurrencia de un evento y su rango, cuando los
eventos se clasifican con respecto a la frecuencia de
ocurrencia.
Las distribuciones Power-Law se han observado en diversos
aspectos de la web y puede ser utilizado para caracterizar el
comportamiento de los usuarios.

Rfagas de
Workloads

Lo principal e este punto es aquella autosemejanza de trfico

de red implica burtiness (rfagas) en varias escalas de
tiempo. Y las rfagas tienen un impacto fuerte sobre el
funcionamiento de sistema conectado a una red.
Cmo podemos representar burtiness en la caracterizacin
del Workload?

Burtiness es un perodo de observacin dado puede ser

representado por un par de parmetros, (a, b). El parmetro a es
el radio entre la tarifa de peticin mxima observada y la tarifa de
peticin media durante el perodo de observacin. El parmetro "b"
es la fraccin de tiempo durante el cual la tarifa de llegada
instantnea excede la tarifa de llegada media

Benchmarck y
pruebas de
Desempeo

Introduccin

La mejor forma de medir el desempeo de

una sistema es hacerlo correr y medir el
resultado.
Benchmark consiste en hacer correr un
grupo de programas en computadoras y
redes.
Las pruebas de desempeo sirven para
medir el desempeo de los sistemas bajo
condiciones especificas.

La naturaleza de
los benchmarcks

Tiempo y velocidad son las mediciones

bsicas.
A los usuarios les interesa el tiempo de
respuesta.
A los administradores les interesa la
velocidad.
A ambos les interesa el costo.

Arquitectura de los
benchmarks

Existen 2 categoras de benchmarks:

1. Bajo nivel: Miden directamente el rendimiento de

los componentes.
2. Alto nivel: Miden el rendimiento de la combinacin
componente/controlador/SO.

Hay 4 niveles de benchmarks.

1.
2.
3.
4.

Operaciones Bsicas.
Benchmarks de juegos.
Kernels.
Programas Reales.

Arquitectura de los benchmarks

Programas reales
Kernels
Juegos de benchmarks
Operaciones Bsicas

Mediciones de Desempeo

Sistema

Arquitectura de los
benchmarks

En el 1 nivel se realizan solo operaciones

bsicas (suma y multiplicaciones).
En el 2 nivel se ejecutan programas que
realizan puzzles clsicos (torres de Hanoi).
En el 3 nivel se ejecutan fragmentos de
cdigo de programas reales.
En el 4 nivel se ejecutan programas reales.

Evitando fallas

Se deben conocer el sistema donde se estn

ejecutando las pruebas (procesador,
memorias, red, etc.).
Para evitar fallas, uno se debe hacer
preguntas como:
tiene las pruebas una configuracin similar
al sistema actual?
Qu tan representativa es la carga de
trabajo con los test de benchmarks?

Benchmarks mas
comunes

Varios test de benchmarks puedes ser usados

para evaluar una amplia variedad de sistemas.
Un test de benchmarks debe tener las
siguientes caractersticas:
Relevancia
Entendible
Escalable
Aceptable

Benchmarks mas
comunes

Existen 2 consorcios que ofrecen benchmarks

usados para comparar sistemas:
System Performance Evaluation Corporation
(SPEC)
Transaction Processing Performance Council
(TPC)

Ejemplo CINT2000

Consta de 12 programas:

164.gzip

compresin

175.Vrp

Direccionamiento y ubicacin de circuitos FPGA

176.gcc

Compilador C

181.mcf

Resolutor de costo mnimo de flujo de red

186.crafty

Programa de ajedrez

197.parser

Procesamiento de lenguaje natural

252.eon

visualizacin

253.perlbmk

Perl

254.gap

Teora de grupo computacional

10

255.vortex

Base de datos orientada a objetos

11

256.bzip2

Compresin

12

300.twolf

Simulador de ubicacin y ruteo

CFP2000

Consta de 14 programas:

168.Wupwise

Cromodinmica de cuantos

171.swim

Modelado de aguas poco profundas

172.mgrid

Resolutor de multi-grilla en campos potenciales 3D

173.applu

Ecuaciones diferenciales parciales parablicas/elpticas

177.mesa

Librera de grficos 3D

178.galgel

Dinmica de fluidos: anlisis de inestabilidad oscilatoria

179.art

Simulacin de red neuronal: teora de la resonancia

adaptativa

183.equake

Simulacin de elementos finitos: modelado de terremotos

187.facerec

Reconocimientos de imgenes: reconocimiento de rostros

10

188.ammp

Qumica computacional

11

189.lucas

Teora de los nmeros: prueba de primalidad

12

191.fma3d

Simulacin de elementos finitos en choque

13

200.sixtrack

Modelo de acelerador de partculas

14

301.apsi

Resolutor de problemas de temperatura, viento y distribucin

de contaminantes

http://www.spec.org/cpu2000/results/

Benchmark a
servidores Web

Estos Benchmark son llevado a cabo en

pequeas redes, sin perdidas de datos
Se describirn 2 benchmark Web
1. Specweb
2. Webstore

Specweb

Mide el mximo de conexiones simultaneas,

soportadas por un servidor Web.
Se usan 1 o mas clientes para generar
peticiones HTTP a un servidor.
Cada cliente valida la informacin recibida por
el servidor.
Al finalizar la prueba un cliente recolecta toda
la informacin y calcula los resultados.

Resultado prueba Specweb

http://www.spec.org/web99/results/

WebStone

Es un benchmark configurable para generar

trafico HTTP
Esta diseado para medir el mximo
desempeo y el tiempo de respuesta de la
conexin
Es un benchmark distribuido y multiproceso,
compuesto de un maestro y varios procesos
clientes.

WebStone

Los parmetros configurables son:

Numero de clientes
Tipos de archivo, tamao y frecuencia de
acceso
Numero de paginas disponibles
Numero de maquinas clientes

Benchmarck de
Sistemas
Estos benchmark miden el sistema completo
(procesador, red, I/O, etc.)
Existen 4 benchmark tpc
1.
2.
3.
4.

Tcp-c
Tcp-h
Tcp-r
Tcp-w

TCP-C

Es un standard para sistemas de procesos de

transacciones en lnea
Consiste de 5 transacciones (con update, insert y
delete):
1.
2.
3.
4.
5.

Nueva orden
Pago
43%
Entrega
Estado de la orden
Nivel de stock

45%
4%
4%
4%

TPC-C
Para el TPC-C el desempeo es el mximo
numero de nueva orden por minuto que puede
ejecutar el sistema mientras ejecuta las otras
cuatro transacciones.

TPC-C Resultados
Compaa
Sistema
Procesos
BDMS
Sistema Operativo
Monitor de transacciones
Costo total del sistema
Desempeo TPC-C
Precio / Desempeo

X
Z
4
Microsoft SQL
Windows XP
Microsoft COM+
$US 445747
34600
$US 12,89

TPC-H y TCP-R

TPC-H: Es un benchmark de soporte a la decisin.

Consta de un conjunto consultas (queries)
especficas, orientadas a la actividad comercial.
TPC-R: es similar a TPC-H pero permite
optimizaciones adicionales basadas en el
conocimiento de las consultas.
Se diferencian en las reglas de implementacin , ya
que mientras TPC-H limita el uso de ndices y
esquemas de particiones, TPC-R no limita el uso de
estas estructuras en la base de datos.

TCP-W

La carga de trabajo se configura en un

entorno de comercio que simula las
actividades de un servidor de WEB orientado a
las transacciones comerciales.
El sistema provee caractersticas como
bsqueda, detalle de productos, etc.
Cada producto tiene asociada una descripcin
y una imagen de 5KB.
Pueden existir 1000,10000,100000,1000000 o
10000000 productos

TCP-W

El sitio debe mantener una base de datos

con informacin de los clientes, productos
en el catalogo, ordenes y transacciones de
tarjeta de crdito.
Este Benchmarck clasifica las interacciones
en 2 tipos:
1. Navegacin
2. Orden

TCP-W

Especifica 3 tipos de secciones:

1. Navegacin:
5% orden
2. Compras:
orden
3. Ordenes
orden

95% navegacin
80% navegacin 20%
50% navegacin 50%

Tiene 2 mtricas de desempeo:

1. Productividad
2. Costo / productividad

TPC-W

El desempeo se mide en WIPS y es el

nmero de transacciones completadas en 1
segundo cuando la seccin es de tipo
compras
Existen 2 mtricas secundarias
1. WIPSb
2. WIPSo

La mtrica con respecto al costo se mide

$/WIPS que relaciona el costo total del
sistema con los WIPS.

TPC-W Resultados
Compaa
Sistema
Escala
Procesos
BDMS
Sistema Operativo
Servidor HTTP
Balanceador de carga
Ingeniera de Bsqueda
Costo total del sistema
Desempeo TPC-W
Precio / Desempeo

X
Z
10000
4
Microsoft Sql
Windows XP
Windows IIS
Microsoft Dns server
Microsoft Sql server FT
search
$US 211214
3130
$US 67,50

Pruebas de
Desempeo

El Principal propsito de ejecutar pruebas de

desempeo es entender el desempeo bajo
cargas especificas de trabajo
Las pruebas de desempeo pueden ser usadas
en cualquier punto de la implementacin del
sistema.
Las pruebas deben ser planeadas con tiempo,
para no perder tiempo si se descubren fallas
cuando es implementada.

Tipos de Pruebas de
desempeo

Existen 3 tipos de pruebas caracterizadas

por la intensidad de la carga generada
1. Prueba de carga
2. Prueba de Stress
3. Pruebas de Punta

Metodologa para la prueba de

desarrollo
Definir los objetivos de la prueba

Entender el ambiente

Especificar el plan

Definir la carga de trabajo

Configurar el ambiente

Ejecutar la prueba

Analizar los resultados

Modelos de
desempeo a nivel de
sistemas

Introduccin

Es desarrollado en distintos niveles.

Es modelado como una caja negra.
Los detalles internos no son modelados explcitamente.
Solo se considera la funcin de throughput.

Modelo simple servidor cola

infinita
Se considera un servidor Web accesible por una gran
cantidad de personas. (Poblacin)
Empresas con varios servidores.
Para mayor simplicidad carga balanceada.
Tasa de llegada de peticiones/sec.
No se rechaza ninguna peticin.
Flow in = Flow out.

Modelo simple servidor cola

infinita

Modelo simple de servidor

Cola Finita
Existen W peticiones rechazadas.

Modelo simple de servidor

Cola Finita

Otros modelos a nivel de

sistemas

Haciendo una generalizacin de los

modelos anteriores, aparecen nuevas
alternativas, considerando 3 nuevas
dimensiones:
Tamao de la poblacin
Ritmo de servicio
Tamao mximo de la cola

Modelo de
poblacin infinita

Son representados por ambientes WWW.

N de usuarios potencialmente largo.

Ritmo de servicio variable

con tamao de cola infinita.

Ritmo de servicio variable y

cola con tamao limitado
Peticiones rechazadas
Cuidados especiales en su implementacin.
Fcil de producir overflows o underflows.

Modelo de
poblacin finita

Z = tiempo de pensamiento.
La tasa promedio de peticiones generadas en el
sistema es representada por 1 / Z Pet/sec.

Ritmo fijo de servicio y cola

ilimitada.
Se considera que la velocidad de servicio del
servidor es fija.
M peticiones.
Por lo general se utiliza para solucionar problemas
matemticos con grandes valores.
Ej. 200!

Modelo de rendimiento a
nivel de componentes ,
REPASO APLICADO

Introduccin

Aqu se caracterizan por su funcin de

throughput X(n), donde n representa la carga del
sistema en trminos del nmero de peticiones del
sistema, y se denominan Qn.

Red de gestin de
colas
Peticin espera en la cola el uso de un recurso.
S(n) tiempo promedio de servicio por peticin.

Red de gestin de colas clase

simple
Ri = tiempo promedio de respuesta
i = cola
Si = tiempo promedio de servicio.
El tiempo de respuesta promedio en una cola es
igual al tiempo de servicio promedio ms el tiempo
de espera promedio de la solicitud.
El mximo valor de es limitada por el recurso con el
valor ms alto de demanda de servicio. (Cuello de
botella de recurso).

Red de gestin de colas

clase mltiple
Es una generalizacin del modelo anterior.
Trabaja con vectores.

Modelos cerrados
Existe un nmero limitado de peticiones en el
sistema.
Mtodo para resolverlos es a travs de MVA
(mean value analisis).

Modelo cerrado de
clase simple
MVA esta basado sobre recursividad usando 3
ecuaciones:
La ecuacin de tiempo de residencia
La ecuacin de rendimiento
La ecuacin de largo de cola.

Modelo cerrado
clase mltiple.

Similar al anterior
Existe un nmero fijo de peticiones, Nr, por cada
clase en el sistema.
Es representado por un vector intensidad de carga.

Modelamiento
Intranet

Modelamiento
Intranet

Es necesario modelar la red de gestin de colas de la intranet.

Para esto es necesario realizar los siguientes pasos.
1 - Decidir la meta del rendimiento del modelado.
2 - Decidir qu tipo de modelo, lo que es, abierto o cerrado, se van
a utilizar.
3 - Determinar el nmero de clases del modelo y lo que
representan.
4 - Decidir cmo los componentes del sistema sern asignadas en
las colas y decidir sobre el tipo de colas se utilizan para
representar cada componente.
5 - Calcular el servicio de las demandas de cada cola y cada clase.
6 - Determinar el nmero de solicitudes por clase de modelos
cerrados y la tasa media de solicitudes de modelos abiertos.

Modelos de desempeo
Web
Caso especial de modelamiento:

Adicin de nuevas caractersticas.

Traffic burstiness.
Heavy-tails.

Modelos del lado del cliente.

Modelos sin cache-proxy.

Modelos con cache-proxy.

Modelos del lado del servidor.

Servidor nico
Servidores redundantes.

Modelos de desempeo
Web

Los servicios Web son un tipo especial de sistema

distribuido y para plantear un modelo de desempeo
valido, se debe modificar para dar cabida a los nuevos
factores.

Traffic burstiness
Se entiende burst como un flujo masivo de peticiones.

Este torrente masivo de peticiones va generando una

congestin acumulativa en los recursos del sistema.

Considerar este parmetro, hace imperiosa la necesidad

de modificar la demanda del servicio, el componente
cuello de botella utilizando un factor de burstiness.

Traffic burstiness
Calculo del factor de burstiness:
Utilizando un registro de peticiones HTTP con las
peticiones en un tiempo T, se calcula el promedio de
peticiones .
El tiempo T es dividido en n intervalos iguales y cada
intervalo es llamado epoch (poca).
Luego se contabiliza el nmero de peticiones de epoca
por sobre y bajo el promedio .
Finalmente, se divide el nmero de epocas que exceden
el promedio dividido por el nmero de epocas en total n.

Traffic bursting

El throughput total del sistema disminuye si el factor de

burstiness aumenta.
No toda la demanda de servicio esta sujeto al efecto del
factor de burstiness.

Heavy-tails
La necesidad de este modelo radica en que se espera que
en un servicio Web exista un gran porcentaje de
peticiones HTTP para documentos de pequeo tamao y
un menor porcentaje para documentos de gran tamao,
volvindose estadsticamente poco significativo.

El modelo de heavy-tails lo soluciona utilizando un

modelo de red de colas multiclases asociadas al tamao
del documento. El ritmo de peticiones se evalua por grupo
de documentos.

Modelos del lado del

Cliente

Estos modelos se construyen con el objetivo de responder

preguntas tales como la ancho de banda que se necesita
para utilizar el servicio correctamente o si es mejor utilizar
un cache-proxy.

Modelos del lado del

Cliente

Diagrama de red de cliente normal y con un proxy-cache

como intermediario.

Modelos del lado del

Cliente

Variantes del sistema de colas Qn normal y con cacheproxy como intermediario.

Modelos del lado del

servidor
Estos modelos se construyen con el objetivo de responder
preguntas tales como cual debe ser el ancho de banda de
conexin a Internet para que el servicio Web sea de una
calidad aceptable, la compaa debera instalar servidores
redundantes, si es as cuantos de ellos, si es recomendable
un cluster con muchos servidores de bajo rendimiento o si
es recomendable unos pocos servidores de alto
rendimiento, etc.

Modelos del lado del

servidor

Diagrama de modelos del lado del cliente

(a) servidor nico (b) servidores espejo.

Modelos del lado del

servidor

Modelo de colas Qn en
(a) servidor nico (b) servidores espejo.

Modelo de servidor
nico
El modelo de colas cerrado Qn usado para un servidor
nico se puede describir como:
Cola 1 y 6: representa los links de entrada y salida del
router a la conexin del ISP (se asume que la conexin es
full duplex).
Delay 2: representa el router por su pequea latencia
comparada con los otros elementos.
Cola 3: representa la LAN y es independiente de la carga.
Cola 4: representa la CPU del servidor.
Cola 5: representa el disco del servidor.

Modelo de servidor con

mirrors
El modelo de servidor con mirrors se diferencia del
servidor nico principalmente en que la demanda de
servicio de la CPU y discos se divide en n (asumiendo que
se balancea la carga equitativamente).
El tiempo promedio de servicio no cambia por el numero
de servidores Web.