Traducido del inglés al español - www.onlinedoctranslator.

com

Vea discusiones, estadísticas y perfiles de autor para esta publicación en:https://www.researchgate.net/publication/221307754

Análisis de rendimiento automatizado de pruebas de carga

Documento de sesión· Septiembre 2009

DOI: 10.1109/ICSM.2009.5306331 · Fuente: DBLP

CITAS LEE
96 1,382

4 autores, incluido:

Ahmed E Hassan gilberto hamann

universidad de la reina Mora
467PUBLICACIONES19,918CITAS 14PUBLICACIONES 440CITAS

VER EL PERFIL VER EL PERFIL

Algunos de los autores de esta publicación también están trabajando en estos proyectos relacionados:

Recompensas en sitios de preguntas y respuestas técnicas: un estudio de caso de recompensas por desbordamiento de pilaVer Proyecto

Ecosistemas de softwareVer Proyecto

Todo el contenido que sigue a esta página fue subido porAhmed E Hassanel 10 de abril de 2014.

El usuario ha solicitado la mejora del archivo descargado.

 Análisis de rendimiento automatizado de pruebas de carga
Zhen Ming Jiang, Ahmed E. Hassan Laboratorio
de inteligencia y análisis de software (SAIL)
universidad de la reina
Kingston, ON, Canadá
{zmjiang, ahmed}@cs.queensu.ca
Abstracto
El objetivo de una prueba de carga es descubrir problemas
funcionales y de rendimiento de un sistema bajo carga. Los problemas
de rendimiento se refieren a las situaciones en las que un sistema sufre
un tiempo de respuesta inesperadamente alto o un bajo rendimiento.
Es difícil detectar problemas de rendimiento en una prueba de carga
debido a la ausencia de objetivos de rendimiento definidos
formalmente y la gran cantidad de datos que deben examinarse.
En este documento, presentamos un enfoque que analiza
automáticamente los registros de ejecución de una prueba de carga para
detectar problemas de rendimiento. Primero derivamos la línea base de
rendimiento del sistema a partir de ejecuciones anteriores. Luego realizamos
una comparación de rendimiento en profundidad con la referencia de
rendimiento derivada. Los estudios de casos muestran que nuestro enfoque
produce pocas falsas alarmas (con una precisión de77%) y se adapta bien a
grandes sistemas industriales.
1. Introducción
Muchos sistemas, desde sitios web de comercio electrónico hasta
infraestructuras de telecomunicaciones, deben admitir el acceso simultáneo
de cientos o miles de usuarios. Muchos de los problemas de campo están
relacionados con sistemas que no se adaptan a las cargas de trabajo de
campo en lugar de errores de funciones [9, 34]. Para garantizar la calidad de
estos sistemas, la prueba de carga es un procedimiento de prueba
obligatorio además de los procedimientos de prueba funcionales
convencionales, como las pruebas unitarias y de integración.
Las pruebas de carga, en general, se refieren a la práctica de evaluar el
comportamiento de un sistema bajocarga[18]. Una carga generalmente se
basa en un perfil operativo, que describe la carga de trabajo esperada del
sistema una vez que esté operativo en el campo [13, 15]. Una carga consta de
los tipos de escenarios ejecutados y la tasa de estos escenarios. Por ejemplo,
la carga de un sitio web de comercio electrónico contendría información
como: navegación (40 %) con una tasa mínima/promedio/máxima de 5/10/20
solicitudes/seg, y compras (40 %) con una tasa mínima/promedio/máxima de
5/10/20 solicitudes/seg. tasa promedio/máxima de 2/3/5 solicitudes/seg.
Una prueba de carga suele durar varias horas o incluso algunos
días. La prueba de carga requiere uno o más generadores de carga.
Gilbert Hamann y Parminder Flora
Investigación de ingeniería de
rendimiento en movimiento (RIM)
Waterloo, ON, Canadá
tores que imitan a los clientes que envían miles o millones de solicitudes
simultáneas a la aplicación bajo prueba. Durante el transcurso de una prueba
de carga, se supervisa la aplicación y se registran los datos de rendimiento
junto con los registros de ejecución. Los datos de rendimiento almacenan
información sobre el uso de los recursos, como la utilización de la CPU, la
memoria, la E/S del disco y el tráfico de la red. Los registros de ejecución
almacenan el comportamiento en tiempo de ejecución de la aplicación bajo
prueba.
El objetivo de una prueba de carga es descubrir problemas
funcionales y de rendimiento bajo carga. Los problemas funcionales a
menudo son errores que no surgen durante el proceso de prueba
funcional. Interbloqueos y errores de administración de memoria son
ejemplos de problemas funcionales bajo carga. Los problemas de
rendimiento a menudo se refieren a problemas de rendimiento como
un tiempo de respuesta alto o un rendimiento bajo bajo carga.
La investigación existente sobre pruebas de carga se centra en la
generación automática de conjuntos de pruebas de carga [13, 14, 15, 17, 20,
25, 35]. Existe un trabajo limitado, que propone el análisis sistemático de los
resultados de una prueba de carga para descubrir problemas potenciales.
Desafortunadamente, buscar problemas en una prueba de carga es una
tarea difícil y que requiere mucho tiempo. Nuestro trabajo anterior [28]
señala posibles problemas funcionales al extraer los registros de ejecución de
una prueba de carga para descubrir patrones de ejecución dominantes y
marcar automáticamente las desviaciones funcionales de este patrón dentro
de una prueba.
En este documento, presentamos un enfoque que marca
automáticamente posibles problemas de rendimiento en una prueba de
carga. No podemos derivar el comportamiento de rendimiento dominante de
una sola prueba de carga como hicimos en nuestro trabajo anterior, ya que la
carga no es constante. Una carga de trabajo típica suele constar de períodos
que simulan un uso máximo y períodos que simulan un uso fuera del horario
laboral. Por lo general, se aplica la misma carga de trabajo en las pruebas de
carga, de modo que los resultados de las pruebas de carga anteriores se
usan como referencia informal y se comparan con la ejecución actual. Si la
ejecución actual tiene escenarios que siguen una distribución de tiempo de
respuesta diferente a la de la línea de base, esta ejecución probablemente
sea problemática y valga la pena investigarla. Las principales contribuciones
de nuestro trabajo son las siguientes:
1. Hasta donde sabemos, nuestro enfoque es el primero
 trabajar para detectar automáticamente problemas de rendimiento en los
