این مقاله عالی و کوچیک و جدید یه نکته خیلی مهم و آموزنده داره:
Scale Up vs Scale Out
برنامه هایی که ما مینویسیم در سطوح مختلف از تعداد بسیار زیادی فرآیند خارجی کمک میگیرن که ما از عملکردشون خبر نداریم در حالیکه میتونن به شدت روی performance برنامه تاثیر بذارن.
در مقاله مطرح شده اپلیکیشن گولنگی رو توسعه دادن که با scyllaDB کار میکنه و بصورت single instance تعداد زیادی cpu core و ram در اختیارش قرار دادن. از یه حدی به بعد با وجود داشتن منابع زیاد، توان پاسخگویی سیستم بیشتر نشده و پس از بررسی متوجه شدن که یه مشکلی در پکیج netpoller گولنگ وجود داره. این پکیج از مکانیز epoll برای io/multiplexing استفاده میکنه و این مکانیزم برای ارتباط های network هم استفاده میشه. (در جلسه تیمسازی با بچه های دوره کلی در مورد این مکانیزم تحقیق و گفت و گو انجام دادیم)
مشکل اینجاست که netpoller در هر بار poll کردن ready بودن داده های ۱۲۸ تا سوکت رو buffer میکنه و این محدودیت وقتی خودش رو نشون میده که شما خیلی بیشتر از این عدد داده آماده از کانکشن های سوکت مختلف داشته باشید.
کاری که کردن اینه که جای اینکه یه single instance از application رو استفاده کنن، ۸ تا instance استفاده کردن ولی با همون میزان منابع که بین همه شون تقسیم شده. نتیجه خیره کننده بوده، توان پاسخگویی شون از ۱.۳ میلیون کوئری بر ثانیه رسیده به ۲.۸ میلیون کوئری بر ثانیه!
تنها کاری که کردن اینه که تعداد containerهارو زیاد کردن با همون منابع!
یعنی جای اینکه با یه container که همه منابع سیستم رو در اختیار داشته باشه کار کنن، یا اصطلاحا scale up کنن، تعداد containerهارو زیاد کردن ولی با منابع کمتر برای هر container یا اصطلاحا scale out کردن.
این مقاله یه نکته آموزنده دیگه هم داره، اونم اینه که بررسی performance یه سیستم به عوامل خیلی زیادی بستگی داره و عوامل درونی و بیرونی خیلی متفاوتی میتونن bottleneck سیستم شما باشن. پس وقتی میخوایم عملکرد سیستم رو بررسی کنیم باید خیلی شرایط رو بسنجیم، از ابزارهای خوب profiling و محیط مناسب تست با داده واقعی استفاده کنیم که بتونیم ارزیابی درستی از سیستم داشته باشیم.