README.md
295 subscribers
20 photos
9 files
608 links
Everything about software engineering
⌨️

https://t.me/boost/readmemdd
Download Telegram
اخیرا در یک پروژه برای شرکتی بودم که تقریبا 1.3 میلیون ! درخواست در "یک دقیقه" دارن 📢
اولین باری 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 باید بهش زیاد دقت کرد

خیلی سعی کردم ساده توضیح بدم امیدوارم تونسته باشم این تجربه رو به خوبی نوشته باشم


#javascript #api #k6

▶️join: @readmemdd