resultados de las pruebas de carga.
2. Nuestro enfoque hace uso de registros de ejecución fácilmente
disponibles, lo que evita la necesidad de instrumentación que
afecte el rendimiento [16, 22] .
3. Nuestro enfoque informa automáticamente escenarios con problemas
de rendimiento y señala los cuellos de botella de rendimiento dentro
de estos escenarios. Los estudios de casos muestran que nuestro
enfoque se adapta bien a sistemas grandes y produce pocas falsas
alarmas (con una precisión de77%).
Organización del Papel
El documento está organizado de la siguiente manera: la Sección 2
describe la práctica actual del análisis del desempeño y sus limitaciones. La
sección 3 muestra un ejemplo de cómo un probador de carga puede usar
nuestro informe de análisis de rendimiento para analizar el rendimiento de
una prueba de carga. La Sección 4 describe nuestro enfoque de análisis de
desempeño. La Sección 5 presenta tres casos de estudio sobre nuestro
enfoque de análisis de rendimiento: dos sobre aplicaciones de código abierto
y uno sobre una aplicación empresarial grande. La Sección 6 presenta
algunas discusiones y trabajos futuros. La Sección 7 describe el trabajo
relacionado. La sección 8 concluye el documento.
2 Práctica actual de análisis de desempeño
La mayoría de las aplicaciones empresariales grandes deben someterse a
pruebas de carga para garantizar un rendimiento satisfactorio bajo carga.
Desafortunadamente, buscar problemas de rendimiento en una prueba de carga es
una tarea difícil y que requiere mucho tiempo debido a muchos de los siguientes
desafíos:
Falta de referencias de rendimiento documentadas:Los requisitos
del sistema correctos y actualizados rara vez existen [32].
La presión del tiempo:La prueba de carga suele ser el último paso en un
programa de lanzamiento ya retrasado que los gerentes deben acelerar. Por
lo tanto, el tiempo asignado para realizar una prueba, que podría ser de días,
y analizar los resultados suele ser limitado.
Supervisión de gastos generales:Los enfoques que monitorean o
perfilan una aplicación afectan la validez de las mediciones de
rendimiento y no son prácticos para las pruebas de carga.
Gran volumen de datos:Una prueba de carga, que se ejecuta durante
algunas horas, genera datos de rendimiento y registros de varios
cientos de megabytes de tamaño. Estos datos deben analizarse para
descubrir cualquier problema en la prueba de carga.
Debido a los desafíos anteriores, un probador de carga a menudo utiliza los
resultados de una prueba de carga anterior como referencia informal y realiza
comprobaciones de rendimiento de alto nivel. Los siguientes dos
Los cheques se utilizan comúnmente en la práctica:
Comprobación de métricas:Un probador de carga examina las métricas de
rendimiento en busca de grandes fluctuaciones. Por ejemplo, una tendencia al alza
en el uso de la memoria durante una prueba de carga es un buen indicador de una
fuga de memoria.
Comprobación del tiempo de respuesta:Usando el conocimiento del dominio,
un probador de carga verifica el tiempo de respuesta de algunos escenarios
clave y los compara con una línea de base informal.
Creemos que esta práctica actual no es eficiente ya que
requiere horas de análisis manual, ni es suficiente ya que podría
pasar por alto problemas que aparecen en otros escenarios.
3 Informe de análisis de rendimiento
La sección anterior discutió los desafíos y limitaciones de las
prácticas actuales de análisis de desempeño. En respuesta, hemos
desarrollado un informe generado automáticamente, que puede
descubrir posibles problemas de rendimiento. El informe extrae
información de los registros de ejecución fácilmente disponibles y
utiliza una ejecución anterior como referencia de rendimiento
informal para comparar.
Considere el siguiente ejemplo. A Jack, un probador de carga, se le pide
que pruebe la carga de una nueva versión de una aplicación en línea.
Necesita determinar si la aplicación puede escalar a cientos de solicitudes de
clientes simultáneas, tal como lo hizo la versión anterior. La aplicación es una
tienda de mascotas en línea que admite operaciones como iniciar/cerrar
sesión, navegar, comprar y registrarse para nuevos usuarios. Ahora
demostramos cómo Jack puede usar nuestro informe de análisis de
rendimiento para descubrir problemas de rendimiento en función de la
ejecución que realizó en una versión anterior.
Resumen de rendimiento general
Dado que la instrumentación adicional o la creación de perfiles de la
aplicación pueden ralentizarla y afectar la medición del rendimiento,
Jack tiene que trabajar con registros de ejecución y métricas de
rendimiento fácilmente disponibles.
Como se muestra en la Figura 1(a), de millones de líneas de registro
en los registros de ejecución, nuestro informe marca 3 escenarios cuyo
rendimiento es estadísticamente diferente al de la ejecución anterior.
Cada fila de la tabla corresponde a un escenario de desempeño
desviado. Entre estos tres escenarios, hay dos escenarios que son
peores que la ejecución anterior (mostrado en rojo) y un escenario que
es mejor (mostrado en azul). Los escenarios se ordenan por el grado de
desviación del rendimiento con respecto a la ejecución anterior para
que Jack pueda aprovechar al máximo su tiempo trabajando desde
arriba.
Mirando la primera fila, Jack descubre que el primer escenario tiene
aproximadamente el mismo rendimiento (5,000versus5,002 solicitudes
por segundo) de ambas ejecuciones. Sin embargo, se da cuenta de que
el rendimiento del escenario actual es peor que el de la ejecución
anterior, indicado por el color rojo debajo del valor de desviación 0,8.
También se muestra la secuencia de eventos desencadenada por este
escenario. Cada evento se abrevia utilizando su ID de evento abstracto (
mi 1 ,mi2,mi 3,ymi4).
Comparación de rendimiento visual
Después de obtener una impresión general sobre el rendimiento del
sistema, Jack hace clic en el hipervínculo debajo del valor de desviación
para profundizar en el rendimiento del primer escenario. Como se
muestra en la Figura 1(b), el informe se expande y muestra una
comparación visual del desempeño de este escenario.
 Rendimiento Desviación Secuencias de eventos

Evento
E1→E2→E3→E4
Rendimiento Desviación Desviación promedio
Secuencias Secuencias de eventos

5,000 E1→E2→ E1:sessionId = 2, tiempo = 1, usuario = Tom, inicie sesión correctamente

0.8
5,002 E3→E4 5,000 1.0 E2:sessionId=2, time=1, user=Tom, navegar por el catálogo,
0.8 0.1
4500 E1→E3→ 5,002 1.1 catálogo = pájaro
0.5 0.5
4,498 E5→E7 0.9
E3:ID de sesión = 2, tiempo = 2, usuario = Tom, agregar elemento,

E1→E3→ 1.8 item=loro, cantidad=1

4,000 0.5
0.3 E5→E7→ 0.1
E4:sessionId = 2, tiempo = 3, usuario = Tom, pago de usuario
4,010 0.5 exitosamente
E2 →E4
4500
(a) Resumen de desempeño general 0.5 E1→E3→E5→E7
4,498
4,000
0.3 E1→E3→E5→E7→E2 →E4
4,010
(c) Diagnóstico de desempeño paso a paso
Rendimiento Desviación Secuencias de eventos

0.8

5,000 E1→E2→
5,002 E3→E4

4500
0.5 E1→E3→E5→E7
4,498
4,000 E1→E3→E5→
0.3
4,010 E7 → E2 → E4
(b) Comparación de rendimiento visual

Figura 1. Ejemplo de informe de análisis de rendimiento

