Guía para realizar pruebas de rendimiento informático significativas para la productividad

Los programas de pruebas de rendimiento intentan analizar el «rendimiento» de una computadora basándose en una plataforma de prueba bien definida (que normalmente ni siquiera se acerca a la configuración final de la computadora). El encargado de la prueba puede aprovechar los límites a los que enfrentarse, como los recursos del sistema, el entorno de software virtual, las aplicaciones, la simulación de carga de procesamiento, la simulación de carga de usuario y la simulación de uso del sistema, entre otros; y hacer lo que sea necesario para superar dichos límites y dar un resultado cuestionable. Ahora, «tener un estándar industrial de prueba es siempre algo bueno, si los resultados no están manipulados. Lamentablemente, muchas pruebas de rendimiento industriales están manipuladas. […] Sin embargo, muchas organizaciones parecen comprar hardware basándose en pruebas de rendimiento en lugar de entender sus cargas de trabajo y comprar hardware según sus requisitos y, por supuesto, su presupuesto» (Newman, 2015). Esto explica por qué el cliente necesita saber exactamente qué es lo que se pretende medir. Un programa de pruebas nunca será capaz de reflejar la llamada experiencia del mundo real; simplemente reflejará qué tan bien funciona dicho programa en la computadora elegida. Por tanto, es responsabilidad del cliente determinar cómo se aplicará el resultado en su entorno productivo.

Sorprendentemente, realizar pruebas de rendimiento correctamente es algo realmente difícil, porque hay muchas posibilidades de obtener resultados malos o engañosos y omitir cosas. El libro blanco «A Nine Year Study of File System and Storage Benchmarking» resume esto:

En este artículo analizamos 415 pruebas de rendimiento de sistemas de archivos y almacenamiento de 106 documentos recientes. Descubrimos que las pruebas de rendimiento más populares son defectuosas y que muchos documentos de investigación no ofrecen una indicación clara del rendimiento real (Traeger, Zadok, Joukov y Wright, 2008).

En dicho libro blanco se pueden ver declaraciones sobre que las pruebas de rendimiento deben explicar qué es lo que se va a probar y por qué, y también deben realizar (o facilitar) una especie de análisis del rendimiento esperado del sistema.

En el artículo «Performance Anti-Patterns», hay algunos puntos destacados para determinar, en este caso, para qué y cómo deben ejecutarse las pruebas de rendimiento. Por lo tanto, una buena prueba de rendimiento debe ser:

• Repetible, para que los experimentos de comparación puedan realizarse con relativa facilidad y con un grado de precisión razonable.
• Observable, de modo que, si se observa un rendimiento deficiente, el desarrollador tenga un punto de partida. Nada es más frustrante que una prueba de rendimiento compleja que entrega un solo número, dejando al desarrollador sin información adicional sobre dónde podría estar el problema.
• Portable, para que las comparaciones sean posibles con tus competidores principales (incluso si son tus propias versiones anteriores). Mantener un historial del rendimiento de versiones anteriores es una ayuda valiosa para entender tu propio proceso de desarrollo.
• Fácil de presentar, para que todos puedan entender las comparaciones en una breve presentación.
• Realista, para que las mediciones reflejen las realidades experimentadas por el cliente.
• Ejecutable, para que todos los desarrolladores puedan determinar rápidamente los efectos de sus cambios. Si toma días obtener resultados de rendimiento, no sucederá muy a menudo.

No todas las pruebas de rendimiento seleccionadas cumplirán con todos estos criterios, pero es importante que algunas de ellas lo hagan. Smaalders invita a elegir pruebas de rendimiento que realmente representen las necesidades del cliente o todos los esfuerzos terminarán optimizando para el comportamiento incorrecto. También alienta a resistir la tentación de optimizar para la prueba de rendimiento con el objetivo de ganar el concurso a cualquier precio. Tal comportamiento ofrecerá resultados falsos que podrían generar falta de confianza en la marca o el proveedor. Generalmente, una prueba de rendimiento destacará el aspecto para el cual está optimizada, a expensas de otros aspectos que no se están midiendo (y que podrían ser importantes para el cliente) (Smaalders, 2006).

Hay otra cosa al comparar varios sistemas con la intención de comprarlos: la relación precio/rendimiento. Esta tasa puede cuantificarse incluyendo el costo de capital de 5 años del equipo (Anon y Gray, 1985).

Las pruebas simples con software de pruebas de rendimiento no constituyen un análisis de rendimiento completo. Los programas de pruebas de rendimiento normalmente funcionan en un entorno controlado, por lo que pueden manipularse para obtener una tasa deseada: la más alta posible. Sin embargo, dicha tasa NUNCA nos dará una correlación adecuada con la experiencia real del cliente. Más bien, las métricas proporcionadas solo te brindan un puntaje que es representativo de qué tan bien funciona en una prueba de rendimiento particular. Un gran problema es que el usuario nunca sabe realmente qué se prueba, cómo se miden los aspectos de un puntaje de prueba de rendimiento, qué indicadores se establecieron en el compilador, qué código o bibliotecas subyacen al programa y, lo más importante, si lo que el programa está probando reflejará el uso real previsto para la computadora. Hay, entonces, algunos puntos a destacar:

• Una prueba de rendimiento nunca reflejará el uso del mundo real. Al ser un programa totalmente automatizado, abrirá, escribirá, configurará, leerá, guardará, mostrará, buscará, navegará, moverá, calculará, asignará y realizará muchas otras tareas de forma totalmente automatizada. Tal forma nunca reflejará el ritmo al que un ser humano realizará su trabajo. Por lo tanto, cualquier programa de pruebas de rendimiento que prometa resultados basados en el uso del mundo real está mintiendo.

• No todas las pruebas de rendimiento evalúan el rendimiento de la multitarea. La gran mayoría de las pruebas de rendimiento solo evalúan tareas ejecutadas en serie. Prueban una cosa y, luego, la siguiente. Nunca pondrán a una aplicación a hacer algo mientras otra aplicación está haciendo otra cosa (y, si es así, normalmente prueban dos o, como mucho, tres instancias). En la vida real, los usuarios ejecutan múltiples aplicaciones simultáneamente. La mayoría de los usuarios abren muchas aplicaciones a la vez (el sistema operativo también ejecuta muchas tareas mientras realizamos nuestras tareas diarias). Vale la pena mencionar que una prueba de rendimiento que refleja solo un proceso/aplicación no escala linealmente con la segunda, tercera y el resto de los procesos/aplicaciones. Por lo tanto, en la tecnología multinúcleo moderna, es importante tomar los resultados de un programa de pruebas de rendimiento con cautela.

• «Tasa» no es lo mismo que «rendimiento». La tasa es solo un número dado por el programa. El rendimiento es algo más complicado. El número de tasa depende del programa de pruebas de rendimiento y la escala establecida por sus desarrolladores. El rendimiento es el logro de una tarea determinada medida contra estándares preestablecidos conocidos de precisión, integridad, costo y velocidad (The Business Dictionary, 2017). Por lo tanto, ninguna tasa de programa de pruebas de rendimiento refleja un índice de rendimiento.

• Las pruebas de rendimiento son inexactas. La variación en la tasa de un programa de pruebas de rendimiento puede ser de hasta un 10% (a veces, más). Estas tasas de pruebas de rendimiento son siempre subjetivas, lo cual es contrario a los principios objetivos de la ciencia y la tecnología. Es por eso que un programa de pruebas de rendimiento debe ejecutarse al menos 3 veces para calcular una media de la tasa dada. Después de determinar la media, se espera al menos una variación de +/- 3 % del resultado (dicha variación puede calcularse basándose en los resultados recopilados).

• Los resultados de las pruebas de rendimiento pueden manipularse. Hay formas de manipular los resultados de un programa de pruebas de rendimiento y ofrecer tasas artificialmente altas solo para impresionar al usuario. Esto se puede hacer a través de muchas técnicas, como ajustes excesivos, configuraciones en el BIOS, alteración del hardware, uso de controladores especiales, manipulación de código y otros. Las tasas de pruebas de rendimiento podrían obtenerse con configuraciones poco realistas en comparación con cómo se usará la computadora en la práctica: se requiere que el sistema esté libre de programas y procesos y que tenga valores específicos que dependen de la prueba de rendimiento particular, y esto no refleja la forma en que se usará la computadora en la productividad. Como declaró Henry Newman: «Lo que nos dice una prueba de rendimiento es: 1) Cuánto hardware puede meter un proveedor en una caja, 2) Qué tan bien puede optimizar el software el equipo del proveedor [para la prueba de rendimiento], y, 3) Qué tanto quiere el proveedor el trato» (Olds y OrionX, 2011). Si no hay un protocolo de prueba de rendimiento claramente establecido por el cliente, la puerta estará abierta para cualquier truco que el encargado de la prueba pueda hacer para alcanzar (o superar) los resultados deseados e impresionar al cliente.

Al final, un programa de pruebas de rendimiento no es una herramienta precisa y debe usarse con cuidado. Como citó Henry Newman en una comunicación personal, «Comparar herramientas de rendimiento del sistema […] con […] pruebas de rendimiento es como comparar manzanas con cerdos voladores» (Carrier, 2012).

Los puntajes proporcionados por una prueba de rendimiento deben usarse junto con otras pruebas de rendimiento y detalles adicionales para obtener una comprensión completa del rendimiento general del sistema. La prueba de rendimiento, en el mejor de los casos, solo está «midiendo la velocidad» de una computadora, pero hay muchos otros aspectos que deben tenerse en cuenta: estándares comerciales, estándares militares, funcionalidad, características, certificaciones, precio, entre otros.

Si la computadora que se está evaluando para su compra necesita cumplir con una variedad de requisitos de usuario diferentes, es mejor predeterminar los casos de uso previstos para que se establezca un conjunto detallado de criterios de calificación apropiados. En la mayoría de los casos, es probable que la computadora se utilice en uno o más de los siguientes contextos:

• Se utilizará con entornos operativos gráficos actuales (Windows 10, o distribuciones de GNU/Linux como mínimo)
  • O si se utilizará con versiones anteriores de sistemas operativos, como Windows 7 o Windows 8.1, o una distribución de GNU/Linux anterior.
• Productividad básica (No más de 5 aplicaciones ejecutándose, incluyendo):
  • Antivirus
  • Procesamiento de textos
  • Correo electrónico
  • Uso ligero de hojas de cálculo
  • Aplicaciones basadas en la web
  • Navegación web con no más de 6 pestañas abiertas.
• Productividad estándar (5 a 10 aplicaciones ejecutándose, incluyendo):
  • Igual que la Productividad básica, y también…
  • Aplicaciones de oficina (procesamiento de textos con manipulación de imágenes, hojas de cálculo con fórmulas y algunos scripts, presentaciones, gestión básica de bases de datos)
  • Navegación web con hasta 15 pestañas
  • Conferencias web
  • Visualización y edición simple de imágenes y videos
  • Educación
  • Puede asumir un uso copioso de videos, imágenes, animaciones, acceso web y aplicaciones que actualmente utilizan computación acelerada.
• Usuario avanzado (Más de 10 aplicaciones ejecutándose, incluyendo):
  • Igual que la Productividad estándar, y también…
  • Desarrollo de aplicaciones
    • Uso de lenguajes y entornos de programación
    • Creación, gestión y prueba de bases de datos,
    • Entorno de prueba con máquina virtual
    • Entornos de prueba controlados
  • Programas para investigación científica
    • Aplicaciones especializadas
    • Aplicaciones científicas y de ingeniería
    • Realidad virtual
• Solo como conocimiento general, los juegos se consideran actualmente computación de alto rendimiento (Stevenson, Le Du y El Afrit, 2011)
• Otros criterios
  • ¿Se requiere bajo consumo de energía?
  • ¿Es importante o limitado el espacio ocupado por la computadora?
  • ¿Se requiere movilidad?
  • ¿Es importante la autonomía de la batería?
  • ¿Es importante el peso?
  • Ciertos otros usos que implican el uso portátil en entornos hostiles, polvorientos o ruidosos.

El término en el título de esta sección puede parecer extraño, pero de hecho es un problema que generalmente se ignora o descuida. Se refiere a la siguiente pregunta: ¿Qué tiempo de respuesta le importa realmente al usuario? La velocidad y el rendimiento son términos realmente relativos. Ilya Grigorik propone un concepto interesante de lo que significa la palabra «rendimiento».

«El rendimiento no son solo milisegundos, cuadros y megabytes. También es cómo estos milisegundos, cuadros y megabytes se traducen en cómo percibe el usuario la aplicación» (Grigorik, 2014).

Cada aplicación prescribe su propio conjunto de requisitos de acuerdo con criterios comerciales, contexto, expectativas del usuario y constantes de tiempo de procesamiento perceptivo totalmente orientadas al usuario. Una vez más, las expectativas del usuario tienen una relación con la primera ley de Maister: «La satisfacción es igual a la percepción menos la expectativa» (Maister, 1985). No importa cuánto se acelere la vida, o al menos se perciba que se acelera (1 cuadro cada 66 ms), nuestros tiempos de reacción permanecen constantes. Si consideramos que un usuario puede ver alrededor de 15 cuadros por segundo según estudios tradicionales (Thorpe, Fize y Marlot, 1996), la siguiente tabla (basada en el Estándar Militar 1472G) da una idea clara del tiempo de respuesta que un usuario espera normalmente. Esto es independientemente del tipo de aplicación (instalada en la computadora o en línea) o medio (portátil, computadora de escritorio o dispositivo móvil).

Tiempo real y percepción del usuario (Seow, 2008)

• 0 – 100 ms: Instantáneo
• 100 – 500 ms: Inmediato
• 500 – 1000 ms: Rápido
• 1 – 10 s: Se percibe un retardo, pero el usuario no pierde el enfoque.
• +10 s: La computadora es demasiado lenta para mantener la atención del usuario.

Para que la respuesta a una solicitud del usuario se perciba como rápida, debe llegar en menos de un segundo. Si toma un segundo o más, el usuario puede percibir cierto retardo, pero su atención no se desviará de la tarea. Después de 10 segundos, a menos que el programa entregue algún tipo de información al usuario, la tarea normalmente se abandonará y el usuario experimentará molestia. Si la computadora que se está evaluando puede entregar respuestas en un tiempo comparable o en menos de 10 segundos, el usuario obtendrá más provecho de la computadora. Estos umbrales son mucho más útiles en el mundo real que los resultados de los programas de pruebas de rendimiento, que no ofrecen una guía clara sobre sus significados.

Dicho esto, en una prueba de rendimiento efectiva el cliente debe saber: cómo se aplica, el análisis y las conclusiones que se obtendrán de ella. Para el análisis, es importante entender o aportar:

• Un umbral o referencia del resultado mínimo esperado
• Qué es lo que se va a probar
• Cuáles son los factores limitantes
• Cualquier perturbación que pudiera afectar los resultados
• Los detalles del sistema probado
• El precio (al menos, el promedio) del sistema probado
• A qué conclusiones se busca llegar con los resultados

El umbral puede obtenerse de sitios públicos (como Futuremark) o puede crearse localmente a partir de una computadora actualmente en uso y con una buena configuración para establecer la línea base para cada prueba de rendimiento de las computadoras que se van a ofrecer. Anota los detalles de la configuración de esta computadora utilizada como línea base (procesador, memoria [cantidad, velocidad, configuración, tiempos], almacenamiento, tarjeta de gráficos y monitor) para tener una idea clara de ella.

El análisis de las pruebas de rendimiento requiere tiempo y experiencia para hacerse correctamente. Como se dijo, la parte más importante es determinar qué es lo que se va a medir y si los resultados obtenidos son significativos para el uso previsto de las computadoras.

Se recomienda para los procesos de configuración y pruebas de rendimiento no dejar solo al encargado de la prueba, especialmente si este es un tercero. El cliente debe asignar un testigo para anotar cualquier cosa que haga el encargado de la prueba con la máquina para configurarla para el proceso. Además, el testigo también debe anotar cualquier cambio o modificación que realice el encargado después de cada tipo de prueba. Si tú, como cliente, tienes un protocolo bien definido, el encargado de la prueba no debe violarlo solo para ganar el proceso. El encargado de la prueba y el testigo no deben ser la misma persona, nuevamente, especialmente si el encargado es un tercero.

Independientemente de la marca o el hardware ofrecido, todas las computadoras deben cumplir con los criterios de configuración:

• Si solicitaste procesadores de cuatro núcleos físicos, todas deben tener cuatro núcleos físicos.
• Si solicitaste una cierta cantidad, velocidad y configuración de memoria RAM, verifica que todas las computadoras tengan la misma configuración. Anota cualquier diferencia:
  • Tamaño
  • Velocidad (MT/s)
  • Tiempos y latencias (CAS, RAS, tRAS, tRC, Frecuencia)
  • Canal único vs arquitectura de doble canal
• Si solicitaste cierto tipo de almacenamiento, verifica que todas las computadoras incluyan ese tipo de almacenamiento. Anota cualquier diferencia encontrada (rendimiento, tiempos de búsqueda y tiempos de escritura):
  • Disco duro rotacional estándar (5400 RPM, 7200 RPM, 10000 RPM, SSHD)
  • SSD
• La tarjeta de video debe cumplir con Shader Model 6.1 (DirectX 12.1) para Windows 10 o Shader Model 5 (DirectX 11) para versiones anteriores de Windows.
• El monitor debe cumplir con las mismas características en cada computadora
  • Frecuencias de refresco
  • Tiempos de respuesta (ms)
  • Resolución (resoluciones más altas podrían traer números de prueba de rendimiento más bajos)
  • Profundidad de color
• El sistema operativo debe ser la misma versión y compilación.
  • En Windows puedes ver la versión y compilación escribiendo winver y Retorno en el cuadro de Cortana o después de presionar Windows+R para abrir la ventana Ejecutar.
• Cada computadora debe tener instalados solo los controladores actuales aprobados por el fabricante de la computadora. Nota: No permitas el uso de controladores especiales o controladores ajustados traídos por un fabricante de componentes, ya que podrían generar resultados falsos. Evita el uso de controladores fuera de los validados y disponibles públicamente en el sitio web o la herramienta de configuración del fabricante de la computadora.
• Configura la computadora en modo Equilibrado. Esta es la forma en que el cliente pretende utilizar las computadoras, y es la forma más fiel de obtener resultados de las pruebas.
• Instala las aplicaciones de uso común del cliente. No importa que no se utilicen en la prueba, es la forma en que se utilizarán las computadoras.
• Instala cualquier otro software (como antivirus y herramientas) requerido por el cliente. Esto establecerá la configuración lo más cerca posible de cómo la utilizará el usuario final.
• Instala los programas de pruebas de rendimiento.

Una vez instaladas las computadoras, se recomienda realizar una prueba de rendimiento en caliente. Una prueba de rendimiento en caliente necesita un ingeniero (Ingeniero, no un técnico) que tome nota de todo lo que sucede durante el proceso (partes de la prueba omitidas, pasos faltantes, comportamientos erróneos de la pantalla, figuras o imágenes mal dibujadas, y así sucesivamente). Dichas anomalías deben anotarse e informarse. Es recomendable evitar las pruebas de rendimiento en frío (simplemente ejecuta la prueba, aléjate de la computadora y, luego, regresa solo para anotar el resultado) porque no se notará evidencia de comportamiento extraño durante la prueba. Como se indicó, hay formas de manipular las tasas de pruebas de rendimiento y hacer una prueba de rendimiento en frío es la mejor manera de perder este tipo de prácticas.

Como las tasas de pruebas de rendimiento podrían arrojar variaciones del 5 al 15 %, se recomienda ejecutar cada prueba al menos 3 veces. Cada vez se necesitará un reinicio de la computadora, esperar unos 5 minutos después de que aparezca el escritorio y, luego, ejecutar la prueba de nuevo. Después de cada ejecución, se recomienda realizar una captura de pantalla del resultado para guardar la evidencia. Esto debe hacerse en cada programa de pruebas seleccionado.

Depende del cliente decidir si las diferentes tasas obtenidas a través de cada ejecución de cada prueba de rendimiento se promediarán, o tomando el valor más alto o más bajo. Cualquiera que sea la decisión que tome el cliente, se recomienda aplicarla a todas las diferentes pruebas utilizadas. Como sugerencia, opta por el promedio.

Después de obtener tales resultados, estos pueden normalizarse (como en el cuerpo de este documento) y, luego, convertirse linealmente en tiempos. Con el precio de las computadoras, el cliente también puede evaluar cuál de los sistemas ofrece la mejor relación precio/rendimiento.

Un proceso de pruebas de rendimiento requiere tiempo, experiencia y paciencia. Si se hacen bien, los programas de pruebas de rendimiento pueden dar una buena idea sobre el rendimiento esperado de la computadora. Todo lo anotado por el testigo será útil para determinar qué deberá proporcionar el concursante en caso de ser seleccionado. La configuración (procesador, memoria RAM [cantidad, velocidad, tiempos, modo de canal], almacenamiento [tipo, rendimiento, capacidad], monitor, factor de forma, etc.) anotada durante el proceso será útil para garantizar que la computadora entregada se configure exactamente como se probó. Esto es importante porque algunos proveedores abusivos pueden entregar una computadora configurada especialmente solo para el proceso de prueba, y una muy diferente al final. Por lo tanto, esto ayudará al cliente a obtener exactamente lo que se probó.

De toda la discusión anterior, se puede concluir lo siguiente:

• Las compras que está realizando el cliente son de computadoras, no solo de un procesador o un componente determinado. Por lo tanto, es necesario tener en cuenta el sistema general (holísticamente) al tomar una decisión de compra.
• El rendimiento de una computadora deriva de todos sus elementos. Esto incluye hardware y software. El rendimiento general de la computadora siempre será igual al rendimiento de su elemento más lento.
• Es necesario tener en cuenta las medidas de ahorro de energía, la generación de calor, la estabilidad de la computadora, sus certificaciones para uso comercial y los servicios de seguridad que ofrece. Más que solo la velocidad basada en pruebas de rendimiento, la tecnología actual requiere que se proporcionen servicios de seguridad y un consumo de energía reducido.
• Es importante ser consciente de que las nuevas tecnologías integradas en las aplicaciones y sistemas operativos aprovechan mucho más que solo el procesador. Más bien, se centran más en otros componentes como la CPU, GPGPU, buses, velocidad de la memoria RAM y tasa de transferencia del disco.

Una medida real de la potencia de cálculo se obtiene cuando la computadora se mide holísticamente, no solo en el área del procesamiento en serie o la CPU. El cliente que utiliza herramientas de oficina, navegadores web, compresión de archivos, reproductores de video, herramientas de teleconferencia, aplicaciones basadas en la web y cosas por el estilo aprovechará todas las características de estas nuevas tecnologías con arquitectura heterogénea.

Una nota final al respecto es que siempre se necesita un umbral o referencia para tener una mejor idea de las mejoras de rendimiento que se van a recibir. Si no quieres usar la medida base ofrecida por FutureMark para un «PC de oficina de referencia» a fecha actual, puedes medir tu computadora base en tu oficina según tus propios criterios (quizás, una computadora con la que te sientas cómodo con su rendimiento estándar). Una vez que ejecutes la prueba de rendimiento para obtener sus resultados, puedes, entonces, usar tales resultados como un umbral para tener tasas mínimas esperadas de las soluciones ofrecidas. Solo otra cosa a tener en cuenta es que «tasas» no es lo mismo que «rendimiento». Una «tasa» solo da una calificación de los procesos ejecutados por el programa de pruebas. «Rendimiento» es el resultado real que obtendrás a medida que uses dicha computadora en tus propias tareas.

Anon, E. A., y Gray, J. (febrero de 1985). A Measure of Transaction Processing Power. Consultado el 22 de marzo de 2015, desde Internet Archive: https://archive.org/details/bitsavers_ta...

Carrier, J. (24 de abril de 2012). HPCS I/O Scenarios. Consultado desde OpenSFS: http://cdn.opensfs.org/wp-content/upload...

Computerhope. (15 de marzo de 2015). Thrashing. Consultado desde Computer hope: http://www.computerhope.com/jargon/t/thr...

Gregg, B. (2014). Systems Performance Enterprise and the Cloud (1.ª ed.). EE. UU.: Pearson Education.

Grigorik, I. (12 de marzo de 2014). Speed, Performance, and Human Perception. (Fluent, Ed.) San Francisco, CA, EE. UU. Consultado el 22 de marzo de 2015, desde https://www.youtube.com/watch?v=7ubJzEi3...

Hoff. (30 de diciembre de 2006). Multicore, SMP and SMT Processors. Consultado el 22 de marzo de 2015, desde HoffmanLabs: http://labs.hoffmanlabs.com/node/13

Maister, D. (1985). The Psychology of Waiting Lines. (T. S. Encounter, Ed.) Consultado el 22 de marzo de 2015, desde David Maister: Professional Business, Professional Life: http://davidmaister.com/wp-content/theme...

Mallik, A. (2007). Hollistic Computer Architectures based on Application, User, and Process Characteristics. Evanston, Illinois, EE. UU.: UMI.

Newman, H. (2015). Data Storage Issues: Big Data Benchmarking. Consultado desde InfoStor: http://www.infostor.com/index/blogs_new/...

Olds, D., y OrionX. (19 de diciembre de 2011). Benchmarks are $%#&@!! Consultado desde The Register: http://www.theregister.co.uk/2011/12/19/...

Osterhage, W. (2013). Computer Performance Optimization (1.ª ed.). (Springer-Verlag, Trad.) Niederbachem, Alemania: Springer-Verlag Berlin Heidelberg.

Seow, S. (2008). Designing and Engineering Time. Boston, EE. UU.: Prentice Hall.

Smaalders, B. (23 de febrero de 2006). Performance Anti-Patterns. doi:1542-7790/06/0200

Stevenson, A., Le Du, Y., y El Afrit, M. (marzo de 2011). High Performance Computing on Gamer PCs. Consultado desde ArsTechnica: http://arstechnica.com/science/2011/03/h...

The Business Dictionary. (2017). Performance. Consultado desde The Business Dictionary: http://www.businessdictionary.com/defini...

Thorpe, S., Fize, D., y Marlot, C. (6 de junio de 1996). Speed of processing in the human visual system. Nature, 381, 520-522. Consultado desde Quora: http://cns.bu.edu/Profiles/Mingolla.html...

Traeger, A., Zadok, E., Joukov, N., y Wright, C. (mayo de 2008). A Nine Year Study of File System and Storage Benchmarking. Consultado el 22 de marzo de 2015, desde File systems and Storage Lab (FSL): http://www.fsl.cs.sunysb.edu/docs/fsbenc...

Vieira, L. (3 de octubre de 2011). The Perception of Performance. Consultado el 22 de marzo de 2015, desde Sitepoint: http://www.sitepoint.com/the-perception-...