Performance de sistemas Angular (Meetup Angular Montevideo)
•Descargar como PPTX, PDF•
0 recomendaciones•443 vistas
Performance de sistemas desarrollados con Angular En esta charla veremos distintos enfoques para mejorar la performance de sistemas desarrollados con Angular, considerando tanto el lado del cliente como el lado del servidor. Para esto veremos herramientas que nos permiten simular cientos de usuarios conectados en simultáneo, y a su vez, herramientas que nos permiten detectar dónde están los cuellos de botella. Por último, veremos cómo esto se puede enganchar en un esquema de CI/CD fomentando una cultura de DevOps y calidad.
Recomendados
Recomendados
Más contenido relacionado
Similar a Performance de sistemas Angular (Meetup Angular Montevideo)
Similar a Performance de sistemas Angular (Meetup Angular Montevideo) (20)
Más de Federico Toledo
Más de Federico Toledo (20)
Último
Último (7)
Performance de sistemas Angular (Meetup Angular Montevideo)
- 1. Performance de sistemas desarrollados con Angular PhD. Federico Toledo @fltoledo
- 2. 1. Introducción • Performance • Load Simulation 2. Taurus (BlazeMeter) 3. CI/CD • No hay nada especial para Angular, esto es aplicable a todo sistema conectado por http y muchos otros protocolos Performance de sistemas desarrollados con Angular
- 4. TRABAJO ÚTIL TIEMPO & RECURSOS VS
- 7. Medir
- 8. Bottlenecks / Punto de Quiebre
- 9. Dos puntas, cliente y servidor
- 10. Dos puntas, cliente y servidor
- 11. Usuarios concurrentes Tipos de Pruebas de Performance
- 12. • JMeter (jmeter.apache.org) • Taurus (gettaurus.org) • BlazeMeter (blazemeter.com) • Gatling (gatling.io) • Visual Studio Team Services (www.visualstudio.com) Herramientas de simulación
- 13. Simulación
- 14. Simulación
- 16. Demo / Dinámica
- 17. En CI/CD ¿Qué medir y cómo? • Carga fija: • Cierta cantidad de hilos. • Métricas para detectar degradaciones: • Response times: • Percentil 95, ¡nunca el promedio! • Throughput. • < 1% error.
- 18. ¿Qué medir y cómo?
- 25. Criterios de aceptación “La rodilla”: 350 usuarios concurrentes • < 1% error • P95 Response Times < 130ms + 20% • Throughput >= 150 TPS – 20%
- 26. • Performance • Velocidad y uso de recursos • Simulación de carga • Taurus • CI/CD friendly • CI/CD • Estrategia • Criterio de aceptación Cerrando
- 27. • Evento anual de testing con charlas y talleres • 21 y 22 de Mayo de 2018 • Meetups cada 2 meses • Web: www.testinguy.org • Meetup: www.meetup.com/Testing-Uy • Twitter: twitter.com/testingUY • YouTube: goo.gl/XAztZY
- 28. Certificación en testing de performance • Curso online de un mes • www.abstracta.us/training http://bit.do/librodetesting Si les gustó… los invitamos
- 29. Silicon Valley office 44 Tehama St San Francisco, CA Uruguay Headquarters Jose Ellauri 1126 Montevideo, Uruguay Uruguay II Uruguay 417 Salto, Uruguay www.abstracta.us jobs@abstracta.us
- 30. Performance de sistemas desarrollados con Angular PhD. Federico Toledo @fltoledo ¡GRACIAS!
Notas del editor
- Performance de sistemas desarrollados con Angular En esta charla veremos distintos enfoques para mejorar la performance de sistemas desarrollados con Angular, considerando tanto el lado del cliente como el lado del servidor. Para esto veremos herramientas que nos permiten simular cientos de usuarios conectados en simultáneo, y a su vez, herramientas que nos permiten detectar dónde están los cuellos de botella. Por último, veremos cómo esto se puede enganchar en un esquema de CI/CD fomentando una cultura de DevOps y calidad.
- 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
- Armar grupos de a 2 personas. En 5 min, una persona tiene que escribir user stories para un sistema de reporte de ventas, donde se recolecten métricas. La otra persona tiene que escribir user stories para un sistema de suscripción de usuarios a canales de cable. Pasados los 5 minutos, se intercambian las historias y pasan a completar los criterios de aceptación para las historias que hizo el otro. Al finalizar, conclusiones. Conversaron entre ellos? Definieron solos los criterios de aceptación? Porque debería ser una instancia de conversación.
- Our tests should have acceptance criteria (assertions) as tight as possible so that at the slightest system regression, before any negative impact, some validation fails, indicating the problem. This should be done in terms of response times and throughput. I like to call this "cinching the belt tight."
- Our tests should have acceptance criteria (assertions) as tight as possible so that at the slightest system regression, before any negative impact, some validation fails, indicating the problem. This should be done in terms of response times and throughput. I like to call this "cinching the belt tight."
- Methodology for profiling a load test Say we run the first test with 100 VU that results without crashes, the response times are below 100ms (at least the 95th percentile) and the throughput is 50 TPS.
- Then we run the test with 200 virtual users and again, there are no crashes and times are at 115 ms and the throughput at 75 TPS. Great, it’s scaling. If we continue on this path of testing, we will at some point, reach a certain load in which we see that we are no longer achieving an increase in the throughput. We will also be getting errors (which exceed 1% for example) which would indicate that we are saturating the server and it’s likely that response times from then on will begin to increase significantly, because some process or some connection or something begins to stick amid all the architecture of the system.
- Following this scenario, imagine we get to 350 concurrent users and we have a throughput of 150 TPS, with 130ms response times and 0% errors.
- If we pass 400 virtual users and the throughput is still about 150 TPS
- and with 450 users the throughput will be even less than 150 TPS.
- There is a concept called "knee" that we would be encountering with this type of testing illustrated in this graph. It is expected to increase the TPS when we increase the number of concurrent users, if it doesn’t happen is because we are overloading the system’s capacity. This is the basic methodology to find the kneecap when doing stress testing, when we want to know how much our servers can scale under the current configuration
- Our tests should have acceptance criteria (assertions) as tight as possible so that at the slightest system regression, before any negative impact, some validation fails, indicating the problem. This should be done in terms of response times and throughput. I like to call this "cinching the belt tight."
- Así detectamos a tiempo las degradaciones en performance, ahorrando el tiempo de detección y el de solución
- 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
- Performance de sistemas desarrollados con Angular En esta charla veremos distintos enfoques para mejorar la performance de sistemas desarrollados con Angular, considerando tanto el lado del cliente como el lado del servidor. Para esto veremos herramientas que nos permiten simular cientos de usuarios conectados en simultáneo, y a su vez, herramientas que nos permiten detectar dónde están los cuellos de botella. Por último, veremos cómo esto se puede enganchar en un esquema de CI/CD fomentando una cultura de DevOps y calidad.