entre las dos carreras. Examina los dos gráficos buscando
responder a las siguientes dos preguntas:
1. ¿Cómo difiere el rendimiento del escenario?
El gráfico superior de la Figura 1(b) es un diagrama de frijol [29], que
visualiza las distribuciones de tiempo de respuesta del mismo escenario
en las ejecuciones anterior y actual, una al lado de la otra. El lado
izquierdo muestra la distribución del tiempo de respuesta de la
ejecución anterior y el lado derecho muestra la ejecución actual. El
ancho de la gráfica indica la frecuencia. Por ejemplo, la mayoría de las
instancias en la ejecución actual toman aproximadamente1segundo y
alrededor 0.5segundo en la carrera anterior.
Después de examinar el diagrama de frijoles, Jack ahora tiene una
mejor idea de por qué se marca este escenario: Primero, la mayoría de
los casos de la ejecución actual son más lentos que la ejecución
anterior. (1segundo contra0.5segundo). En segundo lugar, el tiempo
máximo de respuesta de la ejecución actual es5segundos en
comparación con4segundos de la ejecución anterior.
2. ¿Cómo evoluciona el rendimiento con el tiempo?
El gráfico inferior de la Figura 1(b) muestra si el rendimiento del
más de una instancia de este escenario se activa en el mismo
momento, se utiliza el tiempo de respuesta promedio de estas
instancias.
Para el primer escenario, no hay degradación del rendimiento
aunque el tiempo de respuesta fluctúe con el tiempo. La mayor parte
del tiempo, la ejecución actual (en rojo) está por encima de la ejecución
anterior (en negro), lo que nuevamente indica que la ejecución actual es
peor (es decir, más lenta).
Diagnóstico de rendimiento paso a paso
Una vez que Jack obtiene una comparación visual de las diferencias
de rendimiento para el primer escenario, Jack hace clic en el enlace
debajo de las secuencias de eventos para averiguar la causa exacta de
las desviaciones de rendimiento (Figura 1(c)). Las líneas de registro de
muestra de los registros de ejecución se muestran junto con las
duraciones promedio entre los pasos adyacentes. Además, también se
muestran las desviaciones de los pares de eventos adyacentes entre las
ejecuciones anterior y actual.
Para el escenario investigado, Jack concluye que la degradación
del rendimiento del escenario se debe principalmente a una
ralentización entre la navegación (mi )y compras (mi3)
2

