اولین باری Performance پروژه که داشتیم رو APIها کار میکردیم
همچین تجربه‌ای نداشتم قبلا با این حجم از درخواست ولی . . . شد
تقریبا میشه گفت یکی از تجربه‌های پر از استرسم بود ولی تجربیات خوبی به دست آورم
از K6 برای تست پرفورمنس استفاده کردیم که در مرحله اول خیلی ساده بکارش بردیم ولی دیدم واقعا تست کردن فراتر از ایناس
ما قبل از تست باید زمینه های مختلفی رو برای تست درنظر میگرفیتم که به 4 حیطه رسیدیم:
در زمینه اول باید Traffic رو با Response time پروژه رو تعریف میکردیم که چه انتظاراتی داریم
اومدیم 300 تا Virtual user رو تعریف کردیم که باید کمتر از 200 میلی ثانیه Repones داده می‌شد و این تست رو برای مدت زمان 5 دقیقه درنظر گرفتیم و تونستیم به نقض های خوبی برسیم تا قبل اینکه به Pipeline ارسال کنیم به این تست Load Test میگن
در زمینه دوم
قبلش بگیم فقط تست بالایی که کافی نبود متاسفانه مجبور بود از ابعاد دیگه هم بررسی کنیم
بعضی وقت‌ها درApplication های شما بیشتر از انتطاراتی که داری برای شما Request میاد که ما منتظر این نبودیم این تست بشه و میانگین گرفته بشه چون زمان خیلی کم بود اومدیم تعداد virtual user اها افزایش دادیم البته با level های مختلفی تقسیم کردیم و هدف ها رو روی مثلا 500 , 800, 1000 گذاشتیم که در شرایط مختلف ما چه رویکردی داشته باشیم و حتی تعریف کردیم اگر یوزری هم نبود یعنی صفر مطلق! Duration رو 1m در نظر بگیر که به این نوع تست Stress test میگن که بیشتر برای اینکه ببینید Application شما در رفتار به اصطلاح حاد چه رویکردی باید ارایه بده منظورم Response time هستش
در زمینه سوم
که مثال ساده بگم مثلا شما نیاز دارید برای فروش بلیط کنسرت شخص معروف سایت بزنید درنظر بگیرید چه حجمی قراره به سمت شما بیاد در یک مدت زمان مشخص! ما اینم در نظر گرفتم پس عملا Stress test و Load test زیاد کاربردی ندارن چون Sudden increase دارید
ما طی تحقیقاتی که داشتیم به test Spike رسیدیم
اومدیم stage ها مختلفی تعیین کردیم که مثلا اگر به 50 هزارتا رسید Duration رو به 10s ارتقا بدیم و البته حالت Cool down رو در نظر گرفتیم
در زمینه چهارم
یک مشکل بزرگ داشتیم به نام Memory leak که چالش سخت و جذابی بود
عملا 3 تست بالایی هم برای ما دراین زمینه کاربردی نداشتیم و مجبور به این شدیم از Soak test استفاده کنیم چون Resource usage برای ما خیلی مهم بود و بالا بود!
ما باید Success rate رو همزمان با Memory usage CPU در نظر میگرفتیم تا Weak link رو پیدا میکردیم
البته این زمینه بیشتر در معماری های Microservice باید بهش زیاد دقت کرد
خیلی سعی کردم ساده توضیح بدم امیدوارم تونسته باشم این تجربه رو به خوبی نوشته باشم
#webinarfarsi #performance #javascript #api
ترجمه:
Recently, I was in a project for a company that cost almost 1.3 million! They have a request in “one minute” 📢
For the first time, we were working on APIs for the performance of the project we had
I didn’t have such an experience before with this volume of requests. . . became
It can almost be said that it was one of my most stressful experiences, but I gained good experiences
We used K6 for performance testing, which we used very simply in the first stage, but I saw that testing really goes beyond this.
Before testing, we had to consider different areas for testing, and we reached 4 areas:
In the first context, we had to define the traffic and response time of the project, what are our expectations
We came and defined 300 virtual users, which should be given less than 200 milliseconds Repones, and we considered this test for a duration of 5 minutes, and we were able to achieve good violations before sending it to the Pipeline, this test is called a Load Test.
In the second context
Before saying that only the upper test was not enough, unfortunately, we had to check other dimensions as well
Sometimes in your applications, more requests are sent to you than the ones you have. We didn’t wait for this to be tested and averaged because the time was very short. We increased the number of virtual users. For example, we put 500, 800, 1000, which approach we should have in different situations, and we even defined that if there was no user, it means absolute zero! Consider the duration as 1m. This type of test is called a stress test, which is mostly to see what approach your application should provide in the so-called acute behavior. I mean response time.
In the third context
To give a simple example, for example, you need to visit a website to sell tickets to a famous person’s concert, consider how much is going to come to you in a certain period of time! We also considered this, so stress test and load test are not very useful because you have a sudden increase
During our research, we came to the Spike test
We have set different stages, for example, if it reaches 50 thousand, we will upgrade the duration to 10s, and of course we have considered the Cool down mode.
In the fourth context
We had a big problem called Memory leak, which was a tough and interesting challenge
Actually, the top 3 tests were not useful for us in this field and we had to use the Soak test because Resource usage was very important and high for us!
We had to consider the success rate at the same time as the CPU memory usage to find the weak link
Of course, this field should be paid more attention to in Microservice architectures
I tried very hard to explain in a simple way, I hope I have written this experience well
#webinarfarsi #performance #javascript #api
For the first time, we were working on APIs for the performance of the project we had
I didn’t have such an experience before with this volume of requests. . . became
It can almost be said that it was one of my most stressful experiences, but I gained good experiences
We used K6 for performance testing, which we used very simply in the first stage, but I saw that testing really goes beyond this.
Before testing, we had to consider different areas for testing, and we reached 4 areas:
In the first context, we had to define the traffic and response time of the project, what are our expectations
We came and defined 300 virtual users, which should be given less than 200 milliseconds Repones, and we considered this test for a duration of 5 minutes, and we were able to achieve good violations before sending it to the Pipeline, this test is called a Load Test.
In the second context
Before saying that only the upper test was not enough, unfortunately, we had to check other dimensions as well
Sometimes in your applications, more requests are sent to you than the ones you have. We didn’t wait for this to be tested and averaged because the time was very short. We increased the number of virtual users. For example, we put 500, 800, 1000, which approach we should have in different situations, and we even defined that if there was no user, it means absolute zero! Consider the duration as 1m. This type of test is called a stress test, which is mostly to see what approach your application should provide in the so-called acute behavior. I mean response time.
In the third context
To give a simple example, for example, you need to visit a website to sell tickets to a famous person’s concert, consider how much is going to come to you in a certain period of time! We also considered this, so stress test and load test are not very useful because you have a sudden increase
During our research, we came to the Spike test
We have set different stages, for example, if it reaches 50 thousand, we will upgrade the duration to 10s, and of course we have considered the Cool down mode.
In the fourth context
We had a big problem called Memory leak, which was a tough and interesting challenge
Actually, the top 3 tests were not useful for us in this field and we had to use the Soak test because Resource usage was very important and high for us!
We had to consider the success rate at the same time as the CPU memory usage to find the weak link
Of course, this field should be paid more attention to in Microservice architectures
I tried very hard to explain in a simple way, I hope I have written this experience well
#webinarfarsi #performance #javascript #api
