Práctica 6: Diseño y Evaluación de Configuraciones :: Realización de Un BenchMark

Realización del BenchMark---Descargarlo(Debe contar con una máquina virtual java)

Lenguaje

El benchMark está hecho en java para que se pueda ejecutar en muchas plataformas, además gráfico y por lo tanto tiene ventanas que lo hacen muy comodo al usuario. Ha sido desarrollado con JBuilder y se debe ejecutar con al menos la versión sexta de JRE

Objetivos

Mis objetivos para esta práctica son los siguientes: Pretendo hacer un benchmark muy comodo e intuitivo capaz de ser usado en cualquier sistema operativo y con cualquier ordenador. Además pretendo que sea gráfico y que pueda ser capaz de comparar con el de forma genérica varios ordenadores para darme una idea de cual es mejor

El benchmark se va a ejecutar 3 veces, de las cuales, las 2 primeras se ejecutan en un equipo en diferentes SO, y la segunda se ejecuta en un segundo equipo en Kubuntu

El BenchMark - Instrucciones

Paso a explicar de forma breve el funcionamiento del benchMark, en concreto, este benchMark consta de 3 partes: Menu superior, menú lateral y cuerpo. En el cuerpo se van mostrando los resultados de cada benchMark y en la botonera da a elegir los posibles benchMark que podemos hacer

Paso a explicar las opciones que da el menú superior, dentro de Archivo, ofrece Salir y dentro de Ayuda ofrece Acerca de... (En este último muestra una ventana con información del creador,es decir, de mi)

En la botonera de la derecha se pueden obtener varios benchMark y un botón de información, en el botón de información podemos ver un resumen de las características de nuestra máquinaSi presionamos este botón nos mostrará de forma visual las características generales de nuestra máquina

Ahora podemos pasar a ejecutar cada uno de los benchmark dandonos pantallas como estas donde se nos muestra la información de una manera bastante visual

Y si ejecutamos el modo gráfico podremos observar que pinta una batería de fotos tal y como estas:

El BenchMark - Desarrollo

CPU

Para el benchMark de la CPU he usado hecho sumas y multiplicaciones con enteros y reales, en concreto se hacen 10000000 sumas y multiplicaciones para enteros y para reales, y además esas 10000000 sumas y multiplicaciones se repiten 10 veces para hallar la media de todas estas repeticiones y obtener un valor fiable, por lo tanto en este apartado se llegan a hacer unas 400000000 operaciones

Para obtener el tiempo mido al principio y al final y resto ambos, obteniendo asi el tiempo empleado, y para obtener un tiempo más fiable haga la media (esto ya lo he explicado de forma detallada en el parrafo anterior). Las medidas que obtenemos son SE/ms, SR/ms, ME/ms y MR/ms con S me refiero a Suma, con E enteros, con M multiplicaciones y con R a reales por lo tanto obtenemos el tipo de cálculo, por unidad de tiempo

Memoria

En este apartado, lo que hago es ejecutar un algoritmo de ordenación sobre vectores de varios tamaños, en concreto de 1000, 10000, 100000 y 1000000 elementos. El algoritmo es un mergeSort que utilizando la dinámica divide y venceras. Las medidas que obtenemos aquí son milisegundos
Disco

En este apartado obtenemos el resultado de guardar en 4 archivos diferentes, un número de bloques de 512Bytes diferente, tras hacer los cálculos se nos presentará todas las variables ( número de archivos, número de bloques escrito en total, tiempo medio en escribir un bloque y bloques escritos en un milisegundo, esta última será la que utilizaremos para las comparativas)

Gráficos

En este apartado, lo que quiero medir está más bien referido al tiempo invertido en pintar fotos, que en el número de fotos que caben en pantalla(como dice el guión) puesto que me parece más significativo el primer cálculo.En concreto se muestran una batería de 56 fotografías. Para poder hacerlas visibles al ojo, hago un retardo de 1ms entre foto y foto, este tiempo de espera de 1 milisegundo, al final se lo resto al tiempo total de cálculo.Para las medidas, calculo el tiempo total y lo divido entre el número de fotos, aunque los cálculos se muestran mucho mejor en la propia aplicación como vamos a ver ahora.

Ejecución del BenchMark en Diferentes Máquinas

Ejecución Base

En cuanto a las ejecuciones voy a poner los resultados del benchmark con capturas pues lo he hecho como para que no haga falta interpretarlo, si no que él mismo defina de forma muy visual los resultados

Se ejecuta en mi ordenador portatil:
Tipo de procesador Intel Pentium III Xeon, 2266 MHz (7 x 324)
En Windows Vista Home Premium

Se ejecuta en mi ordenador portatil:
Tipo de procesador Intel Pentium III Xeon, 2266 MHz (7 x 324)
En Ubuntu 9.04

Se ejecuta un ordenador de Mesa: Que consta de KUbuntu 9.04 y tiene un AMD Semprom 2800+

Conclusiones

Según los resultados obtenidos, como podemos ver arriba, gana el caso 2.La diferencia con respecto al primero es mínima, pero esto es lógico debido a que se traba del mismo sistema aunque con diferentes sistemas operativos. Por lo que se puede deducir que Ubuntu es más eficiente que Windows Vista

Donde más se notan estas diferencias es en cuanto a la CPU, que en Ubuntu puede operar hasta una 4.000 Operaciones más por milisegundo. En cuanto a Disco, es capaz de escribir hasta 1000 bloques más por milisegundo, es decir unos 500Kb más por ms. En cuanto a memoria, tarda más o menos igual, aunque claro está siempre gana Ubuntu, que tarda unos 20 segundos menos en todas las operacionesY por último en cuanto a Gráficos, Ubuntu se muestran una 7.24 fotos por segundo mientras que en Vista se muestran 7.16imagenes/seg. Esta diferencia es la más reducida,, aunque vemos que también gana Ubuntu

En cuanto al último sistema, podemos ver con el BenchMark que es muy pobre comparado con la segunda Ejecución (Y es cierto). En cuanto a CPU se pueden hacer en torno a los 3000 cálculos por milisegundo mientras que el sistema con Ubuntu ronda por los 25.000 calculos por milisegundo.En cuanto a Disco vemos que tarda el triple en manejar su disco (de 327ms del sistema en Ubuntu a 865ms de este sistema).En memoria se puden escribir unos 1000Bloques/ms mientras que en el sistema con Ubuntu es casi el doble puesto que ronda los 2000Bloques/ms.Por último vemos que en cuanto a gráfica también es muy pobre porque es capaz de imprimir por pantalla unas 2.94Fotos/Segundo mientras que el de Ubuntu podía unas 7.24 Imagenes/seg es decir más del doble.

Práctica 5: Diseño y Evaluación de Configuraciones :: Mejora de Prestaciones

Mejorar las Prestaciones de un Equipo como Servidor

Introducción:

La necesidad de mejora del equipo en concreto surje por el hecho de querer convertirlo en un Servidor Web. La necesidad en concreto es mudar una página web de un servicio de hosting a un servidor propio, por motivos económicos. Se muda el servidor web, aunque se mantiene el servidor de base de datos en el servidor antiguo, por la complejidad que tenía la base de datos. En concreto se trata de una tienda online ( generada con Oscommerce, una plataforma OpenSource). Como factores influyentes hay que destacar que el servidor donde se quiere alojar es un ordenador con 4 años de antiguedad, al que se le quiere dar alguna utilidad

Fases de Evaluación del Sistema Informático:

Comenzamos el proceso de mejora, haciendolo de una manera ordenada y siguiendo los pasos establecidos en el tema 1 de la asignatura

1. Fijar objetivos y definicir el sistema base

Nuestro principal objetivo es hacer nuestro servidor mucho más rapido, capaz de soportar gran cantidad de conexiones simultaneas y agilizar el tiempo de servir las páginas web alojadas en él. El sistema base:

Procesador: AMD Semprom (tn) Procesosr 2800+ Frecuencia: 1602.05 MHz L2 Caché: 256 KB Sistema Operativo: SO Ubuntu 6.10 (recordemos que el equipo tiene 4 años y hace 3 que no se usa Linux en él)

2. Hacer una lista de los servicios que ofrece el sistema y sus posibles resultados:

El sistema dispone de servicio http, con php 5.2 y apache 2.0, se conecta a una base de datos externa alojada en la misma red local, el servidor en el que se aloja la base de datos está conectado mediante Wifi. Además nuestro servidor dispone de servidor de base de datos que está deshabilitado porque no se está usando

3. Seleccionar las métricas

Las métricas que voy a usar son las siguientes:

• Paginas servidas por segundo
• Tiempo en responder una petición

No Obstante en el análisis iremos apuntando los fallos por petición para tener una idea de la fiabilidad de los datos tomados

4. Listar los parámetros que pueden afectar a las prestaciones

Teniendo en cuenta el objetivo de la mejora los parametros que lo condicionan son diversos:

• A nivel hardware (memoria principal, CPU...) mejoras en la rapidez de la ejecución de los procesos, hace que sean más rapidas las peticiones porque tarda menos tiempo en procesar la petición
• A nivel de Software ( un software más actual seguramente sepa aprovechar mejor los recursos )
• Configuración de los parametros del servidor
• Velocidad de conexión (sobre todo de subida)
• Eficiencia del proceso encargado de gestionar la petición (código PHP)
• Tiempo de acceso a la información

5. Factores a estudiar

Teniendo en cuenta que el cambio se hace para evitar gastos, es lógico que nuestra mejora tenga que verse restringida al gasto de dinero, por lo tanto los factores que estudiaremos serán la actualización de software, mejora de la eficiencia del código PHP, configuración de PHP y tiempo de acceso a la información

6. Seleccionar las técnicas de evaluación:

Se ejecutará un benchmark que simula una carga de trabajo indicada. El benchmark que más confianza me da y más facilidad de uso tiene es el incorporado por apache llamado apache benchmark

7. Seleccionar la carga de trabajo

La carga de trabajo que simularemos estará en el rango de una carga de 10 a 20 peticiones y de 1 a 10 peticiones simultaneas, en este rango he seleccionado varias magnitudes para poder hacer varias mediciones por lo tanto las unidades elegidas son:

• 10 peticiones con ninguna concurrente
• 10 peticiones con ninguna concurrente
• 10 peticiones con ninguna concurrente
• 20 peticiones con ninguna concurrente
• 10 peticiones con 5 concurrentes
• 20 peticiones con 5 concurrentes
• 10 peticiones con 10 concurrente
• 20 peticiones con 10 concurrente

8. Diseñar los experimentos

Los experimentos tratan de simular la carga (especificada en el punto anterior) mediante el benchmark de apache desde un servidor totalmente externo y con un ancho de banda bastante amplio, lo suficiente como para que no influya en las mediciones, por lo tanto, especificamente haremos las mediciones desde la IP 150.214.191.99 a la IP 88.3.30.12 que es nuestro servidor. Este sería un benchMark de los que produce Apache BenchMark

This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 88.3.30.12 (be patient).....done Server Software: Apache/2.2.11 Server Hostname: 88.3.30.12 Server Port: 80 Document Path: /oscommerce/catalog/ Document Length: 29674 bytes Concurrency Level: 10 Time taken for tests: 12.921 seconds Complete requests: 10 Failed requests: 9 (Connect: 0, Receive: 0, Length: 9, Exceptions: 0) Write errors: 0 Total transferred: 301486 bytes HTML transferred: 296576 bytes Requests per second: 0.77 [#/sec] (mean) Time per request: 12920.632 [ms] (mean) Time per request: 1292.063 [ms] (mean, across all concurrent requests) Transfer rate: 22.79 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 66 85 12.7 88 103 Processing: 1859 9794 3446.8 11134 12847 Waiting: 492 1643 605.9 1881 2382 Total: 1925 9879 3455.5 11226 12921 Percentage of the requests served within a certain time (ms) 50% 11226 66% 11436 75% 11785 80% 12118 90% 12921 95% 12921 98% 12921 99% 12921 100% 12921 (longest request)

9. Analizar e interpretar los datos
Introducción al análisis

El análisis lo haremos como ya hemos especificado en los puntos anteriores. En concreto la orden que vamos usar desde el servidor externo es la siguiente "sudo ab -n10 -c5 http://88.3.30.12/oscommerce/oscommerce-2.2rc2a/catalog/" donde la opción -n es el número de peticiones y el -c el de peticiones simultaneas, por lo tanto el valor de -n oscilará entre 10 y 20 y el de -c entre 1, 5 y 10

Esta imagen corresponde al servidor en Ubuntu 6.10, viendo en un navegador la página web

Sistema Base

Reunimos en una tabla la información obtenida

Peticiones Concurrentes	Peticiones Totales	Peticiones Fallidas	Peticiones por segundo	Tiempo en atender una petición (ms)	Porcentaje de Peticiones Fallidas
1	10	9	0,17	5964,258	90
1	20	18	0,15	6559,390	90
5	10	9	0,22	4631,657	90
5	20	18	0,21	4660,543	90
10	10	7	0,22	4631,735	70
10	20	19	0,22	4584,670	95
Media	15	13,333	0,19833	5172,04	88,88

Mejora Número 1

La primera mejora era bastante obvia pues el Sistema Operativo era bastante antiguo, actualizarlo implica que esté más evolucionado que trabaje con los recursos del sistema de una manera mucho más eficiente y además nos permite descargar paquetes pues para la versión de Ubuntu6.10 ya no existian paquetes. Asi que actualizamos a Kubuntu 9.04 como podemos ver en la imagen:

Peticiones Concurrentes	Peticiones Totales	Peticiones Fallidas	Peticiones por segundo	Tiempo en atender una petición	Porcentaje de Peticiones Fallidas
1	10	1	0,17	5848,434	10
1	20	18	0,16	6104,946	90
5	10	8	0,22	4630,695	80
5	20	19	0,22	4565,102	95
10	10	7	0,22	4627,724	70
10	20	18	0,22	4584,670	90
Media	15	11,83	0,2016	5060,2618	78,888

Mejora Número 2

Mudamos la base de datos, del sistema externo a nuestro sistema, por lo que habilitamos el servicio de Base de Datos. La base de datos cabe en nuestro sistema sin problemas y además no se espera un gran crecimiento de esta por lo que su traspaso va a hacer que mejore el sistema. La base de datos será mySQL.

Peticiones Concurrentes	Peticiones Totales	Peticiones Fallidas	Peticiones por segundo	Tiempo en atender una petición	Porcentaje de Peticiones Fallidas
1	10	9	0,89	1125,845	90
1	20	19	0,85	1180,214	95
5	10	9	1,03	970,873	90
5	20	18	1,08	925,470	90
10	10	9	0,77	1292,063	90
10	20	19	1,08	924,538	95
Media	15	13,833	0,8083	1069,833	92,22

Mejora Número 3

En esta mejora usaremos sistemas de caché en el propio servidor. Este método funciona de la siguiente forma: Cuando se recibe una petición al servidor, se analizan todos los parametros que puedan influir en el resultado ( POST, GET, SESSION y por suspuesto la url en cuestión), se le otorga un código y se almacena en base de datos, de forma que si algún otro consulta la misma página no se tendrá que volver a generar porque ya estaba en la caché

Peticiones Concurrentes	Peticiones Totales	Peticiones Fallidas	Peticiones por segundo	Tiempo en atender una petición	Porcentaje de Peticiones Fallidas
1	10	0	1,04	965,808	0
1	20	0	1,04	962,493	0
5	10	0	1,15	872,265	0
5	20	0	1,19	842,917	0
10	10	0	1,16	864,598	0
10	20	0	1,03	973,382	0
Media	15	0	1,1016	913,577	0

Mejora número 4

Ejecución en modo texto: Para evitar el uso de la CPU y que esté libre solo para la tarea que se le encomienda ( la de hacer de servidor) pondremos el sistema en modo texto.

Peticiones Concurrentes	Peticiones Totales	Peticiones Fallidas	Peticiones por segundo	Tiempo en atender una petición	Porcentaje de Peticiones Fallidas
1	10	0	1,03	968,043	0
1	20	0	1,04	965,567	0
5	10	0	1,16	858,432	0
5	20	0	1,18	845,525	0
10	10	0	1,12	896,534	0
10	20	0	1,19	842,006	0
Media	15	0	1,12	896,0178	0

10. Presentar los resultados

En esta sección voy a presentar los resultados obtenidos con las mejoras hechas al servidor, y con el que hemos llegado a obtener un aumento de las prestaciones de casi 6 veces más. Recuerdo los pasos seguidos:

• 1. Cambio de SO
• 2. Cambiar localización de Base de Datos
• 3. Implantar un sistema de caché
• 4. Servidor en Modo Texto

Peticiones por Segundo
Sistema	Media Pet/s	Descripción
Base	0,198	Este es el sistema base
Mejora 1	0,202	Se cambia el SO de Ubuntu 6.10 a Kubuntu 9.04
Mejora 2	0,808	Se cambia de localización la base de datos ( se pone en localhost)
Mejora 3	1,102	Se construye un sistema de cachés para ahorrar tiempo de proceso
Mejora 4	1,120	Se pone el servidor en modo texto, para evitar la ejecución de procesos innecesarios

Como podemos ver en el gráfico esta variable es mejor cuanto mayor sea, puntualizado esto vemos que la primera y segunda mejoras no difieren mucho entre si, pero aunque el cambio de sistema operativo, apenas aumente unas centesimas es un cambio obligado para poder pasar a hacer todos los demás. Por otro lado en el gráfico es más que evidente el grán cuello de botella de nuestro sistema es la base de datos, pues son los cambios que afectan a ella (2 y 3) los que más cambios producen, por útimo el cambio 4 apenas produce efecto, aun así produce una mejora (podemos mirarlo en la tabla)

Tiempo en atender una petición (ms)
Sistema	Media (ms)	Descripción
Base	5172,042	Este es el sistema base
Mejora 1	5060,262	Se cambia el SO de Ubuntu 6.10 a Kubuntu 9.04
Mejora 2	1069,834	Se cambia de localización la base de datos ( se pone en localhost)
Mejora 3	913,577	Se construye un sistema de cachés para ahorrar tiempo de proceso
Mejora 4	896,018	Se pone el servidor en modo texto, para evitar la ejecución de procesos innecesarios

Esta variable, como observamos en la gráfica, es contraria a la anterior y es mejor cuanto menor sea. Viendo detenidamente el gráfico, podemos ver mejor la diferencia que supone la primera mejora con respecto al sistema base, además se siguen observando los cambio centrales, con la diferencia de que la mejora 3 no tiene tanto efecto en esta variable como en la anterior, esto se debe a que es capaz de generar una página en mas o menos el mismo tiempo pero es más concurrente por lo que podrá producir más páginas en el mismo tiempo

Práctica 4: Diseño y Evaluación de Configuraciones :: Monitores

Monitor TaskInfo

Eleccion:

En la práctica 2 usé El administrador de tareas de Windows pero este no guarda en archivos de texto por lo que tuve que salir a la busqueda de otros monitores, di con Systemometers que gráficamente está muy bien pero tampoco admite la opción de guardar en texto de forma que tuve que optar definitivamente por un monitor que me descargué en la práctica 2 pero que no llegué a usar: TaskInfo. Este monitor permite el guardado en varios formatos entre los que se incluye html por lo que para presentarlo más tarde en html este tipo de guardado viene Genial

Introducción y elección de magnitudes:

Para realizar las mediciones he utilizado Windows Vista por lo que es muy lógico que los valores de la CPU esté muy por encima de la media, además, este sistema operativo tiende al lanzamiento de miles de aplicaciones al principio de iniciar la sesión por lo que una medición en plena apertura de la sesión puede tener mucha más carga que cualquier actividad que le demos más tarde, por lo que para hacer la medición base he optado por tomarla un poco despues de que el sistema se "calme" y todos los valores se reduzcan.

Antes de indicar las magnitudes que voy a utilizar, aclaro que en el guión especifica que como mucho se pueden elegir 5, asi que por no ser muy redundante escojo 4 medidas para analizar, para CPU escojo el % de uso de CPU, para la memoria uso el % de uso de memoria caché y para Disco uso Kb leyendose en ese momento y Kb escribiendose en ese momento, uso dos mágnitudes para el Disco porque voy a hacer diferentes cargas con el y si junto la lectura y la escritura no podríamos notar la diferencia

Medición Base

Como he dicho anteriormente voy a medir el sistema tras haber pasado un rato de comenzar el inicio, aunque no iniciaré ninguna otra aplicación tan solo esperaré a que todas las iniciales se hayan abierto, una vez se han abierto las cierro todas y espero a que el sistema se estabilice, En este momento el sistema tendrá los valores más bajos de toda esa ejecución del SO

Tras hacer todo lo anterior guardamos con TaskInfo que nos dá la siguiente tabla

CPU Clock MHz	942	% Idle Pri Threads
% CPU	13,55%	% Idle	86,45%
CPUs Number	2	Queue for CPU	0
Processes	85	Threads	928
Thread Sw/s	2.063	HW Ints/s	2.145
Total Ph KB	3.006.396	Free Ph KB	1.834.952
		Stand By KB	1.852.980
File Cache KB	241.228	File cache peak KB	302.748
Free Virt KB	5.009.524	Committed KB	1.213.228
Paged Pool KB	119.744	NonPaged Pool KB	107.844
Max Swap KB	3.313.596	Swap in Use KB	100.148
Page Faults/s	258
Page Ins KB/s	0	Page Outs KB/s	0
File Read KB/s	2	File Write KB/s	0
File Reads/s	50	File Writes/s	0
Client Read KB/s	0	Client Write KB/s	0
Srv Transmit KB/s	0	Srv Receive KB/s	0

Podemos ver exactamente el archivo que nos devuelve en este archivo

La tabla anterior es la que nos da Task Info, ahora extraemos las medidas que hemos seleccionado y las mostramos en una gráfica:

% Uso CPU	13,55%
Uso de Caché	241.228
Lectura en Disco	2KB/s
Escritura en Disco	0KB/s

Grafico

Debido a que las gráficas de Kiviat necesitan variables que alternen entre mayor_mejor y menor_mejor y las variables que mido en esta práctica no cumplen esas reglas la gráfica de Kiviat no respetará esta norma, no obstante voy a representarla en una gráfica radial para poder observar mejor cada componente

Carga 1:Lectura de Ficheros

Objetivos

Muchas veces la unica carga que soporta nuestro sistema es la de un antivirus ejecutandose como unico programa. Esto sucede en los Scan programados que deja nuestro antivirus para cuando el sistema está inactivo o si lo dejamos por la noche haciendo el Scan para poder detectar algún virus. La acción del Scan del antivirus es recorrer todos los archivos de nuestro disco duro comparando con ciertos patrones de la base de datos del antivirus y haciendo varias comprobaciones sobre el archivo leido, por lo tanto, como objetivo nos fijamos en que aumentaremos en gran medida la Lectura de Disco, la Cpu y caché se verán afectadas en una medida leve y la escritura se quedará en 0

Resultados

CPU Clock MHz	2.002	% Idle Pri Threads
% CPU	50,95%	% Idle	49,05%
CPUs Number	2	Queue for CPU	1
Processes	85	Threads	887
Thread Sw/s	2.561	HW Ints/s	2.284
Total Ph KB	3.006.396	Free Ph KB	1.822.792
		Stand By KB	1.871.712
File Cache KB	245.580	File cache peak KB	302.748
Free Virt KB	5.002.008	Committed KB	1.220.744
Paged Pool KB	119.960	NonPaged Pool KB	107.796
Max Swap KB	3.313.596	Swap in Use KB	100.088
Page Faults/s	2.127
Page Ins KB/s	1.498	Page Outs KB/s	0
File Read KB/s	167	File Write KB/s	0
File Reads/s	110	File Writes/s	0
Client Read KB/s	0	Client Write KB/s	0
Srv Transmit KB/s	0	Srv Receive KB/s	0

El archivo con los resultados que ha generado TaskInfo lo podemos encontrar aqui

Los resultados que a nosotros nos interesan han quedado asi:

Etiquetas	Estado Base	Estado Con Carga
% Uso CPU	13.5%	50,95%
Uso de Caché	241.228KB	245.580KB
Lectura en Disco	2KB/s	167KB/s
Escritura en Disco	0KB/s	0KB/s

Gráfico

Para poder ver una comparativa mucho más fiel y aclaradora voy a hacer 3 Gráficas, una para CPU, otra para Memoria y otra para Disco:

Análisis

Los resultados obtenidos cumplen los objetivos, como vemos la lectura no es intensa, es decir, utiliza una velocidad reducida pero esto se debe a que el antivirus debe hacer una comparativa y calculos sobre cada bloque de memoria y por tanto la velocidad que mantiene en la lectura se ve condicionada por ese fator, es por eso por lo que la CPU aumenta hasta el 50%, en cambio la caché no aumenta tanto porque utiliza un rango de bloques pequeño, el Scan de un antivirus utiliza sobre todo Disco y CPU para calculos y comparaticas con la BD del programa

Carga 2:Apertura de un Programa

Objetivos

Abrimos un programa grande para cargarlo en memoria principal, este comportamiento es el habitual de cualquier tipo de usuario, sobre todo de los sistemas de oficina donde uno de los programas que se abren son el Office. Nosotros vamos a usar NetBeans (es la versión con todos los extras), nuestro objetivo es aumentar en cierta medida la CPU (Esto es inevitable pues es quien ejecuta el programa), aumentar el uso de caché y aumentar la lectura de Disco (Pues el programa se encuentra grabado en disco y habrá que leerlo), la escritura permanecerá igual

Resultados de TaskInfo

CPU Clock MHz	2.261	% Idle Pri Threads
% CPU	93,81%	% Idle	6,19%
CPUs Number	2	Queue for CPU	5
Processes	91	Threads	943
Thread Sw/s	2.961	HW Ints/s	2.330
Total Ph KB	3.006.396	Free Ph KB	1.675.320
		Stand By KB	1.723.292
File Cache KB	279.460	File cache peak KB	302.748
Free Virt KB	4.868.928	Committed KB	1.353.824
Paged Pool KB	121.084	NonPaged Pool KB	108.168
Max Swap KB	3.313.596	Swap in Use KB	100.920
Page Faults/s	462
Page Ins KB/s	1.315	Page Outs KB/s	306
File Read KB/s	309	File Write KB/s	219
File Reads/s	326	File Writes/s	83
Client Read KB/s	0	Client Write KB/s	0
Srv Transmit KB/s	0	Srv Receive KB/s	0

El archivo con los resultados del programa lo podemos encontrar aqui

Como siempre, construimos nuestra tabla

Etiquetas	Estado Base	Estado Con Carga
% Uso CPU	13.5%	93,81%
Uso de Caché	241.228KB	279.460KB
Lectura en Disco	2KB/s	309KB/s
Escritura en Disco	0KB/s	0KB/s

Gráficos

Al igual que con la carga anterior, realizamos varios gráficos:

Análisis

Como vemos la lectura de disco es mucho más grande que con un Scan de un Antivirus, esto es lógico si pensamos que el antivirus está diseñado para trabajar en background intentando "hacer el mínimo ruido posible", es decir, intentando influir lo mínimo posible en el quehacer el usuario. En cambio aquí, se lee de forma mucho más rápida para poder abrir lo más pronto posible el programa porque el usuario lo necesita usar, por otro lado al ejecutarse el programa se necesitan hacer millones de cálculos y por lo tanto la CPU trabajará de forma superintensiva y por último es obvio que se usará bastante caché más pues el programa iniciado es un nuevo proceso y por lo tanto tiene su contexto que se necesita guardar en caché para poder usarse en tiempo de ejecución, al ser bastante grande el programa su caché va a ser proporcional y por eso consume lo que vemos en el gráfico. Por lo tanto el comportamiento es normal salvo por el grandisimo aumento de la cpu que está proxima al 100% y que induce a pensar que algo independiente de la carga en el sistema, está intercediendo

Carga 3: Ejecución de calculo intensivo

Objetivos

En nuestra carrera muchas veces hemos tenido que dejar nuestro ordenador calculando de forma intensiva alguna práctica en la que tarde más de 1 minuto, en esos casos lo más seguro esque no influya el Disco y tan solo la caché y la CPU, para someter al sistema a esta carga lo he expuesto a un programa con una función recursiva en el que en cada llamada hace raices cuadradas, elevaciones, sumas, divisiones, multiplicaciones y además en su recursividad su arbol se exitiende exponencialmente hasta alcanzar una altura de 20 ampliando cada nodo en cada nivel a 4 descendientes asi que tendría 4^20 nodos y además de todo esto, ejecuto el mismo programa 3 veces. Teoricamente debe ascender la CPU hasta un nivel insospechado y la caché (al ser recursiva debe ir creando nuevas variables por cada llamada)

Resultado de TaskInfo

CPU Clock MHz	2.253	% Idle Pri Threads
% CPU	100,00%	% Idle
CPUs Number	2	Queue for CPU	10
Processes	93	Threads	959
Thread Sw/s	2.319	HW Ints/s	2.182
Total Ph KB	3.006.396	Free Ph KB	1.589.056
		Stand By KB	1.638.504
File Cache KB	285.184	File cache peak KB	302.748
Free Virt KB	4.754.756	Committed KB	1.467.996
Paged Pool KB	119.872	NonPaged Pool KB	108.120
Max Swap KB	3.313.596	Swap in Use KB	101.864
Page Faults/s	517
Page Ins KB/s	0	Page Outs KB/s	0
File Read KB/s	21	File Write KB/s	0
File Reads/s	111	File Writes/s	0
Client Read KB/s	0	Client Write KB/s	0
Srv Transmit KB/s	0	Srv Receive KB/s	0

El archivo que da TaskInfo lo podemos ver aqui

Como siempre, construimos nuestra tabla

Etiquetas	Estado Base	Estado Con Carga
% Uso CPU	13.5%	100,00%
Uso de Caché	241.228KB	285.184KB
Lectura en Disco	2KB/s	21KB/s
Escritura en Disco	0KB/s	0KB/s

Gráficos

Al igual que con la carga anterior, realizamos varios gráficos:

Análisis

Vamos a analizar caso por caso, en caso de la CPU el cálculo intensivo le ha hecho entrar en sobrecarga y llegar al máximo de sus posibilidades relentizando el sistema entero en gran medida, este sistema no estaba preparado para este tipo de acciones o usos, a pesar de que el programa es bastante pesado el sistema donde ha sido ejecutado es bastante moderno y en teoria resiste estos cálculos (es más ha sido probado en XP y funciona mucho mejor) por lo tanto sospecho de la existencia de algo ejecutandose que no he contemplado (lo abordaré al final de la práctica). La caché, ha aumentado bastante (eso es muy lógico por los datos dados en objetivos) no obstante si lo comparamos con la carga de NetBeans es parecida, esto se debe a que NetBeans utiliza muchos recursos para el funcionamiento de todos módulos, y este programa los usa simplemente por ineficiencia. En cuanto a la lectura en Disco, como vemos es escasa comparado con las cargas anteriores porque el programa es muy pequeño y apenas ocupa espacio en disco

Prueba 4:Copiando Archivos

Objetivos

En la era en que corre todo sistema se ve sometido en algún momento a un uso de disco intensivo (Copiar peliculas, fotos, videos, canciones...) para ello he confeccionado esta carga, en ella copio varias peliculas de una carpeta a otra, para que sea un archivo grande he copiado tres peliculas que suman un total de 7 Gb, y además para asegurarme de que haya distancia en entre el lugar físico de ambas ubicaciones pego en otra partición, de esta forma se debería aumentar de forma muy considerable la lectura y escritura en disco, aunque ambas deberían ser aproximadas pues lo que se lee se escribe, por otro lado la cpu no debe de aumentar demasiado, y la caché seguramente si aumente por que tenemos que cargar en ella lo que vamos leyendo

Salida de TaskInfo

CPU Clock MHz	2.262	% Idle Pri Threads
% CPU	92,26%	% Idle	7,74%
CPUs Number	2	Queue for CPU	4
Processes	86	Threads	904
Thread Sw/s	9.790	HW Ints/s	2.546
Total Ph KB	3.006.396	Free Ph KB	1.553.412
		Stand By KB	1.680.008
File Cache KB	295.196	File cache peak KB	302.748
Free Virt KB	4.816.860	Committed KB	1.405.892
Paged Pool KB	128.920	NonPaged Pool KB	113.800
Max Swap KB	3.313.596	Swap in Use KB	107.596
Page Faults/s	10.707
Page Ins KB/s	11.797	Page Outs KB/s	8.143
File Read KB/s	12.324	File Write KB/s	12.144
File Reads/s	193	File Writes/s	219
Client Read KB/s	0	Client Write KB/s	0
Srv Transmit KB/s	0	Srv Receive KB/s	0

El archivo que da TaskInfo lo podemos ver aqui

Como siempre, construimos nuestra tabla

Etiquetas	Estado Base	Estado Con Carga
% Uso CPU	13.5%	92,26%
Uso de Caché	241.228KB	295.196KB
Lectura en Disco	2KB/s	12.324KB/s
Escritura en Disco	0KB/s	12.144KB/s

Gráficos

Al igual que con la carga anterior, realizamos varios gráficos:

Análisis

Cabe destacar en el análisis que a la hora de pronosticar el funcionamiento de la CPU este ha variado ligeramente y esque me esperaba que no aumentase tanto como lo ha hecho, aparte de los ya mencionados problemas de Vista con el consumo de cpu, he obviado el hecho de que la CPU puede estar calculando de forma intensiva direcciones de memoria, si el disco no esta defragmentado es muy posible que se produzca, y además está el hecho de que están en dos particiones diferentes por lo que se añaden más motivos al calculo de direcciones intensivo. Por lo demás es todo obvio y se ha cumplido de los objetivos, por lo que no requiere más explicación

Prueba 5:Multitud de Procesos ejecutandose Simultaneamente

Objetivos

El objetivo principal de esta carga es el aumento de la caché, por lo tanto, abrimos muchos procesos a la vez de forma que el cambio de contexto sea muy grande y además en caché necesitamos guardar por cada proceso un determinado espacio. Si ejecutamos todos los procesos(imagen inferior) deberiamos obtener una caché alta, cpu alta, pues está ejecutando procesos sin descanso uno tras otro, una lectura moderada alta, pues debe leer los archivos de todos los procesos que se están ejecutando y una escritura baja-nula, a no ser que algún proceso necesite escribir por alguna razón

Salida de TaskInfo

CPU Clock MHz	2.259	% Idle Pri Threads	1,95%
% CPU	98,05%	% Idle	1,95%
CPUs Number	2	Queue for CPU	14
Processes	96	Threads	1.011
Thread Sw/s	7.156	HW Ints/s	2.244
Total Ph KB	3.006.396	Free Ph KB	1.360.056
		Stand By KB	1.390.844
File Cache KB	331.216	File cache peak KB	332.692
Free Virt KB	4.555.556	Committed KB	1.667.196
Paged Pool KB	126.448	NonPaged Pool KB	113.940
Max Swap KB	3.313.596	Swap in Use KB	108.188
Page Faults/s	5.263
Page Ins KB/s	995	Page Outs KB/s	86
File Read KB/s	669	File Write KB/s	0
File Reads/s	117	File Writes/s	11
Client Read KB/s	0	Client Write KB/s	0
Srv Transmit KB/s	0	Srv Receive KB/s	0

El archivo que da TaskInfo lo podemos ver aqui

Como siempre, construimos nuestra tabla

Etiquetas	Estado Base	Estado Con Carga
% Uso CPU	13.5%	98,05%
Uso de Caché	241.228KB	331.216KB
Lectura en Disco	2KB/s	669KB/s
Escritura en Disco	0KB/s	0KB/s

Gráficos

Al igual que con la carga anterior, realizamos varios gráficos:

Análisis

Efectivamente como vemos en las gráficas se cumple lo dicho en los objetivos, la caché ha aumentado increiblemente, la CPU está muy cargada, la lectura de disco es alta y la escritura nula. Como se han cumplido las espectativas el análisis está implicito en los objetivos.

Problemas Surgidos en las Cargas

Dentro de cada análisis hemos podido observar que la CPU esta siempre bastante alta, incluso en un estado de reposo es del 13%, al hacer una exploración del sistema hemos visto que se trata del SO Windows Vista y por lo tanto es obvio que la CPU se mantenga alta hasta en reposo pero si observamos los análisis podemos deducir que hay tasas bastante altas de CPU incluso siendo Vista, lo que nos puede llevar a pensar que puede haber algún virus, spyware, malware... en el sistema y por lo tanto tendríamos que tratarlo

Pequeña Aclaración

Las escalas varían de una carga a otra por lo que no podemos hacer la compración de gráficas entre cargas a simple vista, hay que fijarse en la escala

Práctica 3: Diseño y Evaluación de Configuraciones :: Profiler

Profiler: NetBeans...Optimizando

Eleccion:

Voy a utilizar NetBeans porque a parte de ser Gratuito, Es de los pocos que ofrecen en el mismo IDE el profiler, ademas de ser muy completo y cómodo

Introducción:

Ante todo, he intentado no recurrir al tópico C o C++ para hacer el profiler asi que de primera pensé en PHP, no obstante no tuve mucho exito con ese lenguaje pues NetBeans no permite hacer Profiler a PHP, abandoné esta posibilidad y opté por algunas prácticas que tenía en Java, pero usaban RMI y me vi incapaz de ejecutarlas con el entorno NetBeans, por último y incapaz de abandonar asi como asi mi ganas de ser original investigue la posibilidad de crear código para movil con NetBeans pero tampoco contemplaba la opción de crear profiles, asi que me vi destinado a crear mi propio código en Java (Como he dicho abandoné desde un principio la idea de coger mis prácticas de C y C++), asi que cree todo el código que voy a mostrar en la práctica, con la ventaja de que al crearlo lo hice con el objetivo de mejorar un código hasta el orden constante.

Implementación

En principio el programa es bastante simple puesto que no es el objetivo de la práctica hacer un código muy pomposo sino entender y comprobar los profiler, asi que hice un programa en java que calcula muchas caracteristicas del número 29, cuadrado, raiz, 29^29, fibonacci...

Código: Clase Principal

/*  * To change this template, choose Tools | Templates  * and open the template in the editor.  */ package javaapplication2; /**  *  * @author Jesse  */ public class Main {     /**      * @param args the command line arguments      */               public static void main(String[] args) {         Calculos calc=new Calculos();         calc.setnumber(6);         int number=29;         int fibon=calc.fiboRecur(number),cuad,ele;         double raiz,dia;         System.out.println("El fibonacci de "+number+" es "+fibon);         cuad=calc.cuadrado(number);         System.out.println("El cuadrado de "+number+" es "+cuad);         raiz=calc.raiz(number);         System.out.println("La Raiz de "+number+" es "+raiz);         ele=calc.elevadoASiMismo(number);         System.out.println("El numero elevado a si mismo de "+number+" es "+ele);         dia=calc.diagonalCuadrado(number);         System.out.println("La diagonal del triangulo que forman dos lados de longitud "+number+" es "+dia);     } }

Código: Clase Calculos

/*  * To change this template, choose Tools | Templates  * and open the template in the editor.  */ package javaapplication2; /**  *  * @author Jesse  */ public class Calculos {     int number;     int fibos[]=new int[1000];     int ultimoCalculado=0;     public Calculos(int number){         this.number=number;     }     public Calculos(){         number=0;     }     public void setnumber(int number){         this.number=number;     }     public int fiboRecur(int numero){         //n=fibo(n-2)+fibo(n-1);         if(numero<2){            return numero;         } else{             return fiboRecur(numero-2)+fiboRecur(numero-1);         }     }         /*Esta funcion devuelve el cuadrado*/     public int cuadrado(int numero){         return numero*numero;     }         /*Esta funcion devuleve la raiz del numero*/     public double raiz(int numero){         return Math.sqrt(numero);     }     /*Esta funcion devuelve el numero elevado a si mismo*/     public int elevadoASiMismo(int number){         return (int) Math.pow((double)number,(double)number);     }     /*Esta funcion devolveria la diagonal del triangulo rectangulo formado      * por dos lados de la misma longitud: number*/     public double diagonalCuadrado(int number){         return Math.sqrt(Math.pow(number, 2)+Math.pow(number, 2));     } }

Ejecución del Programa

run:

El fibonacci de 29 es 514229

El cuadrado de 29 es 841

La Raiz de 29 es 5.385164807134504

El numero elevado a si mismo de 29 es 2147483647

La diagonal del triangulo que forman dos lados de longitud 29 es 41.012193308819754

Primer Profiler

Interpretamos el Profiler: En la imagen podemos ver los tiempos que tarda cada función del programa, lo que más resalta a la vista el el cuello de botella que produce la función fibonacci, porque tarda ella sola lo que tarda todo el programa entero, las demás son todas de orden constante luego va a ser muy dificil optimizarlas por lo que vamos a centrarnos en fibonacci: Si todo el programa tarda 3190ms fibonacci tarda 3188ms luego está claro el porqué de centrarnos en esa función

Función Fibonnaci

Como bien podemos ver en la imagen la función de fibonacci que tenemos es Recursiva y la calculamos asi fibo(n)=fibo(n-2)+fibo(n-1) con caso base n=1 y n=0, si observamos bien ese código podemos deducir que se repiten calculos (los que esten del mismo color) por ejemplo para fibo(24) que se repite varias veces en el arbol, luego podríamos mejorarlo si guardamos los resultados en un vector...

Segundo Profiler

Codigo: Fibonacci Recursiva con Guardado en Vector

public int fiboRecurMejorado(int numero){         //n=fibo(n-2)+fibo(n-1);         int fi=0;                  if(numero<2){            fi=numero;         } else if(ultimoCalculado>=numero){             fi=fibos[numero];         }else{             fi=fibos[numero]=fiboRecurMejorado(numero-2)+fiboRecurMejorado(numero-1);             this.ultimoCalculado=numero;         }         return fi;     }

Ejecucíon del profiler

Fibonacci en Concreto

En el podemos ver como se ha reducido bastante el tiempo de ejecución de fibonacci, de 3188ms a 0,307, ¡Más de 1000 veces menos!, y las invocaciones han descendido hasta un máximo de 4, no obstante sigue siendo una parte importante del programa y se puede seguir optimizando:

Tercer Profiler

Podemos intentar mejorar el fibonacci cambiando radicalmente la estrategia en la recursividad, esto lo hacemos de la siguiente forma:

• Comenzamos en el siguiente sistema de ecuaciones:


• 


• Este sistema se puede representar mediante su notación matricial como:


• 


• Conociendo a f0 = 0 y f1 = 1, al aplicar la fórmula anterior n veces se obtiene:


• 


• y más aún


• 


• Pasamos a Implementarlo

Codigo: Fibonacci Matricial

public int fiboMatricial(int numero){          int matrix[]=fiboAuxMatricial(numero);          return matrix[2];     }     public int[] fiboAuxMatricial(int num){         if(num==1){             int matrixF[]=new int[4];             matrixF[0]=0;             matrixF[1]=1;             matrixF[2]=1;             matrixF[3]=1;             return matrixF;         }else{             if(num%2==0)                 return multiRaices4(fiboAuxMatricial(num/2),fiboAuxMatricial(num/2));             else                 return multiRaices4(multiRaices4(fiboAuxMatricial(num/2),fiboAuxMatricial(num/2)),fiboAuxMatricial(1));         }     }  public int[] multiRaices4(int[] m1,int[] m2){         int aux[]=new int[4];          aux[0]=m1[0]*m2[0]+m1[1]*m2[2];          aux[1]=m1[0]*m2[1]+m1[1]*m2[3];          aux[2]=m1[2]*m2[0]+m1[3]*m2[2];          aux[3]=m1[2]*m2[1]+m1[3]*m2[3];         return aux;     }

Profiler

Como vemos no hemos mejorado nada, es más hemos empeorado asi que tenemos dos opciones, o la descartamos o la analizamos al máximo para ver los posibles fallos: Opto por la segunda.
Analizandola podemos ver una optimización bastante buena y es que en el codigo actual ejecutamos dos veces la funcion recursiva del mismo numero, pudiendo ejecutarla una vez y almacenarla en una variable, asi que lo hacemos:

Cuarto Profiler

Codigo: Fibonacci Matricial Mejorado

public int fiboMatricialMej(int numero){          int matrix[]=fiboAuxMatricialMej(numero);          return matrix[2];     }     public int[] fiboAuxMatricialMej(int num){         if(num==1){             int matrixF[]=new int[4];             matrixF[0]=0;             matrixF[1]=1;             matrixF[2]=1;             matrixF[3]=1;             return matrixF;         }else{             int matrizaux[]=fiboAuxMatricial(num/2);             matrizaux=multiRaices4(matrizaux,matrizaux);             if(num%2==0)                 return matrizaux;             else                 return multiRaices4(matrizaux,fiboAuxMatricial(1));         }     }

Java2html

Profiler

Ahora si que mejoramos lo anterior, ya solo tardamos 0,259 ms, no obstante sigue siendo una parte importante de nuestro programa y puede ser optimizada, podemos probar a hacerla iterativa, porquqe de forma iterativa consume menos recursos y tal vez podamos optimizar la función...

Quinto Profiler

Código: Fibonacci Iterativo

public int fibo(int numero){         int devuelto=0,aux1=1,aux2=0;         for(int i=1;i<numero;i++){             devuelto=aux1+aux2;             aux2=aux1;             aux1=devuelto;         }         return devuelto;     }

Profiler

De forma completamente inesperada el fibonacci iterativo arrasa con todo y tarda 0,003ms menos incluso que un sqrt, pow e incluso la inicialización de la clase, tal vez mi ordenador "digiera" mejor las sumas iterativas que los cuadrados y raices.
Podemos seguir intentado mejorarla, asi que vamos a proceder a hacer el fibonacci de orden constante que aunque en esta situación seguro que no desbanca al iterativo( porque se usan raices y cuadrados) en numeros de orden muy superior, lo desbancará seguro:

Sexto Profiler

Código: Fibonacci Constante

public int fiboConst(int numero){         double raiz5=Math.sqrt(5);         return (int)((1/raiz5)*Math.pow(((1+raiz5)/2),numero)-(1/raiz5)*Math.pow(((1-raiz5)/2),numero));     }

Profiler

Muy buen resultado: 0,96ms. Como vemos es peor que el anterior pero usando la proporción aurea podemos conseguir el orden constante y tardar 0,096ms (o un poquito mas) para cualquier número, la unica formula que hay que aplicar es esta: