Introducción a la optimización de software, consejos, metodología y tools.
Ejemplo y documentación en:
https://drive.google.com/open?id=13egVpX2uOSX7-BWyCvFrpZul6EOEM6_U
Charla: Arquitectura, aplicaciones y seguridad en Android, impartida por Antonio Díaz de Informática 64 en el curso de Especialización en Dispositivos Móviles que tuvo lugar en la Facultad de Informática de la Universidad de A Coruña del 20 al 22 de Junio de 2012.
El ciclo de vida de un proyecto se divide en cinco fases de gestión: inicio, planificación, ejecución, supervisión y cierre. Estas fases son la hoja de ruta para que tú y tu equipo superéis los proyectos más complicados.
Charla: Arquitectura, aplicaciones y seguridad en Android, impartida por Antonio Díaz de Informática 64 en el curso de Especialización en Dispositivos Móviles que tuvo lugar en la Facultad de Informática de la Universidad de A Coruña del 20 al 22 de Junio de 2012.
El ciclo de vida de un proyecto se divide en cinco fases de gestión: inicio, planificación, ejecución, supervisión y cierre. Estas fases son la hoja de ruta para que tú y tu equipo superéis los proyectos más complicados.
Argentesting 2017 - Performance testing 101 con jmeterArgentesting
Este taller será una introducción a los conceptos de Performance Testing y a la utilización de JMETER para armar planes de pruebas de performance.
Los requerimientos de las máquinas de los asistentes son:
Procesador Intel i3 o Superior con 2GB y 1 GB de espacio Libre.
SO: Linux, MacOs, Windows
JAVA 1.8 Instalado
Expositor: Sebastián Lallana
Charla en Universidad ORT 2014 - Testing técnico (automatización, mobile, pe...Federico Toledo
Esta fue una charla dada en la Universidad ORT en el año 2014. Los temas tratados fueron varios, relacionados a la industria y a la academia.
Agenda:
- Test execution automation
- Test design automation
- Monkop (mobile testing, performance and security)
- Performance testing
Testing técnico - Automatización en web y mobile para pruebas funcionales y p...Abstracta
Introducción a distintos aspectos de calidad y testing de software, enfocando en ciertos puntos desarrollados en Abstracta:
- testing automatizado (Selenium, GXtest, JUnit)
- generación de pruebas con model driven approaches usando UML, UTP, ATL (model to model) y Acceleo (Model to Text)
- smart monkey testing (Monkop - monkop.com) para probar automáticamente aplicaciones Android
- pruebas de performance con OpenSTA
De esta forma mostramos cómo estamos volcando la empresa a la investigación en la industria, investigación en la academia, desarrollo de productos y servicios de alto valor agregado.
Taller TestingUy 2019 - ¡Estresá el sistema, no al usuario!TestingUy
Expositores: Federico Orihuela y Rodrigo Quinta
Duración: 2 horas
Resumen: ¿Cómo saber si el sistema soporta la cantidad de usuarios esperada? ¿Qué infraestructura necesitamos para desplegar el sistema? En este taller te ayudamos a responder esas preguntas mediante la ejecución de pruebas de performance utilizando JMeter. La performance de los sistemas es cada día más relevante para los diferentes actores, lo que lleva a una creciente necesidad de ejecutar este tipo de pruebas, que permiten estudiar el comportamiento, la escalabilidad y la confiabilidad de los sistemas.
Transparencias de la charla con la que participamos en las III Jornadas de Java de Alicante.
En las transparencias se muestran algunas herramientas para implantar metodologías ágiles en Java y se comentan algunas anécdotas e historias de diferentes implantaciones.
Framework GSM para Pruebas AutomatizadasSoftware Guru
La automatización de pruebas de software consiste en utilizar herramientas y estrategias para reducir la intervención o interacción humana en tareas redundantes, repetitivas o complejas. Esta automatización se ve reflejada en secuencias de comandos (o por su traducción al inglés “Scripts”) con los que podemos aumentar de forma drástica la capacidad de probar el software. Para poder simplificar aún más el tiempo de diseño y ejecución de dichos scripts se han desarrollado los llamados marcos de trabajo (o comúnmente conocidos como framework por su traducción al inglés), que son un conjunto de suposiciones, conceptos y prácticas que proporcionan apoyo a las pruebas de software automatizado.
Curso de test driven development usando AngularJS, Jasmine, Karma, Protractor, y Gulp para automatizar todo.
Codigo del proyecto de ejemplo:
https://github.com/rodrigopivi/angularComponentStarter
Pruebas de Manto Cuantos tipos de pruebas hay ? Que es una estrategia ? Que e...defijel142
Cuantos tipos de pruebas hay ?
Que es una estrategia ?
Que es verificación?
Que es validación?
Es lo mismo estrategia o guía o check list o .....?
Es lo mismo verificacion y validación?
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
2. Índice
• Introducción
• Un poco de teoría
• Guía básica de viaje. Cómo afrontar una
optimización
• Estudio de un caso real
• Ejemplo práctico
• Enlaces interesantes
4. ¿Qué es la optimización de software?
• Proceso para mejorar la velocidad de ejecución, su tamaño
en disco ó las necesidades de memoria de un software.
• Puede realizarse en la creación del código, en un paso
posterior ó después de haberse finalizado la tarea.
• Puede ser un paso peligroso y nunca se puede asegurar la
optimización perfecta, aunque sí conlleva mejoras.
• Distinguiremos dos tipos: SOFT (optimizaciones sencillas,
que se realizan normalmente en el proceso de creación del
software) y HARD (el resto).
5. ¿Cuándo realizar una optimización?
Optimizaciones SOFT
• Cuando estamos escribiendo el código.
• Al continuar con una tarea (refactorización,
eliminación de código duplicado, etc…)
• Al solucionar bugs o problemas.
Optimizaciones HARD
• Nunca
• Sólo cuando sea estrictamente necesario y
analizando previamente si el cambio compensa
el riesgo:
• Si no se cumplen los requisitos de la
aplicación o del sistema para el que se
desarrolla.
• El rendimiento es crítico.
• Colapsa o deja inutilizable el sistema.
• Etc…
En general seguiremos un planteamiento conservador: Sólo se aplicarán las optimizaciones
“seguras”, en ningún caso aquellas que puedan ser peligrosas
6. Consejos generales
• La primera regla de la optimización es que no se habla de la
optimización (hasta que sea necesario).
• Diseña correctamente las aplicaciones, un buen diseño y estratificación
es indispensable.
• Analiza tus problemas antes de resolverlos, elige los mejores algoritmos
antes de implementar.
• Codifica correctamente con claridad y estilo, no es una pérdida de
tiempo.
• Prima siempre la calidad del código sobre la optimización (no ofusques).
Si no está roto, no lo arregles
Asegúrate de que el cambio que vas a realizar tendrá una
mejora sustancial respecto al software actual. Utiliza
herramientas externas para asegurarte de que es así
9. Ámbitos de optimización
Según arquitecturaSegún aplicación
Dependientes de la máquina
Independientes de la máquina
• Aprovechan las características
específicas de cada máquina.
• Uso de instrucciones especificas de
procesador.
• Predicción de saltos, optimización de
memoria, caché, etc…
• Se aplican a cualquier tipo de
máquina.
• Eliminación de redundancias, cambio
de orden de ejecuciones, etc...
Optimizaciones locales
• Se aplican dentro de un mismo
bloque de código.
• No tienen dependencias ni
repercusiones fuera del bloque de
aplicación.
Optimizaciones globales
• Aplican a más de un bloque.
• Tiene en cuenta el contenido y los
flujos de datos entre todos o parte
de los bloques de un programa..
• Necesita conocer las interrelaciones
entre los distintos bloques .
10. Buenas praxis al programar
• Elimina código innecesario.
• Saca código de los bucles.
• Inicializa las variables al crearlas.
• Divide y vencerás: Independencia de bloques,
zapatero a tus zapatos.
• Pasa los parámetros grandes por referencia.
• Reduce las operaciones de IO, trabaja en memoria.
• Usa los tipos de variables adecuados.
• Identifica constantes y variables estáticas.
• Utiliza las variables globales sólo cuando sean
necesarias.
• ¡Conoce tu entorno y herramientas!
• Un buen diseño y arquitectura inicial te ahorraran
muchos problemas.
• Codifica pensando en la claridad y no ofusques
intentando optimizar, el compilador también
trabaja.
11. typedef struct _my_struct
{
char name[50]; char comments[1024];
}my_struct;
void main()
{
int index;
float total;
bool found;
my_struct data[100];
…
index = 0;
total = 100;
InitializeData(&data);
…
for (index = 0; index < total; index++)
{
char name [] = “Laetitia”;
found = false;
if (IsSameName(name, data[index]))
{
if (found == false)
{
found = true;
break;
}
}
}
…
}
bool IsSameName(char* name, my_struct data)
Buenas praxis al programar (ejemplo)
typedef struct _my_struct
{
char name[50]; char comments[1024];
}my_struct;
void main()
{
int index;
float total;
bool found;
my_struct data[100];
…
index = 0;
total = 100;
InitializeData(&data);
…
for (index = 0; index < total; index++)
{
char name [] = “Laetitia”;
found = false;
if (IsSameName(name, data[index]))
{
if (found == false)
{
found = true;
break;
}
}
}
…
}
bool IsSameName(char* name, my_struct data)
typedef struct _my_struct
{
char name[50]; char comments[1024];
}my_struct;
void main()
{
int total = 100;
bool found = false;
my_struct data[100];
const char name [] = “Laetitia”;
…
InitializeData(&data);
…
for (int index = 0; index < total && !found; index++)
{
found =(IsSameName(name, data[index]));
}
…
}
bool IsSameName(const char* name, const my_struct& data)
12. Optimizaciones HARD
Optimizaciones dependientes del hardware o de muy alta dificultad.
• Se hacen siempre al finalizar la implementación.
• Abordar sólo las que sean completamente seguras, en ningún caso las inseguras.
• Ejemplos:
– Cambios en el orden de las operaciones.
– Optimizaciones para plataformas específicas (MMX, SSE, etc…)
– Cambios en algoritmos.
– Uso de modos de direccionamiento, asignación de registros, etc…
13. Herramientas y utilidades
Software libre
Software comercial
Compuware DevPartner Studio
IBM Rational
Intel V-Tune
Microsoft Visual Studio Ultimate
AMD Code Analyst
MemProf CCMGNU Prof
16. Determinar si existe un problema
Si no hay un problema, no toques nada.
Tenemos un problema si:
• La aplicación no cumple los requisitos iniciales.
• Algún proceso es tan lento que hace la aplicación inmanejable.
• Pierde memoria.
• Los accesos a medios externos provocan costes excesivos.
• El rendimiento se va degenerando cuanto más tiempo lleve ejecutándose el
programa.
• Es necesario aprovechar todos los recursos de la arquitectura sobre la que
ejecutamos la aplicación.
17. Encontrando el problema
• Intentar determinar el origen del problema:
• Buscar en la parte del código con la
funcionalidad a mejorar.
• Ejecutar la aplicación obviando los
bloques sospechosos.
• Verificar que se solucionan los problemas
de rendimiento.
• Si no es trivial encontrar el problema:
• Preparar un entorno de ejecución aislado.
• Si es posible implementar un tester que
ejecute únicamente las partes conflictivas
del programa.
• Utilizar una herramienta externa cómo un
profiler para obtener las estadísticas de
uso de bloques y tiempo que consumen.
18. Estudio y resolución del problema
Una vez encontrado el problema:
• Comprobar que es el problema real.
• Estudiar las posibles soluciones.
• Comprobar la viabilidad de las soluciones.
• De las posibles soluciones viables preparar una prueba de concepto para cada
una de ellas.
• Obtener estadísticas de rendimiento para cada prueba de concepto (hacer
varias ejecuciones en las mismas condiciones y comparar las medias).
• Escoger la mejor solución en cuanto rendimiento/facilidad de implementación.
• Implementar la solución en la aplicación final.
• Comparar las métricas de la aplicación original con la aplicación optimizada
para verificar que el problema se ha solucionado.
19. Comparando resultados
Es indispensable verificar la optimización:
• Prepara un entorno de pruebas limpio, una
máquina virtual con un punto de
restauración es ideal.
• Diseña un proceso de pruebas que verifique
el área concreta a optimizar, por ejemplo
con un tester de línea de comandos.
• Ejecuta un número de veces relevante las
pruebas con el sistema sin optimizar,
tomando las métricas adecuadas en cada
ejecución.
• Calcula la media de todas las ejecuciones
para cada métrica obtenida.
• Repite el proceso con el sistema optimizado.
• Compara los resultados entre ambos y
verifica que la optimización soluciona el
problema.
• Verifica que la solución es viable y es
posible incorporarla a la aplicación final.
21. Resultados de un estudio de
comparación de rendimiento
Escenario:
• Motor de detección viejo y difícil de mantener
• Motor no ampliable.
• Comienzo del desarrollo de un nuevo motor con arquitectura bien definida
• El nuevo motor debía de soportar plugins
• El nuevo motor debía añadir nuevas tecnologías de detección
• Requisito indispensable: Por lo menos igualar el rendimiento del motor actual
Motor actual 1.3 Motor 2.0 (B1)
Inicialización 527 ms. 1.200 ms.
Análisis x fichero +3 ms. 7 ms.
Análisis batería (100.000 ficheros) 6 min. 10 seg. 11 min. 45 seg.
Finalización 100 ms. 94 ms.
Tiempo total análisis 6 min. 20 seg. 12 min.
22. Análisis mediante y conclusiones
Consumo de tiempos (%)
Gestión TAD ficheros*
Análisis T1
Análisis T2
Análisis T3
Análisis T4
Análisis T5
Análisis T6
Operaciones IO
Función aux
Otros
*Gestión en memoria de ficheros a analizar
(búsquedas, accesos, obtener información…)
Conclusiones:
• Cuello de botella en la gestión de ficheros (el
tiempo debería de ser ínfimo en comparación
con las otras operaciones)
• Los análisis pueden verse lastrados por el
problema con la gestión de ficheros
• La función aux es trivial, algo raro está
pasando.
Medidas a tomar:
• Sustituir el TAD de la gestión de ficheros de
lista enlazada a tabla HASH.
• Revisar función aux.
• Eliminar redundancias encontradas.
• Eliminar múltiples lecturas de IO no necesarias.
• Eliminar múltiples llamadas a mismas
funcionalidades.
23. Resultados de la optimización
Conclusiones:
• Las pruebas de concepto resultaron satisfactorias.
• Se realizaron los cambios ideados durante el proceso de análisis.
• La mejora de rendimiento fue sustancial dejando al producto dentro de los
requerimientos iniciales.
• El proyecto salió adelante,
Motor actual 1.3 Motor 2.0 (B1) Motor 2.0 (B2)
Inicialización 527 ms. 1.200 ms. 890 ms.
Análisis x fichero +3 ms. 7 ms. 4 ms.
Análisis batería (100.000 ficheros) 6 min. 10 seg. 11 min. 45 seg. 6 min. 40 seg.
Finalización 100 ms. 94 ms. 74 ms.
Tiempo total análisis 6 min. 20 seg. 12 min. 6 min. 50 seg.