Asegura la performance de apps móviles en devices y servidores
•Descargar como PPTX, PDF•
3 recomendaciones•870 vistas
Este documento discute cómo asegurar el rendimiento de las aplicaciones móviles tanto en el dispositivo como en el servidor. Explica la importancia de realizar pruebas de carga y monitoreo para identificar cuellos de botella y mejorar la experiencia del usuario. También recomienda implementar integración continua, evaluar el uso de CDNs y adoptar HTTP 2.0.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (8)
Similar a Asegura la performance de apps móviles en devices y servidores
Similar a Asegura la performance de apps móviles en devices y servidores (20)
Más de Federico Toledo
Más de Federico Toledo (20)
Último
Último (19)
Asegura la performance de apps móviles en devices y servidores
- 1. Cómo asegurar la performance de aplicaciones móviles tanto en el device como en el servidor PhD. Federico Toledo @fltoledo Ing. Fabián Baptista @fbaptista
- 2. Cómo asegurar la performance de aplicaciones móviles tanto en el device como en el servidor PhD. Federico Toledo @fltoledo Ing. Fabián Baptista @fbaptista Cómo asegurar la performance de aplicaciones móviles tanto en el device como en el servidor
- 3. Performance PhD. Federico Toledo @fltoledo Ing. Fabián Baptista @fbaptista
- 5. Focus on the User https://developers.google.com/web/fundamentals/performance/rail?hl=en < 100 ms – Action / Reaction 100 – 300 ms – Slight Delay 300 – 1000 ms – Feels natural (tasks) +1000 ms – Loses focus
- 6. Tip 1/5: Read about AMP
- 7. • Abstracta • Montevideo, UY (2008) • Salto, UY (2015) • California, US (2016) • GXtest (2009) • Odl.uy (2013) • Monkop Inc. (2014) • Abstracta Academy (2016) Federico y Fabián
- 8. Performance PhD. Federico Toledo @fltoledo Ing. Fabián Baptista @fbaptista
- 9. 1. Load testing en Azure. 2. Monitorización. 3. Performance en los devices. 4. Integración continua. Agenda
- 11. TRABAJO ÚTIL TIEMPO & RECURSOS VS
- 14. Medir
- 15. Bottlenecks / Punto de Quiebre
- 16. Dos puntas, cliente y servidor
- 17. Dos puntas, cliente y servidor
- 18. • Usuarios concurrentes • Proceso Tipos de Pruebas de Performance
- 19. • JMeter (jmeter.apache.org) • Taurus (gettaurus.org) • BlazeMeter (blazemeter.com) • Gatling (gatling.io) • Visual Studio Team Services (www.visualstudio.com) Herramientas de simulación
- 20. Simulación
- 21. Simulación
- 22. Visual Studio Team Services • Load test web sites, apps and APIs • Scale to hundreds of thousands of concurrent users • 20,000 virtual user minutes FREE every month Fuente: https://www.visualstudio.com/en-us/explore/vso-cloud-load-testing-vs https://www.visualstudio.com/docs/test/performance-testing/getting-started/getting-started-with-performance-testing
- 23. Visual Studio Team Services • Generate load from multiple regions worldwide • Deep analysis with rich diagnostics, trace and exception logging Fuente: https://www.visualstudio.com/en-us/explore/vso-cloud-load-testing-vs
- 24. Visual Studio Team Services https://federicotoledo.visualstudio.com
- 25. •Herramientas clásicas: • SQLServer • Estadísticas, uso de índices, caché... • Profiling • Entender comportamiento del código • Indicadores de IIS • PerfMon – a nivel de SO (Windows) •¿Qué pasa en la nube? Monitorización
- 26. Monitorización – Azure Monitorización de la máquina virtual a nivel de Windows
- 27. Visual Studio – Application Insight https://www.visualstudio.com/application-insights/ •APM: Application Performance Management. •En todas las capas. • RUM (real user monitoring) – para conocer el user experience • Arquitectura de la aplicación • Componentes (base de datos, servidor de aplicaciones, etc.) • Sistema operativo
- 28. VS–Application Insight: Top-down https://azure.microsoft.com/en-us/documentation/articles/app-insights-detect-triage-diagnose/ Detectar disponibilidad Métricas de performance
- 29. VS–Application Insight: Top-down https://azure.microsoft.com/en-us/documentation/articles/app-insights-overview/ A nivel de Aplicación • Desde el request hasta las consultas SQL
- 30. Client Side
- 31. • Web Apps (Page load) • Page Speed Insights Performance
- 33. • Web Apps (Page load) • Page Speed • Yslow • monkeytest.it • APMs (Javascript) • Native Apps / Mobile • Xamarin Test Cloud Performance
- 37. • Web Apps (Page load) • Page Speed • Yslow • monkeytest.it • APMs (Javascript) • Native Apps / Mobile • Xamarin Test Cloud • iOS: XCTest / Instruments Performance
- 38. iOS: XCTestCase
- 39. iOS: XCTestCase
- 40. • Web Apps (Page load) • Page Speed • Yslow • monkeytest.it • APMs (Javascript) • Native Apps / Mobile • Xamarin Test Cloud • iOS: XCTest / Instruments • Monkop Performance
- 44. Encuentro GeneXus Marca Fotocasa La Liga VivaVideo Monkop - Exploraciones
- 45. • Web Apps (Page load) • Page Speed • Yslow • monkeytest.it • APMs (Javascript) • Native Apps / Mobile • Xamarin Test Cloud • iOS: XCTest / Instruments • Monkop • APMs (Libraries) Performance
- 46. Team Services | Agile + IC
- 47. Visual Studio Team Services https://monkop.visualstudio.com
- 48. GitHub
- 49. Tip 2/5: Evaluar CDNs! Para contenido estático
- 50. Tip 3/5: Use HTTP 2.0!
- 51. Bonus Track – Tip 4/5 Stop collecting Libraries and Plugins!
- 52. Bonus Track – Tip 5/5 Don’t let marketing lead development!
- 53. • Integración continua • Baby Steps • Chequeos client/side • Device / Browser • Simulación de carga • Integración / Prueba End to End • Monitorización • Application Insights Receta final
- 54. PhD. Federico Toledo @fltoledo Ing. Fabián Baptista @fbaptista ¡GRACIAS! ¡Cómo hacer que mis apps vuelen!
- 55. • Evento anual de testing con charlas y talleres • +270 asistentes • Meetups cada 2 meses • Web: www.testing.uy • Meetup: www.meetup.com/Testing-Uy • Twitter: twitter.com/testingUY • YouTube: goo.gl/XAztZY
- 56. Certificación en testing de performance • Curso online de un mes • www.abstracta.us/training 25% de descuento usando este cupón este mes NETCONFUY http://bit.do/librodetesting Si les gustó… los invitamos
- 57. Silicon Valley office 425 Broadway Street Redwood City, CA Headquarters Jose Ellauri 1126 Montevideo, Uruguay www.abstracta.us jobs@abstracta.us
Notas del editor
- http://netconf.uy/
- http://netconf.uy/
- http://netconf.uy/ 1ro de Octubre - 16:40 (Federico Toledo y Fabián Baptista). Track Octopus. <Fabian> Hicimos inicialmente un título muy aburrido porque no le queríamos sacar gente al extranjero que compite en el otro track ya que corría en desvantaja con nuestros currículums. Gracias por venir! Vamos a hablar de performance, ya que es un tema que nos apasiona y al cual nos hemos dedicado durante toda nuestra carrera profesional Soy Federico, vengo de Uruguay, contento de estar aquí y encontrar antiguos amigos de la facultad y del trabajo, gente con la que he compartido y aprendido mucho. También contento que puedo, gracias a Slack y redes sociales, sentirme parte de esta comunidad a pesar que no estoy físicamente cerca. Y más contento aún que hoy puedo presenciar y compartir este rato contando de una de las pasiones que tengo por el testing, y de hecho fue la que me hizo entrar al mundo del testing: el testing de performance. Hace 10 años comencé trabajando en el CES como performance tester. Hace 8 años fundamos con dos amigos Abstracta, y hoy nos dedicamos a dar servicios y herramientas de testing, en América Latina y hace 3 años especialmente con foco en Estados Unidos. Esto que les voy a presentar hoy es una charla que voy a dar en QA&Test en Bilbao en octubre, y en CMG Impact en USA, en la Jolla cerca de San Francisco. Se trata de analizar qué es más conveniente, si invertir los esfuerzos de tesitng de performance al final del proceso de desarrollo, o durante el proceso. Lo que quiero es compartirles algunas experiencias de haber participado en las dos variantes, viendo algunos pros y contras.
- Hoy, el estándar para juegos (o contenido ANIMADO) es de 60fps, Los displays de todos los iphones, TVs, etc, funcionan a 60fps, eso significa que cada 16ms se vuelve a colocar una nueva imagen en el buffer de la pantalla para poder tener un contenido nuevo.
- El avance en los estudios de la neurociencia y el entendimiento de cómo funciona “nuestro sistema” ha permitido construir modelos como RAIL (recomendar leer / google), el que establece los umbrales físicos de las personas y de los factores psicológicos de las tareas que efectuamos.
- Levanten la mano los que conocen de APM Project? Tip1: leer about AMP
- <Fabian>: Presentación, Motivación, Ejemplos, Preguntas Abstracta Co founders - Why how what ? Con Federico fundamos Abstracta, una empresa que nace con la convicción de que la confiabilidad y la performance son las cualidades mas importantes de cualquier tecnología. Luego contar experiencia de Fabian: performance y devops, misiones complicadas (o por tiempo como un banco, o por impacto (salud)). Luego de Monkop. Fede tiene un doctorado en la materia, escribió el primer libro en español referente a testing, automation y performance, es docente y trabaja en el área de performance hace ¿10 años? Hoy está metido en un proyecto muy desafiante para medir, analizar y mejorar la performance en cada ciclo de build y además es el director de Abstracta Academy.
- http://netconf.uy/ 1ro de Octubre - 16:40 (Federico Toledo y Fabián Baptista). Track Octopus. <Fabian> Hicimos inicialmente un título muy aburrido porque no le queríamos sacar gente al extranjero que compite en el otro track ya que corría en desvantaja con nuestro currículum…, dichosos uds. Que saben que a la otra charla igual la pueden ver en diferido y no se quisieron perder esta charla, gracias por venir! Soy Federico, vengo de Uruguay, contento de estar aquí y encontrar antiguos amigos de la facultad y del trabajo, gente con la que he compartido y aprendido mucho. También contento que puedo, gracias a Slack y redes sociales, sentirme parte de esta comunidad a pesar que no estoy físicamente cerca. Y más contento aún que hoy puedo presenciar y compartir este rato contando de una de las pasiones que tengo por el testing, y de hecho fue la que me hizo entrar al mundo del testing: el testing de performance. Hace 10 años comencé trabajando en el CES como performance tester. Hace 8 años fundamos con dos amigos Abstracta, y hoy nos dedicamos a dar servicios y herramientas de testing, en América Latina y hace 3 años especialmente con foco en Estados Unidos. Esto que les voy a presentar hoy es una charla que voy a dar en QA&Test en Bilbao en octubre, y en CMG Impact en USA, en la Jolla cerca de San Francisco. Se trata de analizar qué es más conveniente, si invertir los esfuerzos de tesitng de performance al final del proceso de desarrollo, o durante el proceso. Lo que quiero es compartirles algunas experiencias de haber participado en las dos variantes, viendo algunos pros y contras.
- Let’s start with a very basic question (I hope that everyone know the answer, but just in case…)
- Computer performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used. We cannot only see how fast it is, because a system that is very fast that uses 100% of CPU is not performant. Then, we need to check both sides, the user experience (the time I perceive, the velocity) and the server feelings (how stressed the servers are). Also, if we only pay attention to response times, we only could see the symptoms, but what we want to find are the root causes in order to identify bottlenecks and then improvements.
- Ok, we agree about what “performance” is, but now, what is performance testing about? Mainly we have to tasks: simulation and measurement
- Simular, el pibe sentado sobre el Puente Simulation and measurement. Analyze the system’s behavior in terms of response times and resource usage. Sometimes we want to report how good or bad is the system behaving, and sometimes is a proactive approach in order to improve the obtained results. Investigate and analyze looking for bottlenecks, in order to make experiments, tuning or altering the system, seeking for improvements. Of course, it is this kind of testing where your focus is on the performance aspects: response times and resource usage. For this, it’s important to simulate the load that it is expected for production: the corresponding amount of concurrent users, with the “intensity” that will characterize them. There is a preliminary result that you can obtain that it is very useful too, that is to simulate certain stress on different components, not only on the entire system. This could be done with the aim of finding bottlenecks, concurrency issues and improvement opportunities.
- Quote GoT – medir – lo que no conocemos es lo que nos mata Enganche con bottle necks
- There are different approaches for performance testing simulation, different types of tests: Load test: when you try to simulate exactly the amount of users that you will have in production. Stress test: you want to go further, trying to determine the breaking point of your system (the biggest load that it can support with acceptable response times) Peak test: you want to see how fast your system can recover from a stress peak Endurance test: you want to address different problems, mainly those that appear in long execution times. Then, you want to execute a test for many ours. You can find memory leaks, or any other resource leak (sockets, connections, etc.) We had a project last year where we executed a great load testing and we tuned the system properly for the production environment. They went live and everything was fine. After 21 days the system (java) had to be rebooted because it has consumed all the memory assigned to the JVM. Then everything good again. After 22 days, again. After 21 days, again. We started to investigate the issue and yes, there was a memory leak caused for a bad use of connections in a list. How to avoid this really bad situation? (bad for your customer and bad for you as a performance testing services provider, because you can lose trust): make an endurance test with focus in memory and sockets. Take a picture of the situation at the start and at the end of a long run (it could be the all night long) and compare them, pay attention to those resources that are not freed as expected. On the other hand, not all systems work under concurrency. Sometimes the stress of a system is more related to data volume, or even a single process executing certain algorithm. In these situations it’s still valid to thing about performance testing analysis of possible improvements, in the algorithms, in the way the data is managed, etc. http://www.abstracta.us/2015/10/12/why-performance-testing-is-necessary/ http://www.abstracta.us/2015/03/30/types-of-performance-tests/
- http://www.abstracta.us/2015/09/07/introduction-to-taurus-an-alternative-to-jmeter/ Blazemeter.com jmeter.apache.org
- Mostrar primero qué se necesita para hacerlo en forma manual De todos modos se necesita automatización, el sistema, la infraestructura y todo eso La complicación es la coordinación y repetitibilidad de las pruebas Ahí metemos herramientas de generación de carga en forma automatizada y soluciona mucho estos problemas y baja costos Con pocas máq Performing load testing without an automated load-testing tool is problematic. Manual load testing is costly, time consuming, and not practical. With manual load testing, it is difficult to replicate the tests over and over again; there is no repeatability. It is almost impossible to simulate tens of thousands of users, while coordinating time, people, machines and the overall testing environment. Also, because it is hard to replicate the tests over again, the results become difficult to analyze. Automated load testing tools on the other hand allow QA professionals to re-run the exact tests over and over again with different premises. With an automated load-testing tool, QA can simulate load conditions, such as number of sessions per hour and then simulate users accessing the application at the same time. For example, QA can run a test that simulate a load of 100 users, then with 200 users, up to tens of thousands of users. At each load, QA will find out how well the application scales and behaves. Also, automated load testing tools allow QA professionals to easily gain access to client side response time and server statistics, such as CPU and memory utilization. With an automated load-testing tool, QA can gain repeatability, reusability, and results that matter. Automated load-testing tools also allow Managers to utilize their QA staff and computer resources more efficiently in order to ensure the optimum stability, responsiveness, scalability, and throughput of an application before it is deployed uinas y sin requerir coordinación con 100s de personas podemos simular su uso.
- El esquema no lo planteamos nosotros, sino que es lo que se usa Se pueden llegar a hacer las pruebas manuales (simulaciones) + las pruebas de performance en concurrencia Easy to use Workflow bar guides you through all steps Single point of control: Health control for agents as well as automatic agent detection, VUser load balancing, remote agent setup Powerful project concept Powerful Replaces tests with virtual users (vs. manual load testing) Automatically synchronizes all virtual users (vs. manual load testing) Systematic and reproducible (vs. manual load testing) Runs thousands of VUs on a single machine (TrueScale technology !!!) IP spoofing and DNS lookup with full scalability (without any penalty on performance or scalability) Various TrueLog formats Accurate Accurately simulates the load of realistic users TrueCache TrueModem TrueLog Reliable error detection on application level (automated link verification) Isolate problems simply and quickly through Content verifications, even under heavy load Visual logs that show you the click paths to your errors (TrueLog On Error) Detailed response time breakdown analysis (also on error – e.g. threshold exceeded – during a load test) Real-time performance monitors for your back-end systems In-depth management reports
- https://www.visualstudio.com/en-us/explore/vso-cloud-load-testing-vs Si usan el VS enterprise pueden configurar todo desde su máquina, pero no es necesario, se puede hacer desde la web
- Para optimizar la performance no alcanza con generar carga, necesitamos entender cómo están funcionando las aplicaciones. Para esto necesitamos herramientas de monitorización.
- Demo vs ts Mostrar cómo se hace por la web Contar que algo simple es con una url, pero eso es demasiado básico Algo posta es con VS test o con Jmeter Apuntar a que estudien jmeter, está copado que se abran a cosas opensource también. Salir de la zona de comfort
- La primera vez que vi uno de estos no entendía cómo hacía pruebas de performance sin esta información. https://azure.microsoft.com/en-us/documentation/articles/app-insights-detect-triage-diagnose/
- http://www.abstracta.us/2015/11/02/how-to-optimize-e-commerce-website-performance-for-black-friday/
- Contar de qué se trata: Pones la URL y mirás los resultados Mobile + Desktop Te ayuda a solucionar los problemas y a determinar si te afecta a tu realidad o no Se puede automatizar (Ring)
- http://www.abstracta.us/2015/11/02/how-to-optimize-e-commerce-website-performance-for-black-friday/
- La adquisición de Microsoft de Xamarin fue un gran hito, no sólo por la capacidad de desarrollar apps nativas, multiplataforma de buena performance, sino por adquirir la nube cd cispositivos más grande del mundo. El know how que existe atrás de eso sino por la solución en si. Este es un ejemplo de varios tests a la aplicación pokemonGo, se puede ver, para cada test, el resultado … explicar el enfoque. Se puede usar ya sea por el equipo de desarrolladores / automators cuando ya está la app, e incluso cuando no (un enfoque mas TDD con cucumber).
- http://www.abstracta.us/2015/11/02/how-to-optimize-e-commerce-website-performance-for-black-friday/
- http://www.abstracta.us/2015/11/02/how-to-optimize-e-commerce-website-performance-for-black-friday/
- Esa herramienta es Monkop. Es un monito que ejecuta pruebas en celulares. Top benefits monkop - no necesito Código. No necesito automatizar - en menos de una hora probé en varios devices incluso en las últimas versiones. Si instaló o no y como se comportó. Ver vídeos de la prueba etc.
- http://www.abstracta.us/2015/11/02/how-to-optimize-e-commerce-website-performance-for-black-friday/
- Preguntas a la audiencia: Quienes usan VS Online / Team Services? Quienes usan Jenkins GitHub? Azure? Nos resultó muy buena las micro instancias que genera Team Services, ya vienen con Python instalado, CURL y otro tipo de herramientas que hacen fácil integrarse con cualquier herramienta. De hecho se puede integrar Monkop con 1 Línea de script. DEMO Mostrar cómo se configura un step en Tservices para agregar Monkop Mostrar la ejecución 1 Mostrar la ejecución 2 Explicar el output
- Demo vs ts Mostrar cómo se hace por la web Contar que algo simple es con una url, pero eso es demasiado básico Algo posta es con VS test o con Jmeter Apuntar a que estudien jmeter, está copado que se abran a cosas opensource también. Salir de la zona de comfort
- Yo creo que existe el mito de que esto es solo para apps basadas en contenido o con mucho tráfico a imágenes / videos / etc. No es así! Incluso hay CDNs gratuitos.
- HTTP 2.0 nace para hacer la web mas robusta, performante y simple (eso es raro). El objetivo principal es reducir la latencia! No modifica la interfaz (metodos, status codes, URL, headers, etc), lo que hace es transmitir los paquetes en forma distinta, permitiendo multiplexing, prioritización de request, server push, compresión de headers, etc.
- Así detectamos a tiempo las degradaciones en performance, ahorrando el tiempo de detección y el de solución
- http://netconf.uy/ 1ro de Octubre - 16:40 (Federico Toledo y Fabián Baptista). Track Octopus. <Fabian> Hicimos inicialmente un título muy aburrido porque no le queríamos sacar gente al extranjero que compite en el otro track ya que corría en desvantaja con nuestro currículum…, dichosos uds. Que saben que a la otra charla igual la pueden ver en diferido y no se quisieron perder esta charla, gracias por venir! Soy Federico, vengo de Uruguay, contento de estar aquí y encontrar antiguos amigos de la facultad y del trabajo, gente con la que he compartido y aprendido mucho. También contento que puedo, gracias a Slack y redes sociales, sentirme parte de esta comunidad a pesar que no estoy físicamente cerca. Y más contento aún que hoy puedo presenciar y compartir este rato contando de una de las pasiones que tengo por el testing, y de hecho fue la que me hizo entrar al mundo del testing: el testing de performance. Hace 10 años comencé trabajando en el CES como performance tester. Hace 8 años fundamos con dos amigos Abstracta, y hoy nos dedicamos a dar servicios y herramientas de testing, en América Latina y hace 3 años especialmente con foco en Estados Unidos. Esto que les voy a presentar hoy es una charla que voy a dar en QA&Test en Bilbao en octubre, y en CMG Impact en USA, en la Jolla cerca de San Francisco. Se trata de analizar qué es más conveniente, si invertir los esfuerzos de tesitng de performance al final del proceso de desarrollo, o durante el proceso. Lo que quiero es compartirles algunas experiencias de haber participado en las dos variantes, viendo algunos pros y contras.
- Inviten a sus testers al evento y a los meetups de testingUY
- Opening: incluye el PoC, plantear que a nadie le gusta el testing. He estado involucrado en testing y calidad desde hace 10 años en muchas cosas, libro, universidades, herramientas, servicios, en la universidad, con un doctorado en España