این مطلب رو هم دوست خوبم میلاد زنگنه برام فرستاده، منتشرش می کنم چون دیده می شه که روش صحیح صحبت در مورد طول تاخیر در بسیاری جاها شناخته نشده.
یکی از مشکلاتی که توی بیان کارایی سیستم توزیع شده داریم بحث زمان پاسخ یا همون response time هستش و برای اینکه کمی با این بحث و اهمیتش آشنا بشیم من این متن رو اینجا می‌نویسم.
همه می‌دونیم تأخیر توی سیستم‌های کامپیوتری یعنی مدت زمانی که یک پردازه دستورالعمل‌های خودش رو انجام میده و خاتمه پیدا میکنه. روش‌های متفاوتی مثل میانه، میانگین و صدک‌ها برای اندازه‌گیری تأخیر توی این سیستم‌ها مطرح می‌شن. اما بایستی ببینیم واقعاً این معیارها برای اندازه‌گیری زمان پاسخ مناسب هستند؟
دو معیار اول یا همون معیارهای میانگین و میانه روش‌های مناسبی برای توصیف طول تأخیر سیستم‌های کامپیوتری نیستن چون این روش‌ها بدترین حالت‌ها (زمان پاسخ‌های طولانی) رو توی خودشون محو می‌کنن و ابزارهای مانیتورینگی که بر این مبنا تأخیر رو محاسبه می‌کنن قادر به تشخیص موارد خاص نیستند. اگه واضح‌تر بخوام بگم فرض کنید ۲۰ تا درخواست به سیستم وارد شدن و زمان پاسخ اون‌ها به شکل زیر هستش:
۱ ، ۱ ، ۱، ۱ ، ۲ ، ۲ ، ۲ ، ۳ ،۳ ، ۳ ، ۳ ، ۳ ، ۴ ، ۴ ، ۴ ، ۴ ، ۴ ، ۵ ، ۱۵ ، ۱۶
خب اگه بخواییم میانگین زمان پاسخ رو حساب کنیم میشه حدود ۴ میلی ثانیه و ما هم خیلی خوشحالیم! اما واقعیتش اینه که دو تا زمان پاسخ خیلی بد داشتیم که یطورایی توی نتیجه محو شدن و اثری ازشون دیده نمیشه.
اگه در مقیاس وسیع نگاه کنید یک درصد چیز کمی نیست. ممکنه ۱۰۰۰ تا درخواست (کاربر) با تأخیر زیاد مواجه بشن و در نتیجه کسی از سیستم ما راضی نباشه و سراغ یک جایگزین بهتر بره (:
شاید این بحث روی نمودار جالبتر باشه. توی نمودار زیر به طور میانگین زمان پاسخ در حدود ۵۰ میلی ثانیه است و توی مواردی نادر به۱۰۰ میلی ثانیه می‌رسه.
همونطور که می‌بینید این نمودار در بدترین حالت (تأخیر زیاد) توانایی نمایش تاخیر سیستم رو نداره. حالا وضعیت سیستم رو با استفاده از یک معیار دیگه به نام صدک بررسی می‌کنیم:
اینم بگم که ما انواع مختلفی از صدک داریم که توی نمودار زیر فقط صدک ۹۹ ام تأخیر نمایش داده شده و تمرکز رو روی یک درصد زمان پاسخ خیلی بد گذاشتیم.
نمودار بالا به طور باور نکردنی با نمودار اولیه (میانگین و میانه) تفاوت داره. این نمودار بیان میکنه که در ساعت ۹:۳۶ دقیقه ۹۹ درصد مقادیر کمتر از ۸۵۰ میلی ثانیه هستن یا به عبارتی دیگه یک درصد کاربرها تاخیری بیشتر از ۸۰۰ میلی ثانیه رو تجربه کردن!
نکته‌ای که وجود داره اینه که اگه از سیستم توزیع شده استفاده کنیم این طول تأخیر تشدید میشه چون معمولاً توی این سیستم‌ها یک درخواست به چندین درخواست کوچیکتر شکسته میشه و بصورت توزیع شده روی ماشین‌های زیادی (شاید بیشتر از هزارتا) اجرا میشه و در نهایت نتیجه کل پاسخ‌ها تجمیع و به کاربر تحویل داده می‌شن.
هر چند از احتمال خیلی خوشم نمیاد ولی برای اینکه یک کم مستند صحبت کنیم فرض کنید میانگین زمان پاسخ یک سرویس دهنده ده میلی ثانیه ست اما صدک ۹۹ ام تأخیر اون برابر با یک ثانیه باشه. بنابراین یک درصد از درخواست‌ها تاخیر یک ثانیه ای را تجربه می‌کنن. حالا تصور کنید درخواست کاربر برای انجام شدن نیاز به اجرا بر روی صد سرویس دهنده رو داشته باشه. بنابراین داریم :
درخواست توسط یک گره ریشه میان تعداد زیادی ماشین توزیع میشه و برای تولید پاسخ نهایی لازمه منتظر پاسخ تمام سرویس دهنده‌ها بمونیم.
خب اول فرض‌های مسأله رو می‌نویسیم:
- احتمال اینکه «یک» سرویس دهنده به‌موقع پاسخ خود را تولید کند : ۹۹ درصد
- تعداد کل سرویس دهنده ها : ۱۰۰
حالا مسئله مشخصه و می‌تونیم با داشتن این فرض‌ها احتمال تأخیر هر درخواست رو به صورت زیر محاسبه کنیم:
خب طبق این محاسبه ۶۳ درصد کاربرها تأخیر بیش از یک ثانیه رو تجربه می‌کنن و عملاً میشه گفت سیستم شما بدرد نمی‌خوره چون بیشتر مواقع کنده (: