Página de la asignatura
Tema siguiente
Página del profesor

ETSIIT: Diseño y Evaluación de Configuraciones:

1. Sistemas Informáticos y su Evaluación

Los sistemas informáticos son el objeto de estudio de esta asignatura, y, como es natural, de toda la carrera. Denominamos sistema informático a cualquier sistema que use medios informáticos. Suena redundante, pero así podemos abarcar, por ejemplo, todos los diferentes sistemas situados en diferentes niveles del modelo de capas OSI: desde la más baja, la física, hasta la más alta, la de aplicación; también a las diferentes capas de un sistema operativo. Desde el punto de vista de esta asignatura, un sistema puede ser tanto un chip, como una tarjeta de red, como una red completa, como un programa que ofrezca servicios en esa red, como el programa junto con todo el sistema necesario para ejecutarse.

Durante el ciclo de vida de un sistema informático, resulta muchas veces necesario evaluar sus prestaciones o rendimiento, habitualmente con el objetivo de mejorarlas o bien de comparar diversos sistemas informáticos entre sí. Esa evaluación de prestaciones se debe hacer de forma objetiva, para que puedan compararse diversos valores a lo largo del tiempo o bien los valores para diversos sistemas informáticos. Tales mediciones pueden servir también para identificar los problemas que tiene un sistema informático, con el objetivo de solucionarlos.

En concreto, se necesitará evaluar objetivamente las prestaciones de un sistema informático a lo largo de las siguientes fases de su ciclo de vida:

Los objetivos de una evaluación suelen ser alguno de los siguientes:

Hay otros sistemas operativos: OS X, el sistema operativo de los Apple iMac, los sistemas operativos de los grandes mainframes: OS/390, por ejemplo. Sin embargo, Unix/Linux y WindowsNT/2K/XP/Vista copan el 90%, o quizá más, de los servidores actuales.
También están los diferentes miembros de la familia BSD: NetBSD, FreeBSD, y OpenBSD; otros Unix gratuitos, no tan extendidos, ni tan fáciles de instalar como Linux, pero que, como suele suceder, tienen un grupo de adeptos bastante fuerte. En el caso del OpenBSD, se pone énfasis en la seguridad; mientras que en el caso del NetBSD, se trata de potenciar sobre todo la portabilidad.

Los sistemas de referencia que se van a usar serán habitualmente ordenadores con el sistema operativo UNIX (que es multiusuario y multiproceso). Aunque en general todos los UNIX son bastante similares, es decir, funcionan en todos las mismas órdenes (porque todos usan el mismo grupo de intérprete de comandos) y librerías, hay sutiles diferencias entre los dos tipos principales de UNIX, los System V, y los BSD; sin embargo, hoy en día, el UNIX más extendido, con mucho, es Linux (en sus diferentes distribuciones), seguido de lejos por Solaris, la versión de Sun, o sea que, a estas alturas de la película, las diferencias no importan tanto.

En esta asignatura se tratará también con otro de los sistemas operativos más usados en la actualidad, Windows NT/2K/XP. En este caso, se trata de un sistema operativo multiproceso, multihebras, y, en el caso de XP, multiusuario.

  1. Mencionar sistemas operativos que no estén entre los anteriores, y el nicho de mercado que suelen cubrir.

En cualquier caso, el SO es sólo uno de los componentes de un ordenador, que se compone de muchos subsistemas diferentes, tanto software, como hardware, y todos interaccionan entre sí para dar el resultado que observa un usuario. El procesador, los diferentes elementos de la jerarquía de memoria, el sistema operativo, compiladores, la cantidad de usuarios, todos tienen un impacto en las prestaciones del sistema. En concreto, los sistemas con los que trabaja el ordenador se pueden dividir de la forma siguiente:

Aproximación pachanguera al análisis de prestaciones

A pesar de la sabiduría y la ciencia que se encuentra en el análisis de prestaciones, lo más habitual es que poca gente le haga caso, salvo que se estén jugando muchos cuartos. Lo más normal es usar alguna de las opciones siguientes

