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