Hace un par de meses salió un juego online de la casa Bioware, el Starwars The Old republic conocido como el SWTOR. Algunos ya lo saben que soy bastante fanática de los juegos online, y cómo no, de este también. Así que me puse a jugar y descubrí que mi PC necesitaba unas optimizaciones, así que apliqué mis conocimientos técnicos en la mejora de mi experiencia de usuario de un juego online.  Os doy una lista de mejoras a nivel de PC basados en Windows 7, y que realmente pueden servir para cualquier aplicación corriendo bajo windows.

Con esta guía conseguiremos mejores tiempos en el Boot, y de escritura lectura, y en general liberará recursos para mejorar la experiencia de juego. Primero empezamos con los requisitos de sistema para Windows 7.

• 1GHz processor (32- or 64-bit)
• 1GB of main memory
• 16GB of available disk space
• Support for DX9 graphics with 128MB of memory (for the Aero interface)
• A DVD – R/W drive

Qué es lo que necesitamos hacer para mejorar el rendimiento de nuestro pc.

Deshabilitar la búsqueda

Deshabilitar el Aero Theme

Deshabilitar Efectos Extra y servicios

Deshabilitar el control de la cuenta de Usuario

Deshabilitar cualquier feature que no usemos en general

Ahora bien tweaks de configuración más específicos a nivel de rendimiento:

Para mejorar el tiempo de boot

acceder al msconfig ( [Win] + R  o desde Ejecutar en el menú de inicio )

hacer click en el Boot Tab, allí hay una opción llamada Time Out. Este es el tiempo que el sistema espera para que el usuario selecciones el sistema operativo para hacer el boot.  tienes varios sistemas operativos en tu PC?   Si la respuesta es no, puedes setear el valor a 0.

También checkear el No GUI boot para apagar el logo de Windows 7 durante el boot -up

Aplicar y Ok

Para cambiar el número de procesadores usados durante el Boot Up

Normalmente ya los últimos PC’s vienen con varios procesadores, un Core Duo o Quad CPU tienen estas características.  normalmente a nivel profesional podemos asignar procesos a una cpu para mejorar el rendimiento de ese servicio. En windows también podemos hacer lo mismo. Lo que haremos es usar todos los procesadores durante el momento de carga, haciendo que el reboot sea más rápido.

Hacer click en las opciones avanzadas. Se abrirá un pop up con Boot Advanced Options, hacer click en el número de procesadores y escoger el número máximo de procesadores de los que disponemos.

Mejorar el tiempo para mostrar el menú

Vamos a tocar el registro de windows siempre con mucho cuidado.  [WIN] + R y usar el comando regedit. Navegar hasta la clave HKEY_CURRENT_USER\Control Panel\Desktop en el panel izquierdo. En el derecho hacer click derecho sobre MenuShowDelay y modificar con el valor 1 ( por defecto está en 400 ms )  Reiniciar la máquina para que se apliquen cambios.

Mejora del tiempo de apagado

[WIN] +R y entrar en el registro vía regedit. Navegar hasta HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control en el panel izquierdo, en el derecho modificar la entrada WaitToKillserviceTimeout poniendo 1000 ms por defecto es de 12000.

Cambiar el Plan de Energía

por defecto los settings de energía no están automáticamente seteados a máximo rendimiento. Cambiando el plan de energía implica que decrece  el consumo para hardware mejorando un poco el rendimiento a nivel de software.

En general:

Por supuesto es conveniente  siempre tener un registro limpio, podemos usar algún software que nos ayude como Ccleaner.  Podemos usar también una aplicación para mejorar la conexión de internet como SG TCP Optimizer

Una de las muchas preguntas que me hacen a lo largo de los días es qué es RUX. Así llamamos en Infojobs a la herramienta desarrollada para controlar los tiempos de carga de nuestros usuarios. Es como LA matrix realmente. Todas las peticiones que se hacen a nuestros servidores llevan una marca, un pixel trasparente, que nos indica cuánto ha tardado la renderización de nuestras páginas. La próxima vez que entres en infojobs.net recuerda que, ¡ te estamos controlando! al menos en cuanto al tiempo que tarda en cargar la página.

¿Por qué creamos una herramienta así y no la compramos? Básicamente porque teníamos ya el sistema Syslog montado y de este modo podemos controlar realmente qué es lo que queremos medir.

Un performance tester o engineer ( acordaros de mi post donde indicaba las diferencias ) querrá tener un indicador de tiempo de carga de una página y ahí es él/ella quien decide qué es lo que realmente quiere medir, si la página completa con elementos 3rd party o sin ellos. Con una herramienta hecha a medida eso se consigue. Mi recomendación a cualquier empresa tecnológica es que implementen una herramienta de este tipo primero porque reducirá costes, y segundo porque siempre tendrá el control sobre sus métricas.

De todos modos, el otro día navegando por la red encontré una lista de herramientas de este tipo, tanto comerciales como open source. Y por eso os la añado a enlances interesantes que necesitáis saber y conocer!

http://www.real-user-monitoring.com/the-complete-list-of-end-user-experience-monitoring-tools/

Particularmente me decanto por Keynote o Gomez y la que últimamente estamos probando de Quest, la maravillosa y tristemente cara Foglight. De esta última espero poder teneros actualizados a lo largo de los próximos meses que es el período de prueba que tenemos.

Así que feliz navidad Ya tenéis “cacharrines” con los que jugar!

Yo marcho pa casa a ver la eficiencia de las vacas Asturianas!

Una de las cosas que siempre hay que hacer es mantenerse al día en cuanto a tecnología, pero no hay que olvidar los conceptos aprendidos que pueden ser simples pero que también puede ser que hayamos desvirtuado a lo largo de los años.

Hace un par de meses nuestro gurú particular Scott Barber publicó una guía para tontos, Webload Testing for Dummies conjuntamente con compuware ( LoadRunner ). Os lo podéis bajar registrandoos en la página de gomez de forma gratuita.

http://www.gomez.com/ebook-web-load-testing-for-dummies-generic/

Particularmente me pareció un libro brillantemente sencillo, que ayuda a fijar conceptos a nivel de negocio y técnicos que deberíamos tener en cuenta en nuestro a día a día.

Por ejemplo me gustaría resaltar el capítulo 7: Ten Common Myths and Misconceptions of Web Load Testing.  Lo primero que hay que distinguir cuando hablamos de performance es 3 términos, Performance Engineering, Performance Testing y Capacity Planning.  Muchas veces en nuestro día a día podemos realizar tareas relacionadas con una de estas actividades. Tenemos que saber en todo momento que “gorra” tenemos puesta y a quién debemos acudir en caso de un impedimento.  Distinguiendo esto podemos ahorrarnos muchos corre-ve-y-dile

Otra de las entradas que a mi me parece más interesante y que intentaré desarrollar otro día es sobre la gran pregunta de cómo de rápido debe de ser un site:  Industry Standard Response Time = Satisfied Users. Os pongo un ejemplo, no es lo mismo una página de ocio un domingo por la tarde que un sistema crítico de banca que tiene que tener una respuesta inmediata en nuestro trabajo. No es lo mismo trabajar sobre un sistema distribuido que navegar por internet. Incluso la misma persona puede presentar diferente respuesta ante mismos tiempos de carga.  Un buen performance tester debe de tener ese punto de psicología y empatía con el usuario que está al otro lado de los firewalls, switches, nodos, servidores … al otro lado del cable al fin y al cabo.

buen fin de semana y feliz lectura!

Después de una presentación así, normalmente la siguiente pregunta que te harán es, “¿y qué haces en el día a día?”.
Los amigos de Softqanetwork me han invitado a escribir en este espacio para ir explicando qué hacemos “los de rendimiento”.

• Primero una pregunta sencilla,  ¿qué son las pruebas de rendimiento?. Cuando se lo tengo que explicar a mi madre, le digo que trabajo para que las páginas web sean más rápidas. Si se lo explico al inversor, le comento cómo voy a ahorrarle costes a nivel de hardware y que su negocio recibirá más tráfico y por tanto tendrá más beneficios. En realidad lo que hago es “sencillo”, ayudo a las organizaciones y a los técnicos a optimizar sus sistemas y su aplicación a nivel de coste, “time to market” y capacidad. Y como somos QA performance testers,  siempre orientados a la calidad del servicio para los usuarios.

• La siguiente pregunta será quién hace rendimiento. Normalmente, al performance expert se le llama después de una catástrofe, por lo que una habilidad social que debemos tener es la de dar seguridad, -estoy aquí para ayudaros, y vais a tener que sudar para conseguirlo!- Un performance expert es un “jack of all trades”, alguien que sabe de todo y no sabe de nada. El gran lema a nivel de rendimiento es que tienes que probar la aplicación sobre el sistema. Ni la aplicación aislada, ni el sistema aislado. Un performance tester tiene que saber de servidores, pero no será el administrador de sistemas, sabrá de tuning de SQL pero no será dba, de igual forma tiene que saber de código pero no será el arquitecto de la aplicación.  El performance expert/tester será el engranaje y el facilitador entre los distintos equipos en un departamento de IT, desde networking, base de datos, sistemas,  desarrollo y por supuesto el Usuario. Por eso es normalmente díficil encajarnos en el agilismo, aunque el performance testing es ágil per se. Esta última reflexión la dejo para un post siguiente.

• Qué se necesita para hacer rendimiento. Dinero y sobre todo TIEMPO,  mucho tiempo.  Primero debemos saber qué espera el Usuario de la aplicación. Psicología:  es vital conocer la experiencia de Usuario a nivel de rendimiento.  Necesitamos herramientas de análisis de comportamiento del usuario, no será igual una página web de ocio que una aplicación de escritorio crítica, uno de nuestros mejores aliados será entonces el departamento de marketing o de atención al usuario. Convicción:  Por supuesto es necesario tener el apoyo del equipo de desarrollo para convencerles de que una aplicación puede funcionar, pero puede que funcione de una forma poco eficiente.  Conocimiento técnico para saber qué hay que probar, cómo, cuándo y durante cuánto tiempo. Conocer las limitaciones del hardware, y la lógica de la aplicación. Por supuesto conocer el negocio y conocer la tecnología. Un performance expert detecta los problemas de rendimiento y puedo colaborar en dar soluciones, por lo que tiene que estar muy al día en cuanto a la tecnología.  Entorno específico y aislado para pruebas de rendimiento y Monitorización para saber el estado de los sistemas productivos y poder comparar el entorno de rendimiento/stress con el entorno productivo.  Por culpa de este último punto la percepción de que “hacer  rendimiento” es caro.  Disciplina y orientación a la calidad al fin y al cabo somos QA’s

   PERFORMANCE TESTING: Una investigación técnica y empírica  dirigida a darle a los inversores lainformación sobre la calidad del  producto o  del    servicio testeado acerca de la velocidad,  escalabilidad y estabilidad.

    PERFORMANCE INVESTIGATION:  Recopilar datos, y más datos, y  más datos, y más gráficas… Toda la información es  principalmente para realizar  hipotésis sobre el origen de los  problemas de rendimiento. 

   PERFORMANCE VALIDATION:  Comparación, Benchmarking …  todo es medible, y si no lo es, se puede hacer medible

En resumen, un performance tester necesita tiempo y dedicación, pero necesita unos mínimos de conocimiento técnico, paciencia, capacidad crítica y analítica y mucha muchaaaaaa mano izquierda

Una prueba de rendimiento es fácil. Es fácil diseñar escenarios poco realistas. Es fácil recolectar datos irrelevantes. Incluso, con un buen escenario y uno buenos datos, es fácil utilizar el método estadístico incorrecto.  Alberto Savoia

Recientemente, en una reunión, un compañero afirmaba rotundamente que un requerimiento no necesita ser analizado para ver si se puede testear, es decir, si es “testeable”. Afirmaba lo siguiente: “Si el cliente pide ese requisito, se puede y se debe testear…no es necesario analizar nada, lo quiere el cliente y punto”. Desde mi punto de vista era una afirmación un poco arriesgada. Esto me hizo pensar, ¿realmente sabemos que quiere decir que un requisito sea “testeable”? Un requerimiento testeable nos asegura que podremos ejecutar nuestras baterías de pruebas llegado el momento de ejecución. Probablemente para un analista de negocio (Business Analysis) no sea un asunto demasiado importante, pero para los equipos de testing si que es un factor crítico a considerar. En principio, todo requerimiento debe poder ser testeado, pero en la práctica la cosa es diferente.

Por tanto los equipos de testing deberíamos de tener este atributo siempre en cuenta cuando nos encontremos en las fases de toma de requisitos y análisis. Ya sabéis que cuanto antes nos demos cuenta de la “testeabilidad” de un requisito, antes podremos mitigar el riesgo y gastaremos menos dinero. Por ejemplo, tenemos un nuevo producto y debemos comunicarnos con uno de nuestros clientes. ¿Es este requisito testeable? ¿Podemos comunicarnos con nuestro cliente para enviarle y recibir información o debemos simularlo? Si tenemos que hacer una simulación implicará que tendremos que crear todo este set de pruebas simuladas y tal vez necesitemos ayuda de desarrollo. ¿Está nuestra arquitectura preparada para realizar estas pruebas? Tal vez en el entorno en el que queremos realizar las pruebas no tenemos todos lo elementos necesarios para hacer una cobertura total. Esto implicará la comunicación con el equipo de arquitectura para ver cómo podemos mitigar este riego. Esto son sólo algunos ejemplos, pero podemos encontrarnos en miles de situaciones similares…así que no deis por hecho la testeabilidad en la práctica de un requisito teórico.

Es cierto que no podemos ignorar las demandas de nuestros clientes sólo porque un requerimiento es difícil de testar, pero sí que debemos comprobar que el producto cumple con ellos.

Webserver Stress Tool es una potente herramienta de pruebas de rendimiento que permite encontrar problemas críticos en aplicaciones web y web servers (HTTP-client/server).

Permite simular un gran número de usuarios accediendo a un aplicación web via HTTP/HTTPS. La versión de pago permite simular hasta 10.000 usuarios, mientras que la gratuita sólo permite simula un único usuario. El precio de la lincencia no es muy elevado (200€), barata en comparación con otras herramientas de este tipo que están en el mercado.

Esta herramienta permite realizar pruebas de rendimiento, stress, carga y disponibilidad.

Sahi es una herramienta de automatización de aplicaciones web. Es muy parecida al “Selenium Web Test tool” de la que ya hablamos hace unos meses. Sahi es un herramienta desarrolla en java y javascript que usa el javascript para ejecutar eventos del navegador.

Una de las características que más me ha gustado es que además de soportar HTTP y HTTPS, soporta AJAX.

El único requisito para su instalación es la Java Vitual Machine (JVM) 1.4 o superior.

Antes de instalarla la herramienta se puede ver una demo bastante interesante en la web de sahi.

¿Qué es JMeter?
JMeter es una herramienta de carga para llevar acabo simulaciones sobre cualquier recurso de software.

Inicialmente diseñada para pruebas de estrés en aplicaciones web, hoy en día su arquitectura ha evolucionado no sólo para llevar acabo pruebas en componentes habilitados en Internet (HTTP), sino además en Bases de Datos, programas en Perl, requisiciones FTP y prácticamente cualquier otro medio.

Además, posee la capacidad de realizar desde una solicitud sencilla hasta secuencias de requisiciones que permiten diagnosticar el comportamiento de una aplicación en condiciones de producción. En este sentido, simula todas las funcionalidades de un Navegador (“Browser”), o de cualquier otro cliente, siendo capaz de manipular resultados en determinada requisición y reutilizarlos para ser empleados en una nueva secuencia.


Proceso de instalación
Instalación del JDK (J2SE)
La base para operar cualquier producto que utiliza “Java” es el “JDK” de la plataforma correspondiente, puede encontrar instrucciones para plataformas Linux así como Windows, en la página web principal de java

Los pasos anteriores son los suficientes para el “JDK” en lo que concierne a la instalación de JMeter, posiblemente después tenga que trabajar con la también sumamente importante variable de entorno CLASSPATH, por ahora lo anterior es suficiente.

Instalación
1. Descargar JMeter de su página web principal.
2. Descomprimir el archivo .tar de JMeter en un directorio temporal ( /tmp por lo general) a través del comando : jakarta-jmeter-<numero_de_version>.
3. El paso anterior genera un directorio por nombre jakarta-jmeter-<numero_de_version>, dentro del cual se encuentran los diversos componentes de JMeter, descritos a continuación.

Estructura
bin
Este directorio contiene los ejecutables utilizados por JMeter, tanto para ambientes Linux (jmeter) asi como Windows (jmeter.bat).

docs
Contiene documentación acerca de JMeter

printable_docs
Contiene documentación — en modalidad de impresión — acerca de JMeter

lib
Este directorio contiene los archivos JAR empleados por JMeter requeridos en cualquier modalidad.

Ejecución
La ejecución de JMeter es llevada acabo del directorio bin, que contiene las siguientes opciones:

jmeter | jmeter.bat
Corresponde a los ejecutables de la interfase principal para plataformas *nix y Windows, respectivamente.

jmeter-server | jmeter-server.bat
Representan los ejecutables para el emulador de Servidor JMeter para plataformas Linux y Windows, respectivamente.

jmeter.properties
Contiene propiedades de arranque para JMeter que son utilizadas por cualquiera de sus ejecutables.

jmeter.log
Representa los registros (“logs”) generados al ejecutar JMeter.

users.xml | users.dtd
Un archivo XML y su correspondiente DTD, empleados para definir características de usuarios que serán simulados por JMeter.

ApacheJMeter.jar
Archivo JAR que contiene las principales clases de JMeter.

Las siguientes secciones de esta guia están concentradas en pruebas llevadas acabo con la interface gráfica (Cliente) de JMeter, por esta razón, ejecute el comando jmeter ( o jmeter.bat si utiliza Windows).

Prueba de Carga Básica
El componente principal de JMeter es denominado Plan de Prueba o Test Plan, en él se definen todos los aspectos relacionados con una prueba de carga, como por ejemplo parámetros empleados por requisición, tipo de reportes a generarse con los resultados obtenidos, la posible reutilización de requisiciones compuestas por usuarios, entre otros aspectos.

A continuación se ilustra paso a paso un Plan de Prueba utilizado para simular una carga de 50 usuarios solicitando la página principal en determinado sitio.

• Estando en la interface principal de JMeter (ilustrada anteriormente), en la columna izquierda debe observar un icono llamado Test Plan (seleccionelo) al llevar acabo este paso, en la ventana derecha aparecerán varias opciones, aquella encontrada en la parte superior le permite asignar un nombre a su plan de prueba, definalo a su criterio. El resto de las opciones representan funcionalidades avanzadas que no serán descritas para esta simulación.

• Definido el nombre, coloquese nuevamente en el icono Test Plan y oprima el botón derecho de su ratón, del menú generado seleccione la opción Add – Thread Group; para efectos prácticos un Thread Group es considerado el grupo de usuarios que desea simular para su aplicación.

• Ahora seleccione el icono Thread Group recientemente creado. Al llevar acabo este paso la ventana derecha mostrará la siguiente serie de opciones:

name
Utilizado para definir un nombre más descriptivo sobre el grupo de usuarios, como Usuarios Esperados

number of threads
Equivale al numero de usuarios que se desean simular, en este caso utilizaremos 50.

Ramp-up period
Es el lapso de tiempo en segundos que se desea tener entre cada grupo de usuarios Thread Group, utilizaremos 15.

Forever
Utilizado para indicar si la simulación para grupos de usuarios Thread Group será llevada acabo infinitamente, esto es, si selecciona esta opción indica que desea simular 50 usuarios, esperar 15 segundos Ramp-up period, simular otros 50 usuarios y así sucesivamente. Para esta prueba es recomendable defina 10 ciclos para simular un total de 500 usuarios en cuestión de 150 segundos.

Scheduler
Finalmente, esta opción permite definir tiempos de arranque para determinados grupos de usuarios Thread Group , para efectos prácticos de esta simulación no será seleccionada esta opción y se iniciará la prueba a nuestra discreción.

Una vez definidas las características del grupo de usuarios Thread Group, colóquese nuevamente en este icono de la columna izquierda y ahora seleccione la opción Add Sampler HTTP Request. Lo anterior genera un icono denominado HTTP Request utilizado para definir las requisiciones de simulación. Si selecciona este último icono aparecerán las siguientes opciones en la ventana derecha:

Server Name or IP
Empleado para definir la dirección I.P o nombre del servidor donde será llevada acabo la prueba de carga, se utilizará 127.0.0.1 para indicar un servidor local.

Port number
Define el puerto TCP de operación del servidor, será empleado 80, que es el “default” para Servidores de Páginas.

path
Utilizado para definir la ruta de acceso para llevar acabo la prueba, será definido /index.html, típicamente la página principal de todo sitio para Internet.

Ahora debe colocarse en el icono de HTTP Request y oprimir el botón derecho de su “mouse”, del menú generado seleccione la opción Add Listener Graph Results, así como Add Listener View Results in Table. Lo anterior le indica a JMeter que debe generar una gráfica y tabla (respectivamente) con los resultados obtenidos en la simulación.

• Finalmente guarde su plan de prueba y ejecútelo seleccionando la opción Run – Start del menú superior. Si se coloca en el icono Graph Results mientras se esta llevando acabo la simulación, puede observar como es construida interactivamente la gráfica de resultados.

Como ultima nota, es recomendable que cuando ejecute la presente prueba de carga también realice un análisis sobre el comportamiento del Hardware, para tener una perspectiva global acerca del sistema.

En la siguiente y última sección de esta guiá, será descrita otra prueba de carga con funcionalidades más avanzadas.