En el caso de un sistema monousuario, que es lo más habitual entre el alumnado de esta asignatura, también es necesaria la evaluación de prestaciones con el objeto de aprovechar al máximo las posibilidades del hardware; la mayoría de los sistemas operativos serios ofrecen una serie de posibilidades de medición y sintonización, que se deberán de aprovechar, como se tratará en el tema 3; en el caso de un sistema informático compuesto por una red con varias decenas de recursos, periféricos, usuarios, y que se use las 24 horas del día, y en el cual la adquisición de un nuevo componente sea un proceso largo y costoso, será imprescindible evaluar los problemas del sistema para poder dar una solución.

Una primera aproximación a la medición de prestaciones son las ofrecidas por el fabricante de cada uno de los componentes del ordenador. Un ordenador con una tarjeta de vídeo rápida será habitualmente más rápido que otro con la tarjeta de vídeo más lenta, o con más memoria (al tener más memoria, hay que transferir más información en cada instante, y por tanto hace más lento el sistema), si todos los demás componentes son iguales. Pero ¿habría mucha diferencia de velocidad, si la velocidad es lo que importa, entre una tarjeta rápida con mucha memoria y otra lenta con menos memoria? ¿Como influiría en eso la velocidad del microprocesador? ¿Y el tipo de bus al que se conecta la tarjeta? Todas esas preguntas y muchas más, tratarán de responderse a lo largo de la asignatura.

Algunas características de los Unix (incluyendo Linux)

Todos los servicios que ofrece un sistema como UNIX están administrados a través de daemons. Los daemons son programas, cuyo nombre normalmente acaba en d, que administran un servicio determinado, como ftp o telnet. Durante el funcionamiento normal del sistema, hay muchos daemons funcionando; se suelen iniciar al arrancar el sistema.

Por ejemplo, dado que UNIX es un sistema operativo de red, existe un método de hacer disponibles los sistemas de ficheros (filesystems) locales a toda la red, que se denomina NFS, o network filesystem. Este NFS permite a cualquier ordenador en la red acceder a los demás discos duros puestos a su disposición como si se tratase de directorios locales, es decir, que existe un solo sistema de ficheros en toda la red.

Otros sistemas de ficheros distribuidos son SMB/Samba y CodaFS, usado sobre todo en sistemas de alta disponibilidad.

Normalmente hay una persona o personas dedicadas a la administración de un sistema UNIX, los denominados superusuarios o administradores del sistema. Estas personas tienen privilegios para hacer cosas que habitualmente no tienen los demás usuarios.

Todas las órdenes de UNIX tienen una página de manual; estas páginas están distribuidas en diferentes secciones, que se suelen indicar entre paréntesis después del nombre del comando. Las secciones relevantes a la evaluación de prestaciones de sistemas son la 4 o 7 (formatos de fichero) y 1m u 8 (administración del sistema).

En este capítulo, veremos primero qué fases se siguen en la evaluación de un sistema informático (en la sección 1.2); posteriormente se verá (en la sección 1.3) qué es lo que se debe medir y qué tipos de magnitudes hay; a partir de ahí examinaremos qué técnicas (1.4) se usan para la medición de prestaciones de un sistema informático, comenzando con la carga del sistema (sección 1.5).

  1. Indicar qué tipo de medidas sueles tomar para medir las prestaciones de un ordenador.
  2. Indicar en qué casos de los que te encuentras en tu trabajo (u otro quehacer) diario necesitarás medir las prestaciones del ordenador.
  3. Indicar en qué casos percibes una falta de prestaciones de los ordenadores que sueles manejar.
  4. Mirar qué servicios hay activos en nuestro ordenador personal y en algún otro ordenador al que tengamos acceso. ¿Qué usas para saber los servicios que hay activos? ¿Sabes lo que hacen? ¿Si suprimes alguno de ellos, qué pasa?

Para que se vea lo que tienen que sufrir los informáticos, y especialmente los administradores de sistemas que se tienen que dedicar, entre otras cosas, a solucionar los problemas de los demás, es interesante consultar la Pringao-HOWTO y la tabla de los 30 sentimientos de un informático. Lo que hace que a veces se comporten como el operador bastardo del infierno.

Durante la evaluación de cualquier sistema informático, hay que seguir las siguientes fases:

  1. Especificar los objetivos y definir el sistema: una medición de prestaciones no tiene sentido sin objetivos. Se debe de definir claramente cuál es el sistema además, para medir exclusivamente eso. Es decir, si se quieren medir las prestaciones de la memoria de un sistema, hay que aislar lo que pertenece a ella, y eliminar en lo posible de la medición la influencia de todos los demás factores.
  2. Hacer una lista de los servicios que ofrece el sistema y sus posibles resultados: es decir, un sistema puede dar un resultado válido, inválido o simplemente no dar ningún resultado, en cualquier caso, habrá que medir la tasa de sucesos de uno u otro tipo.
  3. Seleccionar las métricas, es decir, los criterios para comparar prestaciones.
  4. Listar los parámetros que pueden afectar a las prestaciones, que se dividen entre las características del sistema, y la carga de trabajo a la cual está sometido; las primeras no varían para todos los sistemas que tengan el mismo hardware; pero la segunda varía entre diversas instalaciones.
  5. Factores a estudiar; de los parámetros anteriores, algunos se variarán durante el estudio, los denominados factores. Los diferentes valores que tomarán durante el estudio se denominan niveles.
  6. Seleccionar las técnicas de evaluación: entre la modelización, simulación y medición de un sistema real. La selección de la técnica dependerá del tiempo y el dinero disponibles, aunque lo más habitual es que se lleven a cabo benchmarks.
  7. Seleccionar la carga de trabajo, es decir, la carga a la que se va a someter el sistema para medirlo. Siempre se hará en función de los objetivos establecidos; en particular si el objetivo es mejorar las prestaciones para una carga determinada.
  8. Diseñar los experimentos, dividiéndolos en niveles o valores que tomarán los factores. Inicialmente, se suele diseñar un experimento con muchos factores, pero pocos niveles, para, una vez vistos cuáles son los factores que influyen más en el experimento, concentrarse en esos.
  9. Analizar e interpretar los datos; no basta con medir, sino que hay que sintetizar los datos de las medidas, y extraer conclusiones de ellos. Esto se verá principalmente en el Tema 2 y el último tema.
  10. Presentar los resultados: lo cual es muy importante, tanto si se presenta a una clase como si es a un gerente que debe de tomar una decisión sobre qué comprar. Llegados a este punto, puede ser necesario comenzar otra vez el estudio desde el principio, porque es bien conocido que los objetivos de un estudio siempre varían durante la realización del mismo.

Cualquier estudio de rendimiento de un sistema deberá seguir explícitamente estos pasos, aunque algunos de ellos podrán evitarse en casos particulares. A lo largo de la asignatura trataremos cada uno de los pasos por separado, y qué metodología y técnicas se usan habitualmente.

  1. Especificar en qué consistirían los 10 pasos de la sección 1.2 en el caso de la evaluación de alguno de los siguientes sistemas: un compilador, un proveedor de servicio ADSL, una tarjeta gráfica, una impresora.

Para cada estudio, hay que decidir qué conjunto de criterios para la evaluación de prestaciones o métricas van a usarse; en concreto, nos referimos a la fase 3 de la sección donde se describen las fases en la evaluación de un sistema informático. Se puede empezar listando los servicios dados por el sistema; para cada petición, hay tres respuestas posibles:

En caso de que se haya llevado a cabo correctamente, las prestaciones se miden por el tiempo que se ha tardado en realizar la petición, la tasa a la cual el servicio ha sido realizado, y los recursos consumidos mientras se lleva a cabo el servicio, es decir, tiempo/tasa/recurso; estas tres métricas se denominan también responsividad, productividad y utilización.

Por ejemplo, para una pasarela de red (gateway), la responsividad se mide por su tiempo de respuesta, es decir, el tiempo entre la llegada y la salida de un paquete; su productividad por el número de paquetes que procesa por unidad de tiempo, y su utilización el porcentaje en que los recursos se usan en una unidad de tiempo determinada. Fijaros por ejemplo en estas mediciones de carga de La Fonera.

Todas estas métricas miden, en resumen, la velocidad. Los dos segundos casos se resumen en la fiabilidad y la disponibilidad del sistema. Cada servicio que ofrece un sistema debe de tener una serie de métricas de velocidad, fiabilidad y disponibilidad. Por ejemplo, la fiabilidad se puede medir en tiempo medio entre fallos (MTBF, mean time between failures), y la disponibilidad en el número de horas al año que no está disponible debido a un fallo. Generalmente, estos factores son difíciles de evaluar, y habitualmente se considera en vez de ello las garantías del fabricante. A veces se habla de disponibilidad cinco nueves, para indicar que el sistema está disponible el 99.999%.

Los tres criterios que se suelen seguir para elegir un subconjunto de todas las métricas suelen ser: variabilidad baja (para que no haya que repetir las mediciones muchas veces), que no haya redundancia (que no haya métricas que dependan unas de otras), y complitud (que definan de forma completa las prestaciones de un sistema).

Ejemplo: Medir las prestaciones de diferentes tarjetas gráficas

Básicamente, el servicio que ofrecen es dibujar: textos, gráficos, polígonos, texturas, movimiento de bloques de bits. En este caso es poco probable que se den métricas del tipo fiabilidad y disponibilidad (si no funciona, se devuelve), pero en cuanto a la velocidad, se pueden considerar: velocidad de dibujo y relleno de polígonos, velocidad de dibujo de tipos de letras diferentes, velocidad de descompresión MPEG (si ofrece ese servicio), velocidad de polígonos OpenGL, velocidad en Direct3D, velocidad de dibujo de texturas. ¿Qué métricas se podrían elegir? Byte, en febrero de 1997, usó una serie de tests para 2D, usando programas comerciales, y los programas Viewperf para medir prestaciones en OpenGL y Tunnel para Direct3D. Los tiempos se usaron para generar un índice. Dado que hay tarjetas optimizadas para uno de los dos entornos, lo mejor es compararlos en ambos, y además en el caso más normal, es decir, 2D.

También se pueden usar como medida métricas de nivel más alto: texels o frames por segundo, aunque hay que tener en cuenta que ambos tipos de medidas se referián a una aplicación en particular.

Un par de comparativas recientes: esta en LegionHardware, una de tarjetas económicas en The Tech Report y ésta en TodoReviews

Las métricas de prestaciones se suelen clasificar de la forma siguiente:

  1. Indicar las métricas que se usarían, y de qué tipo son (más-es-mejor, menos-es-mejor, nominal-es-mejor), en los siguientes sistemas: tarjeta gráfica, impresora, programa servidor web, ordenador servidor web .

Este apartado correspondería al punto 6 de la sección de evaluación de fases de un sistema informático; hablaremos de las técnicas más habituales usadas para evaluar un sistema, que son las siguientes: medición, modelado y simulación.

La medición consiste en tomar medidas directamente sobre el sistema en el que uno está interesado, usando también la carga adecuada, o bien una parte de la misma, que es lo que se suele denominar, en general, carga sintética.

Cuando se trata de evaluar un sistema incompleto, o que no se ha construido aún, hace falta construir un modelo analítico del mismo, es decir, usando fórmulas y ecuaciones diferenciales, tratar de hallar a partir de los valores conocidos o estimados de ciertos parámetros, los valores de los que nos van a interesar.

Por último, se puede simular el sistema, usando algún lenguaje de simulación, como el SIMULA, o cualquier otro lenguaje orientado a objetos con las herramientas gráficas adecuadas o usando sistemas de simulación tales como Simics o Bochs. Generalmente se usa simulación antes de construir un sistema, especialmente cuando se construyen nuevos microprocesadores, y se basa su estudio en las versiones anteriores de los microprocesadores. Para ello se suelen usar máquinas masivamente paralelas o superordenadores. Por ejemplo, la empresa VirtuTech creó un simulador llamado VirtuHammer para simular uno de los últimos procesadores de AMD, los Claw/SledgeHammer; también ofrece una licencia de su producto Simics gratuita para uso académico.

El clásico 99 bottles of beers on a wall se escribiría en simula de la siguiente forma:

BEGIN
  COMMENT
     Simula version of 99 beers
     Maciej Macowicz (mm@cpe.ipl.fr)
     Status: UNTESTED :)
  ;
  INTEGER bottles;

  FOR bottles:= 99 STEP -1 UNTIL 1 DO 
  BEGIN
    OutInt(bottles,1);
    OutText("bottle(s) of beer on the wall, ");
    OutInt(bottles,1);
    Outtext("bottle(s) of beer");
    OutImage;
    Outtext("Take one down, pass it around, ");
    OutInt(bottles,1);
    OutText("bottle(s) of beer on the wall, ");
  END;
  OutText("1 bottle of beer on the wall, one bottle of beer."); 
  Outimage;
  OutText("Take one down, pass it around, no more bottles of beer on the wall");
  OutImage
END    
Hay implementaciones gratuitas de Simula tales como esta. Sin embargo, no se puede decir que sea precisamente un lenguaje popular.

El problema en cada caso es qué técnica usar. La mayoría de las veces se recurre a la medición: las herramientas existen ya, y sólo hay que aplicarlas a nuestro sistema; sin embargo, si el sistema no existe, la única forma de medir sus prestaciones es mediante simulación y modelización.

En cuanto al tiempo que se tarda en obtener resultados, lo más rápido es usar un modelo analítico: simplemente se aplican ecuaciones; las mediciones tardan un poco más (sobre todo, teniendo en cuenta la variabilidad de las cargas de trabajo durante el tiempo); por último, la simulación es lo más lento, pues hay que diseñar y escribir un programa y evaluar los resultados.

En cuanto a la exactitud, por supuesto, realizar mediciones sobre el propio sistema da el resultado más exacto (siempre que se mida lo correcto, y se extrapolen correctamente), seguido por la simulación, ya que en ella se ponen casi todos los elementos del sistema real, y por último, el modelo analítico, porque requiere gran cantidad de suposiciones. También habría que tener en cuenta el coste (normalmente la medición es bastante cara), y, por supuesto, lo vendibles que son los resultados (en este caso, lo mejor son mediciones).

  1. Buscar sistemas gratuitos de simulación, especialmente para hardware.

Dado que la medición es el sistema más habitual de análisis de prestaciones, suele haber herramientas genéricas para hacerlos. Generalmente, este tipo de mediciones son previas al análisis de un sistema informático, antes incluso de establecer los objetivos de su análisis: hay que conocer qué es lo que está haciendo realmente el sistema, como trabajan sus diferentes subsistemas, y si se puede identificar algún tipo de problema.

Para medir la utilización de sistemas informáticos se usan los denominados monitores, que son herramientas de medición que permiten seguir el comportamiento de los principales elementos de un sistema informático cuando éste se halla sometido a una carga de trabajo determinada. En el caso de ordenadores personales o estaciones de trabajo son habitualmente programas, que o bien están incluidos en la distribución del sistema operativo (UNIX, Windows NT/2000/XP), o son utilidades externas (Windows 95/98); también pueden ser fragmentos de código unidos a un programa, como en el caso de los profilers de aplicaciones, o aparatos de medición, como en el caso de los monitores de prestaciones de la red.

Aunque durante la historia de la informática se han utilizado muchos tipos de monitores, los más habituales hoy en día son programas destinados a evaluar un sistema informático completo o una parte del mismo, y programas o aparatos de medición para medir las prestaciones de una red de ordenadores.

Según la forma como miden las prestaciones, los monitores se denominan de eventos o acontecimientos, que se activan cada vez que sucede un proceso determinado en el ordenador (como leer de disco, por ejemplo), o de muestreo. Los segundos son los más habituales, se activan a intervalos de tiempo fijos, o aleatorios. Lo importante de los monitores es que introduzcan poco overhead, es decir, que interfieran poco en el funcionamiento del sistema; los primeros, en general, interfieren mucho más que los segundos. Un monitor, además, los monitores pueden funcionar en tiempo real o en modo batch, según presente los resultados durante su ejecución o al final. Según la presentación de los resultados, también pueden ser monitores gráficos o basados en texto.

La mayoría de las veces, los monitores incluyen dos partes: un cliente y un servidor, sobre todo en el caso de los monitores gráficos. La parte cliente interroga a los servidores, que pueden ejecutarse en la máquina local o en otra máquina, y presenta los datos en forma gráfica, bien mediante diagramas de barras que indican porcentajes de utilización o mediante strip charts, es decir, diagramas temporales que representan en abscisas el tiempo y en ordenadas la utilización del recurso.

En cuanto a los monitores software, hay también principalmente dos tipos: profilers, o programas pegados a otros que miden sus prestaciones, y programas que miden el estado de un sistema. Se verán a continuación.

Los profilers son trozos de código linkados a un programa, y que son llamados cada cierto tiempo. Habitualmente, hay que instruir al compilador para que incluya esta opción de profiling. Estos fragmentos de programa generan un fichero, que es luego analizado por otros programas; el análisis muestra el tiempo empleado en cada una de los procedimientos de un programa y el número de veces que se ha llamado, de forma que el hábil programador pueda optimizar esos procedimientos. Esto puede tener un gran impacto en las prestaciones del programa; si un programa que tarda normalmente 10 segundos en ejecutarse se tira el 50% del tiempo en un procedimiento determinado, y, mediante alguna hábil técnica de optimización, conseguimos reducir el tiempo empleado en ese procedimiento a la mitad, habremos logrado que el programa tarde en ejecutarse solo 7.5 segundos, un 25% menos. Para hacer eso hay diversas técnicas, algunas de las cuales se muestran en Programming Pearls.

Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 12.26 0.19 0.19 837698 0.00 0.00 eoRng::uniform(double) 7.10 0.30 0.11 1095925 0.00 0.00 vector<bool, __default_alloc_template<true, 0> >::begin(void) const 7.10 0.41 0.11 907355 0.00 0.00 vector<bool, __default_alloc_template<true, 0> >::size(void) const 7.10 0.52 0.11 41897 0.00 0.01 __copy_d__H3Z20__bit_const_iteratorZ14__bit_iteratorZi_X01T0X11PX21_X11 5.16 0.60 0.08 778944 0.00 0.00 __ml__C20__bit_const_iterator 4.52 0.67 0.07 931658 0.00 0.00 __ml__C14__bit_iterator 4.52 0.74 0.07 701600 0.00 0.00 eoRng::flip(float) 3.87 0.80 0.06 910452 0.00 0.00 __pp__14__bit_iterator 3.87 0.86 0.06 837698 0.00 0.00 eoRng::rand(void) 3.23 0.91 0.05 1710602 0.00 0.00 __bit_reference::__bit_reference(unsigned int *, unsigned int) 3.23 0.96 0.05 990533 0.00 0.00 __mi__C20__bit_const_iteratorG20__bit_const_iterator 3.23 1.01 0.05 912052 0.00 0.00 __bit_iterator::bump_up(void) 3.23 1.06 0.05 673552 0.00 0.00 __bit_const_iterator::bump_up(void) 3.23 1.11 0.05 40000 0.00 0.01 eoBitMutation<eoBit<double> >::operator()(eoBit<double> &) 2.58 1.15 0.04 1027694 0.00 0.00 __opb__C15__bit_reference 2.58 1.19 0.04 81096 0.00 0.00 EO<double>::operator<(EO<double> const &) const 1.94 1.22 0.03 2045477 0.00 0.00 __bit_const_iterator::__bit_const_iterator(__bit_iterator const &)

Ejemplo de listado generado por un profiler en Linux para un programa que implementa un ejemplo de algoritmo genético. En este caso, la rutina que más tiempo consume es la de generación de números aleatorios, que además aparece varias veces dentro del listado. Esto es bastante habitual en muchos programas. En todo caso, el tiempo empleado no es muy alto, alrededor del 12%, por lo tanto no merece mucho la pena mejorar la velocidad de esas rutinas, pues tendrán una incidencia mínima en las prestaciones totales del programa.

Evidentemente, para sacar partido de estas técnicas hace falta tener el código fuente para que los nombres de los procedimientos puedan ser leídos por el profiler. Algunos sistemas operativos (tales como el SysV) incluyen también depuradores de kernel. SGI ha desarrollado un sistema para Linux llamado kernprof, que se aplica como un parche al kernel; las medidas se pueden examinar luego con una utilidad de línea de comandos con el mismo nombre.

Para usar un profiler en diferentes sistemas operativos y con diferentes compiladores, hace falta lo siguiente:

Algunos profilers también hacen tests de cobertura, es decir, un examen de qué ramas ha sido las que ha tomado el programa y qué parte del código no se ha usado nunca. Pueden servir para eliminar ramas muertas del programa.


1. Buscar y usar un profiler sobre un programa propio, en el lenguaje de programación que sea. Indicar qué es necesario para usarlo, y, una vez aplicado sobre un programa, decir qué mejoras se pueden hacer sobre el mismo.

La medición de diversas magnitudes relacionadas con el funcionamiento de un sistema, como las que se verán a continuación, es necesaria tanto para detectar los problemas que afectan al sistema como para evaluar los resultados de un benchmark:

Antes de intentar mejorar las prestaciones de cualquier sistema, es decir, hacerlo más rápido (al menos en algún aspecto), hay que saber en qué invierte el tiempo el sistema. Para medir el tiempo que tarda en ejecutarse un programa, una de las medidas básicas de las prestaciones de cualquier sistema, se puede ejecutar una utilidad tal como /bin/time, /usr/bin/time o timex (para diferenciarlos del time que es parte del intérprete de comandos), que son el equivalente en las dos versiones del sistema operativo; y que son diferentes a una función del shell, también llamada time. Esta utilidad, usada así, da los siguientes resultados (para el mismo programa al que le hicimos el profiling anteriormente):

3.63user 0.02system 0:03.75elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (171major+33minor)pagefaults 0swaps

Lo cual significa lo siguiente: el programa ha tardado 3.75 segundos reales, desde que se ha tecleado Enter hasta que ha salido la línea de comandos de nuevo; pero de esos 3.75 segundos, en realidad sólo 3.63 + 0.02 ha estado en la CPU; el resto del tiempo ésta no le ha hecho caso. Y además, 0.02 segundos son tiempo de sistema, es decir, tiempo invertido en ejecutar llamadas del programa al kernel, y código de UNIX en general. Sólo 3.63 segundos ha estado realmente ejecutando código del usuario; y este es el que está bajo su control completo. El resto es información sobre lo que el programa ha leido y escrito, los fallos de página, y las veces que ha tenido que ser enviado al espacio de swap.

Desde el punto de vista de la sintonización del sistema y la mejora de prestaciones, la diferencia entre tiempo usuario+sistema y tiempo total está totalmente fuera de control del usuario, ya que depende de lo que todo los demás estén haciendo (aunque siempre puede chivarse al superusuario y que los echen a todos), así que veremos en qué consiste el tiempo de usuario+sistema:

Ejemplo: ¿A qué dedica su tiempo la internet?

Pues, como sistema complejo que es, el tiempo que tarda en presentarse una página Web, es decir, desde que metemos el URL en el cuadrito y aparece "Done" en la parte baja del nevegador, se invierte a muchas cosas diferentes:

Como se ve, en todo esto el usuario tiene poco control, salvo en el primer paso, es decir, elección del proveedor y cómo se accede a él, y en el último, presentación, en el resto, lo único que se puede hacer es comprarse una internet nueva.

Los siguientes programas son útiles para monitorizar la actividad del sistema, o ayudan a preparar un sistema para ser monitorizado, aunque no sean monitores en sí. En mi carpeta BackFlip de monitores se coloca periódicamente información sobre programas de monitorización (aunque hace un par de añillos que no se añade nada).

Monitor de tareas WinNT Monitor de tareas WinNT

Otros programas sirven para evaluar las prestaciones de una red; o al menos los retrasos que la red introduce en las prestaciones de un ordenador.

[Desktop GNOME con varios
applets para medición de prestaciones]
En esta imagen se pueden ver, empezando arriba a la izquierda y en sentido de las agujas del reloj:

En general, cada sistema operativo viene con multitud de programas de monitorización de la carga del sistema, algunos de ellos en forma de pequeñas aplicaciones (applets) que pueden tenerse siempre ejecutándose (por ejemplo, en la barra de Gnome o en la barra de estado del XEmacs). Es conveniente echar un vistazo a las descripciones de los programas del sistema operativo, a ver cuál es la más conveniente; también conviene mirar en sitios web de distribución de aplicaciones gratuitas, tales como Freshmeat o TuCows.También en en el manual de WinXP vienen una serie de instrucciones para dejar instalado y configurado el WinNT (que para WinXP servirá también, supongo). En cuanto a otros sistemas operativos, en este documento de Sun explica como configurar y usar la orden sar.

Por ejemplo, se puede usar el programa vmstat para analizar la actividad de un sistema, de la forma siguiente:
Evaluación y modelado del rendimiento de los sistemas informáticos, de Xavier Molero, Carlos Juiz, Miguel Jesús Rodeño, Madrid : Pearson Educación, 2004. Ficha en la biblioteca de la UGR. Puedes ver su ficha en la editorial y comprarlo online. Especialmente relevante para este tema es el capítulo 2 del libro.
Portada del libroSystem Performance Tuning, de Mike Loukides, O'Reilly, un libro un tanto obsoleto, pero que contiene todas las técnicas básicas para analizar las prestaciones de los diversos subsistemas de un ordenador: memoria, disco, red. Desde la red de la Universidad de Granada (y cualquier otra red que tenga acceso) puedes acceder a la versión online del libro, a través del servicio Safari de O'Reilly. En el mismo sitio hay enlaces a otros artículos del mismo autor sobre el mismo tema.
Específicamente para el lenguaje Java, se puede consultar Portada del libroJava Performance Tuning, second edition, de Jack Shirazi, un libro concentrado, como es natural, en Java, en cómo incrementar las prestaciones de la máquina virtual y en cómo mejorar los programas escritos en Java . Desde la red de la Universidad de Granada (y cualquier otra red que tenga acceso) puedes acceder a la versión online del libro (de la primera edición); el capítulo 2 es el más relevante para la asignatura.
Portada del libroProgramming Pearls, de Jon Bentley, Addison Wesley, 1989. Colección de las columnas publicadas por el autor en Communications of the ACM, son una colección de técnicas y trucos utilizables para programar en cualquier lenguaje y ordenador.
Portada del libroThe art of computer systems performance analysis: Techniques for experimental design, measurement, simulation and modelling, Raj Jain, Wiley, 1992. Está un tanto obsoleto; sin embargo, tiene un enfoque ameno y completo al problema del análisis de prestaciones.
Portada del libroWeb Performance Tuning: Speeding Up the Web (O'Reilly Nutshell) by Patrick Killelea, Linda Mui; un libro un tanto básico; se concentra demasiado en cosas como aumento de las prestaciones del cliente, pero no está mal del todo. También puedes acceder a él dese Safari (pero a la primera edición, y no completa).

Valid HTML 4.01 Transitional

Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons. Realizado por
Juan Julián Merelo Guervós jmerelo at geneura.ugr.es
Depto de Arquitectura y Tecnología de Computadores
Universidad de Granada
URL:http://geneura.ugr.es/~jmerelo/DyEC/Tema1/DyEC-Tema1.html