sistema se ha degradado durante el transcurso de la prueba de eventos. La duración promedio de este par de eventos salta de 0,5
carga. El eje horizontal indica la hora de inicio de una instancia de segundos en la ejecución anterior a 1,8 segundos en la ejecución
escenario. El eje vertical indica el tiempo de respuesta de las actual. La desviación entre estos dos eventos, marcada (en rojo), es
instancias del escenario desencadenadas en ese momento. si mas la desviación más alta (0.9)entre todas las parejas de eventos
en este escenario. Luego, Jack hace clic en el hipervínculo debajo de la
desviación de 0,9 para obtener una comparación visual de las
2 en elmi→mi
diferencias de rendimiento 3 par. El informe se expande
nuevamente para mostrar gráficos similares a los de la Figura 1(b), pero
para pares de eventos específicos.
Informes
Según el análisis del primer escenario, Jack concluye que existe
un problema de rendimiento entre los eventos de navegación y
compra. Luego realiza un análisis similar en los otros dos
escenarios. Jack ahora puede redactar un correo electrónico, que
explica los problemas de rendimiento. El correo electrónico se
envía a los desarrolladores correspondientes con el informe de
análisis de rendimiento adjunto.
4. Nuestro enfoque para crear el informe de análisis
de rendimiento
Ahora presentamos nuestro enfoque para generar el informe de
análisis de rendimiento discutido en la Sección 3. Como se muestra en
la Figura 2, nuestro enfoque consta de cinco fases. Para ambas pruebas,
realizamos abstracción de registros, recuperación de rendimiento de
secuencias y resumen de rendimiento. Luego marcamos los escenarios
de desviación del rendimiento analizando estadísticamente los datos de
rendimiento recuperados. Finalmente, se genera un informe de análisis
de desempeño, clasificado por el grado de desviación del desempeño.
Explicamos nuestro enfoque utilizando el ejemplo de ejecución que se
muestra en la Tabla 1.
Fase 1. Abstracción de registros
Dado que la instrumentación adicional o la creación de perfiles del
sistema ralentizan su ejecución, estas técnicas no son viables para el
análisis de pruebas de carga. Como resultado, nuestro enfoque analiza
los registros de ejecución fácilmente disponibles. Estos registros suelen
estar disponibles para habilitar el soporte remoto o para hacer frente a
actos legales como la "Ley Sarbanes-Oxley de 2002" [5]. Dichos registros
registran actividades de software (p. ej., "Autenticación de usuario
exitosa") y errores (p. ej., "No se pudo recuperar el perfil del cliente").
La Tabla 1(a) muestra la primera8líneas de registro de un archivo de
registro de ejecución. Estos registros son difíciles de analizar y analizar
automáticamente, ya que están en forma libre sin un formato estricto y
utilizan un amplio vocabulario de palabras. Los registros contienen una gran
cantidad de redundancia. Por ejemplo, aunque la primera y la segunda línea
de registro se desencadenan por el mismo evento en el código, son
diferentes pero tienen una estructura similar entre sí. Nuestro objetivo es
eliminar la redundancia en los registros abstrayendo las líneas de registro en
eventos de ejecución. Hemos desarrollado una técnica [27] que explota la
estructura común entre las líneas de registro: cada línea de registro es una
mezcla de información estática y dinámica. La información estática describe
el evento de ejecución (es decir, el contexto), mientras que las partes
variables (es decir, dinámicas) son valores de parámetros generados en
tiempo de ejecución.
La información dinámica, específica de la ocurrencia particular de un
evento, hace que el mismo evento de ejecución resulte en diferentes
líneas de registro.
Las líneas de registro en la Tabla 1(a) se resumen en6eventos de
ejecución que se muestran en la Tabla 1(b). El signo “$v” indica un valor
dinámico.
Fase 2. Recuperación del rendimiento de la secuencia
A medida que el sistema maneja solicitudes de clientes simultáneas, las
líneas de registro de diferentes escenarios se entremezclan entre sí en los
registros de ejecución. Como se muestra en la Tabla 1(a), los escenarios
relacionados con los usuarios Tom, John y Mike se mezclan. Además, algunas
líneas de registro (p. ej., la octava línea de registro), que solo emiten la
información de estado del sistema, no están relacionadas con ningún
escenario de cliente. Estas líneas de registro deben filtrarse de nuestro
análisis de rendimiento.
Para recuperar el rendimiento de todos los escenarios de clientes,
primero debemos recuperar las secuencias de eventos. Recuperamos
las secuencias vinculando los valores de los parámetros apropiados.
La primera fase abstrae cada línea de registro en un evento de
ejecución. Aquí, usamos los valores dinámicos ($v) así como sus
nombres de parámetros en el evento de ejecución. Los pares de
nombre-valor de parámetro se utilizan para vincular las líneas de
registro relacionadas en secuencias. Por ejemplo, la primera línea
contiene3pares de nombre-valor de parámetro: sessionId con valor1,
tiempo con valor1,y usuario con valorJohn.
La Tabla 1(c) muestra los resultados después de extraer y vincular la
información de las líneas de registro utilizando los valores de ID de sesión de
las líneas de registro en la Tabla 1(a). Por ejemplo, el segundo (mi1), tercero (
mi ),cuatro (mi3),y sexto (mi
2 4 )todas las líneas de registro comparten
el mismo ID de sesión (2),así que los agrupamos. La octava línea de
registro en la Tabla 1(a) corresponde a un evento de verificación de
estado periódico, que no tiene ID de sesión y se usa para determinar si
el sistema está activo. Esta línea de registro se filtra.
El rendimiento de la secuencia recuperada se calcula tomando
la diferencia de tiempo entre el primero y el último evento. En
nuestro ejemplo de ejecución, el tiempo de respuesta general de la
secuencia (mi→mi→mi→mi
1 2)conID de
3 sesión
4 =2 es2segundos. Dado
que solo hay una línea de registro con sessionId
3,no hay información de duración para esta sesión. También se calculan
las duraciones entre cada par de eventos adyacentes. La
información de duración por pares se usa más tarde para el diagnóstico
de rendimiento por pasos. El tiempo de duración entre los dos primeros
eventos (mide la segunda línea de registro ymi de la tercera línea de
1 2
registro) es0segundos, y así sucesivamente.
Fase 3. Resumen del desempeño
La fase anterior ha recuperado la actuación de las secuencias
individuales. Secuencias de eventos idénticas corresponden al
mismo escenario. Como una prueba de carga ejecuta
repetidamente escenarios una y otra vez, la secuencia1mi→mi→2
mi→mi
3 4 puede aparecer varias veces. En la tercera fase, nos
resumir el rendimiento de cada escenario.
 Secuencia
pasado Ejecución
Actuación
Registro
Correr
Registros
Abstracción resumen
Recuperación
Secuencia
Actual Ejecución
Actuación
Registro
Correr Registros
Abstracción resumen
Recuperación
Figura 2. Nuestro enfoque para generar el informe de análisis de rendimiento
Las tablas 1(a), 1(b) y 1(c) solo procesan las primeras 8 líneas de
registro de los registros. Los registros de ejecución suelen
contener millones de líneas. La Tabla 1(d) muestra un ejemplo del
rendimiento del escenario resumido utilizando los registros de
ejecución completos. En total, tenemos2escenarios. El primer
escenario (mi1→mi2→mi3→mi4)ocurre 300 veces. Entre ellos, 100
veces ocurre con una duración de 2 segundos y 200 veces con 3
segundos. También se resume el rendimiento de los pares de
eventos adyacentes de cada escenario. Por ejemplo, el par de
eventosmi→mi2desde el3 primer escenario tarda en promedio 1,7
segundos. Entre las 300 ocurrencias totales de este par de eventos
en este escenario, toma 1 segundo en 100 veces y 2 segundos en
las otras 200 veces.
Fase 4. Análisis Estadístico
La frase 3 descubre el rendimiento de todos los escenarios de
las ejecuciones anteriores y actuales. La cuarta fase evalúa el
rendimiento general de cada escenario y señala los pares de
eventos que se desvían del rendimiento.
Comparamos el rendimiento de cada escenario en las ejecuciones
anteriores y actuales mediante una prueba estadística. Usamos la
prueba t de Student no apareada para comparar las distribuciones de
tiempo de respuesta del escenario de la ejecución anterior con la
ejecución actual. Además, utilizamos una prueba t de Student
modificada [26], que genera un intervalo de confianza. En comparación
con la prueba de hipótesis, cuyo resultado solo responde si las dos
distribuciones son estadísticamente iguales, un intervalo de confianza
también proporciona rangos posibles. Dependiendo de la posición
relativa del intervalo de confianza a cero, podemos saber qué ejecución
tiene mejor rendimiento (es decir, sincronización) para este escenario.
Solo mostramos los escenarios, cuyo rendimiento es estadísticamente
diferente entre las dos ejecuciones, en nuestro informe.
Una vez que se marcan los escenarios con rendimiento
desviado, debemos identificar los pares de eventos que causan
las desviaciones de rendimiento. Logramos esto aplicando la
misma prueba estadística en todos los pares de eventos
adyacentes. Por ejemplo, para el escenario
1 marcado
2 (3mi→mi→
4
mi→mi), comparamos el rendimiento1demi→mi 2 ,mi→mi
2 ,y 3
mi→mi
3 4 entre la ejecución anterior y la actual.
Fase 5. Generación de informes
Como el probador de carga tiene un tiempo limitado, clasificamos los
escenarios potencialmente problemáticos para ayudarlo a priorizar su tiempo.
Actuación
Actuación
Estadístico Informe Análisis
Análisis Generación
Actuación
Informe
Clasificamos cada escenario según el grado de desviación del
rendimiento entre las ejecuciones anterior y actual.
La distancia del coseno, que mide el grado de similitud
entre dos distribuciones, arroja un valor entre 0 y 1. Si las dos
distribuciones son muy similares, la distancia del coseno es
cercana a 1. Si son muy diferentes, la distancia del coseno es
cercana a 0 Como la desviación es lo opuesto a la similitud,
usamos la siguiente fórmula para calcular la desviación:
desviación(pag, c) = 1−coseno(pag, c) (1)
∑
XPAG(X)C(X)
coseno(pag, c) =√∑ √∑ (2)
XPAG(X)2 XC(X)2
Tenga en cuenta que P(x) y C(x) corresponden al número de
instancias en las ejecuciones anterior y actual que tienen un tiempo
de respuesta x para un escenario particular. Por ejemplo, si la
distancia del coseno del primer escenario en la Tabla 1(d) es0.2,su
valor de desviación es0.8.
5. Estudios de casos
Realizamos3estudios de casos sobre3diferentes sistemas (2
aplicaciones de código abierto y1aplicación de gran empresa).
Buscamos verificar si nuestro informe de análisis de rendimiento puede
ayudar a los probadores de carga en sus tareas habituales. Como
nuestro enfoque solo señala los escenarios de rendimiento desviado,
depende de su conocimiento decidir si el rendimiento desviado conduce
a problemas de rendimiento.
Utilizamos la precisión para evaluar el rendimiento de nuestro
enfoque. La precisión se define de la siguiente manera:
# de escenarios de falsa alarma
precisión(%) = (1− ) ×100%
T otal#de escenarios marcados
Múltiples escenarios con rendimiento desviado pueden ser
causados por el mismo problema de rendimiento, lo que puede
ser una indicación del impacto de este problema. Si un escenario
marcado no genera un problema de rendimiento, este escenario se
considera una falsa alarma.
Un probador de carga realiza y analiza una prueba de carga de un
sistema en evolución que busca realizar muchas de las siguientes
tareas: recomendar configuraciones óptimas del sistema, certificar
 # Líneas de registro

1. sessionId=1, time=1, user=John, iniciar sesión correctamente sessionId=2, time=1, user=Tom, Identificador de evento Plantilla de evento #
2. iniciar sesión correctamente sessionId=2, time=1, user=Tom, navegar por el catálogo, E1 sessionId=$v, time=$v, usuario=$v, inicio de sesión correctamente sessionId=$v, 1, 2
3. catalog=bird sessionId=2, tiempo=2, usuario=Tom, añadir artículo, artículo=loro, cantidad=1 E2 time=$v, user=$v, examinar catálogo, catalog=$v sessionId=$v, time=$v, usuario =$v, 3, 5
4. ID de sesión=1, tiempo=3, usuario=Juan, examinar catálogo, catálogo=perro ID de sesión=2, E3 agregar artículo, artículo=$v, cantidad=$v sessionId=$v, tiempo=$v, usuario=$v, pago del 4
5. tiempo=3, usuario=Tom, pago de usuario con éxito sessionId=3, tiempo=4, usuario=Mike, E4 usuario con éxito sessionId=$v, tiempo=$v, usuario=$v, usuario elemento de búsqueda, 6
6. elemento de búsqueda de usuario, elemento=tiempo de serpiente de cascabel=4, E5 elemento = $ v tiempo = $ v, verificación de estado 7
7. verificación de estado E6 8
8. (b) Eventos de ejecución abstraídos y líneas de registro correspondientes

(a) Ejemplos de líneas de registro de ejecución

Secuencias de eventos Duraciones
E1→E2→E3→E4 2 (100), 3 (200)
ID de sesión Secuencias de eventos Duraciones - E1→E2 (0) 0 (300)
1 E1→E2 2 - E2→E3 (1.7) 1 (100), 2 (200)
-
E1→E2 2 - E3→E4 (1) 0 (100), 1 (100), 2 (100)
2 E1→E2→E3→E4 2 E1→E3→E5→E7→E4 3 (200)
- E1→E2 0 - E1→E3 (0.5) 0 (100), 1 (100)
- E2→E3 1 - E3→E5 (1) 1 (200)
- E3→E4 1 - E5→E7 (1) 1 (200)
3 E5 - E7→E9 (0.5) 0 (100), 1 (100)
(c) Secuencias recuperadas con duraciones calculadas (d) Tiempo de respuesta resumido para cada escenario

Tabla 1. El ejemplo de ejecución

plataformas de software/hardware, y para estudiar el impacto de los cambios
de diseño. Usamos esto para estructurar nuestro estudio de caso. Para cada
estudio, primero damos una breve descripción del sistema estudiado y una
descripción general de la tarea que debe completar el probador de carga.
Luego explicamos los pasos para realizar los experimentos y el
procedimiento de recolección de datos. Finalmente, presentamos nuestros
resultados y conclusiones.
Nuestro prototipo de análisis de rendimiento está escrito en
Perl y utiliza R [7] para generar los gráficos.
Tarea 1: Recomendar configuraciones
óptimas
de parámetros de configuración para especificar la carga de trabajo. En esta
tarea, usamos MySQL como base de datos back-end y Apache Tomcat como
nuestro motor de servidor web.
Objetivo: recomendar la configuración óptima de MySQL
Buscamos evaluar el impacto en el rendimiento debido a las siguientes
dos opciones de configuración de software para la base de datos
MySQL:
Almacenamiento en caché:Si almacenar en caché los resultados de la consulta o no;
Motores de almacenamiento:Ya sea para usar MyISAM o InnoDB como
el motor de almacenamiento.

Los sistemas empresariales interactúan a menudo con otros
componentes de software, como bases de datos o servidores de correo.
Las configuraciones subóptimas de estos componentes pueden afectar
el rendimiento del sistema. Un probador de carga necesita explorar
estas configuraciones y brindar recomendaciones para la
implementación. En esta tarea, usamos Dell DVD Store (DS2) como
nuestro sistema de estudio de caso.
Sistema estudiado: la tienda de DVD de Dell
Experimentos y colecciones de datos
DS2 no tiene registros, por lo que instrumentamos manualmente sus
cuatro páginas JSP. Realizamos 4 pruebas de carga de una hora: InnoDB
con y sin almacenamiento en caché de consultas, y MyISAM con y sin
almacenamiento en caché. Las 4 ejecuciones se realizan bajo la misma
carga de trabajo y se realizan en una máquina con CPU de un solo
núcleo con 1 GB de RAM y un5,400disco duro rpm. Cada prueba
generada durante120,000líneas de registro.

La aplicación Dell DVD Store (DS2) es una aplicación en línea de código
abierto que se utiliza para comparar el hardware de Dell. [6]. DS2 proporciona
funciones básicas de comercio electrónico, que incluyen: registro de usuarios,
inicio de sesión de usuarios, búsqueda de productos y compra de artículos.
DS2 contiene una base de datos, un generador de carga y una
aplicación web. Viene en diferentes paquetes de distribución que
admiten varias plataformas web (por ejemplo, Apache Tomcat o
JBoss) y proveedores de bases de datos (MySQL, Microsoft SQL
Server y Oracle). La aplicación web consta de cuatro páginas JSP
que interactúan con la base de datos y muestran contenidos
dinámicos. El generador de carga DS2 admite una gama
Análisis de resultados y conclusiones
Realizamos los análisis de rendimiento sobre los resultados de estos 4
carreras.
Para determinar el impacto en el rendimiento del almacenamiento en caché,
realizamos dos comparaciones. Primero, comparamos los resultados de InnoDB
con/sin almacenamiento en caché, luego MyISAM con/sin almacenamiento en
caché. Usamos los identificadores de sesión para recuperar las secuencias. Nuestros
dos informes de análisis de rendimiento han marcado18 escenarios de rendimiento
desviado. Al examinar las subtablas de diagnóstico de rendimiento paso a paso en
todos los pares de eventos, encontramos que los eventos, que invocan operaciones
de base de datos, funcionan mejor con el almacenamiento en caché habilitado.
 Para determinar el impacto en el rendimiento de diferentes motores de
almacenamiento, comparamos los resultados de MySQL configurado con el
motor MyISAM con los del motor InnoDB. Dado que nuestro análisis anterior
muestra que habilitar el almacenamiento en caché produce un mejor
rendimiento, solo comparamos las dos ejecuciones con el almacenamiento
en caché habilitado. De nuevo,18los escenarios están marcados. Al investigar
las subtablas de diagnóstico de rendimiento paso a paso, encontramos que
los eventos relacionados con la base de datos funcionan mejor con el motor
InnoDB. Nuestro hallazgo está de acuerdo con estudios de referencia previos
[4].
Utilizando nuestros informes de análisis de rendimiento, concluimos
que DS2 debe implementarse con las siguientes configuraciones de
MySQL para lograr un rendimiento óptimo: InnoDB como motor de
almacenamiento y caché habilitado. la precisión es 100%entre los tres
informes de análisis de rendimiento.
Tarea 2. Certificación de software/hardware
Plataformas
Hoy en día, los sistemas soportan varias plataformas de software
(por ejemplo, sistemas operativos) así como plataformas de hardware.
Un probador de carga necesita verificar si un sistema bajo prueba
puede hacer un uso óptimo de los servicios y recursos disponibles. En
esta tarea, usamos JPetStore como nuestro sistema de estudio de caso.
Sistema estudiado: JPetStore
JPetStore [2] es una aplicación web de código abierto más
grande y compleja en relación con DS2. A diferencia de la
versión original de Pet Store de Sun, que se enfoca más en
demostrar la capacidad de la plataforma J2EE, JPetStore es una
reimplementación con un diseño más eficiente [3] y tiene como
objetivo comparar la plataforma J2EE con otras plataformas
web como.Neto. A diferencia de DS2, que incorpora toda la
lógica de la aplicación en el código JSP, JPetStore utiliza el
marco "Modelo-Vista-Controlador" y archivos XML para
asignaciones de objetos/relaciones. En esta tarea,
implementamos la aplicación JPetStore en Apache Tomcat y
usamos MySQL como base de datos.
Objetivo: certificar un servidor multinúcleo
En este estudio de caso, buscamos certificar la plataforma de
hardware verificando si hay una ganancia de rendimiento al migrar
JPetStore de una máquina de un solo núcleo a un servidor
multinúcleo más potente.
Experimentos y recopilación de datos
Como JPetStore no viene con un generador de carga, usamos Webload [8],
una herramienta de prueba de carga web de código abierto, para probar la
carga de la aplicación. Usando Webload, hemos registrado un solo escenario
de cliente para reproducirlo durante las pruebas de carga. Además,
configuramos Webload para que aumente gradualmente la carga de trabajo
a medida que avanza la prueba de carga.
En cada plataforma de hardware, realizamos una ejecución de una
hora. La primera ejecución utiliza una máquina que tiene una sola CPU
con 1G de memoria y una5,400rpm disco duro. La segunda
ejecución usa otra máquina que tiene una CPU Quad-Core con 8G
de memoria y una7,200rpm disco duro. Ambas ejecuciones
generan más770,000líneas de registro.
Análisis de resultados y conclusiones
La figura 3 muestra el informe de análisis de rendimiento de JPet-Store.
El informe ha marcado nuestro único escenario. El color de la desviación
(azul) muestra que la ejecución en la máquina de cuatro núcleos supera
estadísticamente a la ejecución en la máquina con una sola CPU. Sin
embargo, la comparación visual de las dos carreras revela que:
1. El contraste del tiempo de respuesta máximo y mínimo de ambas
ejecuciones es muy grande, especialmente para la ejecución en el
servidor multinúcleo. Como se muestra en el diagrama de frijoles de la
Figura 3, el tiempo de respuesta mínimo para la máquina Quadcore es
de alrededor de 30 segundos y el máximo es de alrededor de 200
segundos.
2. Como se muestra en el gráfico inferior de la Figura 3, ambas ejecuciones
se ralentizan a medida que avanza la prueba de carga debido al
aumento constante de la carga de trabajo. Sin embargo, el tiempo de
respuesta en la máquina de cuatro núcleos durante los últimos
segundos es de aproximadamente3veces más que la máquina de un
solo núcleo durante la carga pesada (alrededor de200segundos en la
máquina Quadcore versus alrededor80segundos en la máquina de un
solo núcleo).
Repetimos ambas ejecuciones y seguimos obteniendo los mismos patrones. A
través de un examen minucioso de la subtabla de diagnóstico de rendimiento paso
a paso en nuestro informe, revelamos un error de rendimiento de MySQL. El motor
de almacenamiento MySQL InnoDB tiene problemas para escalar a máquinas de
varios núcleos. Nuestro hallazgo está confirmado por las publicaciones de los
desarrolladores de MySQL [1].
Utilizando nuestro enfoque de análisis de rendimiento,
concluimos que el rendimiento de JPetStore mejora en una
máquina más potente. Sin embargo, existe un error de
rendimiento de MySQL que prohíbe el uso eficiente de la
arquitectura de hardware multinúcleo bajo una carga pesada. La
precisión de este informe es100%.
Tarea 3. Estudiar el impacto de los cambios en el
sistema
Los sistemas se someten constantemente a cambios de mantenimiento para
corregir errores y hacer frente a nuevos estándares o nuevas interfaces. Los
cambios pueden causar un rendimiento del sistema subóptimo. En esta tarea,
utilizamos una aplicación empresarial grande como nuestro sistema de estudio de
caso.
Sistema estudiado: una aplicación empresarial grande
El sistema que estudiamos es una gran aplicación empresarial
distribuida. Esta aplicación admite una gran cantidad de
escenarios que utilizan miles de usuarios simultáneamente.

Rendimiento
5,463
6,193
Figura 3. El informe de análisis de rendimiento en JPetStore
Objetivo: evaluar diferentes diseños de software
Hay una nueva compilación de software que utiliza un mecanismo
de comunicación diferente. Queremos determinar el impacto en el
rendimiento del nuevo diseño.
Experimentos y recopilación de datos
Un probador de carga ha realizado los experimentos. Se ejecutan dos pruebas de
carga de 8 horas en diferentes compilaciones de software bajo la misma carga.
Ambas ejecuciones generan más2millones de líneas de registro.
Análisis de resultados y conclusiones
Esta es una gran aplicación empresarial con registros de ejecución fácilmente
disponibles. Después de revisar brevemente las líneas de registro, encontramos tres
parámetros principales que se pueden usar para vincular las líneas de registro para
formar escenarios.
Nuestro informe señala alrededor30escenarios de desviación del
rendimiento. La mayoría de los escenarios se ejecutan más de4,000
veces. Nuestro informe revela que la compilación actual funciona peor
que la compilación anterior. Al examinar las subtablas de diagnóstico de
rendimiento paso a paso, este probador de carga puede identificar los
pasos que se desvían del rendimiento y, posteriormente, identificar los
problemas de rendimiento del nuevo diseño.
Nuestro informe de análisis de rendimiento tiene una precisión de77%.
Algunas secuencias marcadas no son escenarios. Por lo tanto, las falsas
alarmas son provocadas por los intervalos de tiempo aleatorios entre los
pares de eventos adyacentes.
Llegamos a la conclusión de que nuestro informe de análisis de
rendimiento ha ayudado al probador de carga a evaluar el impacto en el
rendimiento de diferentes diseños. La precisión de nuestro informe de
análisis de rendimiento es77%.
Evento
Desviación
Secuencias
0.9
E1→E3→E4
→ E2→E4
→ E5→E6
6. Discusión y Trabajo Futuro
En esta sección, discutimos nuestros resultados y el trabajo futuro.
Comparaciones de rendimiento
Nuestro enfoque utiliza los resultados de una ejecución anterior como
referencia de rendimiento informal. La línea base de rendimiento
también se puede derivar de los datos en una o más ejecuciones. Por
ejemplo, podemos formar la línea base de rendimiento al combinar los
resultados de 10 ejecuciones realizadas el año pasado. Los grandes
datos resultantes son más deseables para inferir el comportamiento de
rendimiento común pasado.
Creemos que vale la pena investigar los escenarios de mejora y
degradación del rendimiento por dos motivos. Primero, un probador de
carga necesita verificar las correcciones de errores de rendimiento
comparando la ejecución actual con una prueba que sufre de
problemas de rendimiento. En este caso, los casos de mejora del
rendimiento también le interesan. En segundo lugar, no queremos
perdernos posibles problemas de rendimiento. Tome nuestro caso de
estudio de JPetStore, por ejemplo. El rendimiento en un servidor
potente es generalmente mejor, pero sufre una ralentización severa en
condiciones de estrés.
Recuperación de escenario
Nuestro enfoque requiere algo de trabajo manual al principio, ya que
necesitamos encontrar cuáles son los parámetros de identificación en
los registros. Este es un esfuerzo de una sola vez y requiere un esfuerzo
mínimo. Estos parámetros se pueden obtener preguntando a un
experto en el dominio o hojeando los registros.
Análisis estadístico
Nuestro enfoque utiliza una prueba t de Student para comparar las
distribuciones de tiempo de respuesta. Una prueba t de Student es una
prueba estadística paramétrica que supone que el tiempo de respuesta se
distribuye normalmente. Las pruebas estadísticas no paramétricas, como la
prueba de Kolmogorov-Smirnov [19], también se pueden utilizar en nuestro
análisis. Estas pruebas no tienen suposiciones sobre la distribución de los
datos. Las pruebas paramétricas son menos estrictas que las pruebas no
paramétricas. En otras palabras, las pruebas no paramétricas tienden a decir
que no hay diferencias estadísticas entre dos conjuntos de datos, mientras
que las pruebas paramétricas indicarían una diferencia estadísticamente
significativa. Elegimos usar la prueba t de Student menos estricta, ya que
queremos encontrar todos los posibles problemas de rendimiento. Además,
también hemos intentado usar la prueba de Kolmogorov-Smirnov para
verificar los hallazgos en nuestros estudios de casos. Encontramos que los
resultados de la prueba de Kolmogorov-Smirnov concuerdan con la prueba
de la t de Student. Este hallazgo se confirma con los resultados informados
por Bulej et al. [21].
Análisis del rendimiento del sistema mediante registros de ejecución
Nuestro enfoque utiliza registros de ejecución fácilmente disponibles e infiere
el rendimiento del sistema en función de las diferencias de tiempo entre las
líneas de registro. Por lo tanto, nuestro enfoque está limitado por la
granularidad de las líneas de registro. Además, asumimos que los registros
son relativamente estables en el tiempo. Esta suposición es válida para
muchos sistemas industriales. Dado que los registros ya están procesados
por muchas otras herramientas, los cambios de registro generalmente se
minimizan. En el futuro, planeamos aplicar coincidencias aproximadas en
diferentes secuencias entre ejecuciones.
Nuevos escenarios
Dado que no hay objetivos de rendimiento formales ni datos de
ejecuciones anteriores para nuevos escenarios, nuestro enfoque actual
no los analizará. En el futuro, planeamos inferir el desempeño esperado
del escenario en base a los escenarios existentes.
7 Trabajo relacionado
Discutimos dos áreas de trabajo relacionadas.
Prueba de carga
La mayoría de las investigaciones existentes sobre pruebas de carga se
centran en la generación automática de conjuntos de pruebas de carga [13,
14, 15, 17, 20, 25, 35]. Nuestro trabajo anterior [28] se enfoca en descubrir
automáticamente problemas funcionales en una prueba de carga. Bulej et al.
[21] proponen el concepto de evaluación comparativa de regresión como una
variante de las pruebas de regresión para la regresión de rendimiento. La
evaluación comparativa de regresión compara el rendimiento en diferentes
versiones de los sistemas que utilizan el mismo conjunto de evaluación
comparativa. Nuestro trabajo es una mejora sobre la evaluación comparativa
de regresión en cuatro aspectos. Primero, nuestro enfoque recupera los
escenarios automáticamente sin especificación. Segundo,
nuestro enfoque es más detallado, ya que analizamos el rendimiento de
los escenarios, así como los pasos individuales en cada escenario. En
tercer lugar, nuestro enfoque minimiza la cantidad de procesamiento
manual. En cuarto lugar, los problemas informados en nuestro informe
de análisis de rendimiento se clasifican para que un probador de carga
pueda priorizar sus esfuerzos y hacer un uso óptimo de su tiempo.
Supervisión y análisis automatizados del rendimiento de los
sistemas de producción
La supervisión y el análisis automatizados del rendimiento de los
sistemas de producción se pueden dividir en dos subcategorías: analizar
las métricas de rendimiento y analizar los registros.
El siguiente trabajo analiza las métricas de rendimiento: Avritzer et
al. [12, 11] proponen varios algoritmos para detectar la necesidad de
rejuvenecimiento del software al monitorear los valores cambiantes de
varias métricas del sistema. Mi et al. [23, 31] y Cohen et al. [24, 36]
desarrollan firmas de aplicaciones basadas en las diversas métricas del
sistema (como CPU, memoria). Las métricas de la aplicación se utilizan
además para la planificación eficiente de la capacidad y la detección de
anomalías. La principal diferencia entre estos enfoques y el nuestro es
que usamos registros de ejecución para nuestro análisis. En
comparación con las métricas del sistema, los registros de ejecución
proporcionan información específica de dominio más detallada.
El siguiente trabajo analiza los registros fácilmente sin
instrumentación adicional: Aguilera et al. [10, 33] desarrollaron varios
algoritmos para realizar una depuración de rendimiento de caja negra
en sistemas distribuidos. Utilizan la información del encabezado en los
rastros de paquetes TCP (fuente, destino y tiempo) para inferir las rutas
causales dominantes a través de un sistema distribuido.
Desafortunadamente, la precisión de las rutas causales inferidas
disminuye a medida que aumenta el grado de paralelismo. Esto no es
ideal para el análisis de pruebas de carga, ya que hay muchos
intercambios de mensajes que ocurren simultáneamente. Marwede et
al. [30] utilizan la anomalía de sincronización para descubrir
automáticamente problemas funcionales.
8. Conclusiones
Es difícil realizar un análisis de rendimiento de los resultados de las
pruebas de carga debido a la ausencia de una línea de base de
rendimiento documentada, la presión del tiempo, la sobrecarga de
monitoreo y el gran volumen de datos. En este documento,
proponemos un enfoque que marca automáticamente los posibles
problemas al adoptar una ejecución anterior como referencia de
rendimiento y compararla con ella. Nuestro enfoque es fácil de adoptar
y escala bien a grandes sistemas con alta precisión (77%).
Reconocimiento
Agradecemos a Research In Motion (RIM) por proporcionar
acceso a la aplicación empresarial utilizada en nuestro estudio de
caso. Los hallazgos y opiniones expresados en este documento
pertenecen a los autores y no necesariamente representan o
reflejan los de RIM y/o sus subsidiarias y afiliadas.
Además, nuestros resultados no reflejan de ninguna manera la calidad de los
productos de software de RIM.
Referencias
[1] Respuestas de Heikki Tuuri Innodb - Parte I.http://tiny.cc/
N8qVq.
[2] iBATIS JPetStore. http://sourceforge.net/
proyectos/ibatisjpetstore/.
[3] Implementación de Microsoft .NET Pet Shop us-
ing Java. http://www.clintonbegin.com/
JPetStore-1-2-0.pdf.
[4] Puntos de referencia de InnoDB vs MyISAM vs Falcon.http://
tiny.cc/lPDFp.
[5] Ley Sarbanes-Oxley de 2002.http://www.soxlaw.
com/.
[6] La tienda de DVD de Dell. http://linux.dell.com/
tienda de dvd/.
[7] El Proyecto R para Computación Estadística.http://www.
r-proyecto.org/.
[8] Carga web.http://www.webload.org/.
[9] Encuesta de Gestión del Desempeño Aplicado, octubre de 2007.
[10] MK Aguilera, JC Mogul, JL Wiener, P. Reynolds y
A. Muthitacharoen. Depuración de rendimiento para sistemas
distribuidos de cajas negras. EnActas del decimonoveno
Simposio ACM sobre principios de sistemas operativos, 2003.
[11] A. Avritzer, A. Bondi, M. Grottke, KS Trivedi y EJ
Weyuker. Aseguramiento del desempeño a través del rejuvenecimiento del
software: Monitoreo, estadísticas y algoritmos. Enel internacional
Conferencia sobre Sistemas y Redes Confiables, 2006.
[12] A. Avritzer, A. Bondi y EJ Weyuker. Garantizar estable
rendimiento para sistemas que se degradan. Enel 5to interna-
taller nacional de software y rendimiento, 2005.
[13] A. Avritzer y B. Larson. Software de prueba de carga usando de-
prueba de estado terminista. EnActas del simposio internacional
ACM SIGSOFT de 1993 sobre pruebas de software y
análisis, 1993.
[14] A. Avritzer y EJ Weyuker. Generación de suites de prueba para
pruebas de carga de software. EnActas del simposio internacional
ACM SIGSOFT de 1994 sobre pruebas de software y
análisis, 1994.
[15] A. Avritzer y EJ Weyuker. La generación automática de
cargar conjuntos de pruebas y la evaluación del software resultante.
Trans. IEEE. suave Ing., 21(9), 1995.
[16] P. Barham, A. Donnelly, R. Isaacs y R. Mortier. Usando
urraca para extracción de solicitudes y modelado de cargas
de trabajo. En OSDI'04: Actas de las VI Jornadas de Simposio
sobre diseño e implementación de sistemas operativos, 2004.
[17] MS Bayan y JW Cangussu. Estrés y carga automáticos
Pruebas para sistemas embebidos. En30º Anual Internacional
Congreso de Software y Aplicaciones Informáticas, 2006.
[18] B. Beizer.Pruebas de sistemas de software y control de calidad.
Van Nostrand Reinhold, marzo de 1984.
[19] S. Boslaugh y DPA Watters.Estadísticas en pocas palabras A
Referencia rápida de escritorio. O´Reilly, 2008.
[20] LC Briand, Y. Labiche y M. Shousha. usando genetica
algoritmos para análisis temprano de programabilidad y pruebas de
estrés en sistemas en tiempo real.Programación genética y máquinas
evolutivas, 7(2), 2006.
Ver estadísticas de publicación
[21] L. Bulej, T. Kalibera y P. Tůma. Análisis de resultados repetidos para la
evaluación comparativa de regresión de middleware.Llevar a cabo. Eval.,
60(1-4):345–358, 2005.
[22] MY Chen, A. Accardi, E. Kiciman, J. Lloyd, D. Patter-
hijo, A. Fox y E. Brewer. Gestión de fallos y evolución basada
en rutas. Enla 1ra conferencia sobre Symposium on Net-
diseño e implementación de sistemas trabajados, 2004.
[23] L. Cherkasova, K. Ozonat, N. Mi, J. Symons y E. Smirni.
¿Anomalía? cambio de aplicacion? o cambio de carga de trabajo? hacia
la detección automatizada de anomalías y cambios en el rendimiento
de la aplicación. EnConferencia internacional IEEE sobre
Sistemas y redes confiables, 2008.
[24] I. Cohen, S. Zhang, M. Goldszmidt, J. Symons, T. Kelly y
Un zorro. Captura, indexación, agrupamiento y recuperación del
historial del sistema. EnActas del vigésimo simposio de la ACM
sobre los principios de los sistemas operativos, 2005.
[25] V. Garousi, LC Briand e Y. Labiche. Consciente del tráfico
Pruebas de estrés de sistemas distribuidos basados en modelos
uml. EnActas de la 28ª conferencia internacional sobre Soft-
ingeniería de mercancías, 2006.
[26] R. Jain.El arte del análisis del rendimiento de los sistemas informáticos:
Técnicas de Diseño Experimental, Medición, Simulación
ción y modelado. Wiley-Interscience, 1991.
[27] ZM Jiang, AE Hassan, G. Hamann y P. Flora. un au-
enfoque automatizado para abstraer los registros de ejecución de los
eventos de ejecución.Revista de Mantenimiento y Evolución del Software:
Investigación y Práctica, 20(4), 2008.
[28] ZM Jiang, AE Hassan, G. Hamann y P. Flora. Auto-
Identificación automática de problemas de pruebas de carga. EnEn
Actas de la 24.ª Conferencia Internacional IEEE sobre Software
Mantenimiento (ICSM), 2008.
[29] P. Kampstra. Beanplot: una alternativa de diagrama de caja para visualización
comparación de distribuciones.revista de software estadístico,
Fragmentos de código, 28(1), 2008.
[30] N. Marwede, M. Rohr, A. van Hoorn y W. Hasselbring.
Diagnóstico automático de fallas en sistemas de software distribuidos a gran
escala basado en la correlación de anomalías de comportamiento de tiempo.
Enla 13ª Conferencia Europea sobre Mantenimiento de Software
y Reingeniería, 2009.
[31] N. Mi, L. Cherkasova, KM Ozonat, J. Symons y
E. Smirni. Análisis del rendimiento de la aplicación y su cambio a
través de firmas de aplicaciones representativas. EnRed
Simposio de Operaciones y Gestión, 2008.
[32] DL Parnas. Envejecimiento del software. EnCISE '94: Actas de
la 16ª conferencia internacional sobre ingeniería de software,
Los Alamitos, CA, EE. UU., 1994.
[33] P. Reynolds, JL Wiener, JC Mogul, MK Aguilera y
A. Vahdat. Wap5: depuración de rendimiento de caja negra
para sistemas de área amplia. EnWWW '06: Actas del 15
conferencia internacional sobre la world wide web, 2006.
[34] EJ Weyuker y FI Vokolos. Experiencia con desempeño
pruebas de manejo de sistemas de software: problemas, un enfoque y
caso de estudio.Trans. IEEE. suave Ing., 26(12), 2000.
[35] J. Zhang y SC Cheung. Generación automatizada de casos de prueba
para la prueba de estrés de los sistemas multimedia. suave Practica
Exp., 32(15), 2002.
[36] S. Zhang, I. Cohen, J. Symons y A. Fox. Conjuntos
de modelos para el diagnóstico automatizado de problemas de
rendimiento del sistema. EnActas de la Conferencia Internacional
de 2005 sobre Sistemas y Redes Confiables, 2005.