چه روش‌هایی برای بهینه‌سازی تأخیر سرویس تکمیل خودکار در معماری چندمنطقه‌ای ول‌هاب (Wellhub) وجود دارد؟

نکات کلیدی

• ول‌هَب یک معماری چندمنطقه‌ای برای سرویس تکمیل خودکار مبتنی بر زبان گو (Go) اتخاذ کرد و از الاستیک‌سرچ (Elasticsearch) برای پیش‌بینی ورودی کاربر و بهبود مرتبط‌بودن نتایج جست‌وجو با استفاده از پرس‌وجوهای جغرافیایی بهره گرفت.

• از AWS Global Accelerator برای مسیریابی کارآمد ترافیک استفاده شد؛ با بهره‌گیری از آی‌پی‌های ثابت و بهینه‌سازی‌های TCP برای تضمین اتصال کم‌تأخیر به نزدیک‌ترین نمونهٔ سرویس.

• تکثیر داده از طریق قابلیت تکثیر بین‌منطقه‌ای AWS S3 انجام شد، به‌طوری که پشتیبان‌ها بتوانند در مناطق مختلف بازیابی شوند و با نیازمندیِ به‌روزرسانی‌های غیرِبلادرنگ هم‌راستا باشد.

• حتی پس از استقرار معماری چندمنطقه‌ای، تأخیر با معرفی یک نقطهٔ پایانی پیش‌واکشی (pre-fetch endpoint) باز هم کاهش یافت؛ کاری که عملکرد ادراک‌شده را بهتر کرد و تجربهٔ کاربری را در همهٔ مناطق بهبود داد.

• بهینه‌سازی‌های شبکهٔ موبایل، مانند کاهش پولینگ (polling) و دسته‌بندی درخواست‌ها (batching)، به ارائهٔ سریع‌تر و کارآمدتر سرویس روی دستگاه‌های موبایل منجر شد.

هر شرکتی سرویس‌هایی سریع، با دسترس‌پذیری بالا و کم‌تأخیر می‌خواهد. ما مهندسان هم همین آرزو را داریم. اما همان‌طور که قضیهٔ معروف می‌گوید: «ناهار رایگان وجود ندارد». رسیدن به این اهداف نیازمند سرمایه‌گذاری و تلاش قابل توجه است. در این مقاله، توضیح می‌دهم که ول‌هَب چگونه روی یک معماری چندمنطقه‌ای سرمایه‌گذاری کرد تا به یک سرویس تکمیل خودکار کم‌تأخیر برسد. دربارهٔ راهبردهایی که اتخاذ کردیم، درس‌هایی که گرفتیم و پیشنهادهایی که بر اساس این تجربه‌ها داریم صحبت می‌کنم.

زمینه (Context)

سرویس تکمیل خودکار، که با Go توسعه داده شده است، با دریافت یک ورودی متنی کوتاه کار می‌کند و ادامهٔ مورد نظر کاربر را پیش‌بینی می‌کند. این رویکرد با کاهش «نتیجهٔ صفر» ناشی از غلط‌های املایی و ایجاد تجربه‌ای روان‌تر، تجربهٔ جست‌وجو را بهبود می‌دهد. برای مثال، تایپ کردن «Yo» ممکن است پیشنهادهایی مانند «Yoga» و «Yoga for Kids» را برگرداند. همچنین از قابلیت پرس‌وجوهای جغرافیایی الاستیک‌سرچ (geo queries) استفاده می‌کنیم تا با شخصی‌سازی پیشنهادها بر اساس موقعیت کاربر، میزان مرتبط‌بودن را بهتر کنیم.

این سرویس فقط کمک نمی‌کند کاربران سریع‌تر چیزی را که می‌خواهند پیدا کنند؛ بلکه مقدار قابل توجهی ترافیک را از زیرساخت اصلی جست‌وجوی ما دور می‌کند و کارایی کلی سامانه را افزایش می‌دهد. حدود ۶۶٪ از تکمیل‌های خودکار، با در نظر گرفتن جست‌وجوهای یکتا، به کلیک‌هایی منجر می‌شوند که کاربر را به یک صفحهٔ اختصاصی هدایت می‌کنند و از نتایج جست‌وجو عبور می‌دهند. این موضوع فرایند جست‌وجو را ساده‌تر و بهینه‌تر می‌کند.

پیش از پیاده‌سازی معماری چندمنطقه‌ای، راهکارهای دیگری را هم بررسی کردیم؛ به‌خصوص چون زمان پردازش سرویس حدود ۱۵ میلی‌ثانیه است و فضای کمی برای بهبود باقی می‌گذارد. یکی از گزینه‌هایی که بررسی کردیم استفاده از ژئوهشینگ (geohashing) برای یک کش بهینه در شبکهٔ تحویل محتوا (CDN) بود که در مورد ما Amazon CloudFront است. اما به دلیل تغییرپذیری بالای داده، این رویکرد ناکارآمد بود. تحلیل ما نشان داد با زمان ماندگاری (TTL) برابر ۷ روز و طول ژئوهش ۵، نرخ موفقیت فقط ۲۸٪ است؛ که نمایانگر یک ناحیهٔ شبکه‌ای تقریباً ۴,۸۹ کیلومتر در ۴,۸۹ کیلومتر (۳,۰۳ مایل) است.

با توجه به توزیع جهانی کاربران، به این نتیجه رسیدیم که نزدیک‌تر کردن داده به آن‌ها مؤثرترین راهکار است.

طراحی یک سامانهٔ چندمنطقه‌ای برای تکمیل خودکار سریع

ما یک RFC توسعه دادیم که ساخت یک معماری چندمنطقه‌ای را پیشنهاد می‌داد و این کار به همکاری تیم پلتفرم ما نیاز داشت. مهاجرت سرویس نسبتاً ساده بود: تعریف‌های Helm chart را تکثیر کردیم، کاربران را ساختیم، سیاست‌ها را در مناطق جدید اعمال کردیم و همهٔ کلیدها را داخل Vault پیکربندی کردیم. با این وجود، مثل تقریباً هر مهاجرتی، چالش اصلی مدیریت داده است.

در ابتدا استفاده از Elasticsearch Cross-Cluster Replication را بررسی کردیم؛ به خاطر قابلیت‌های دوطرفه بودن، زنجیره‌ای بودن و بازیابی بحران. اما این قابلیت‌ها برای نیاز ما ضروری نبودند و علاوه بر آن نیاز به خرید مجوز داشتند. منطق ما بر اساس بسامد به‌روزرسانی ایندکس‌ها، تازگیِ مورد نیاز داده و این واقعیت بود که لازم نیست همهٔ مناطق کاملاً همگام‌سازی شوند.

به‌عنوان یک بهترین‌رویه، ما پشتیبان‌های روزانه را داخل AWS S3 ذخیره می‌کنیم که با یک کران‌جاب (cron job) اجرا می‌شود و از ایندکس‌ها اسنپ‌شات می‌گیرد تا برای بازیابی بحران استفاده شود. نکتهٔ کلیدی این بود که متوجه شدیم AWS S3 قابلیت تکثیر بین‌منطقه‌ای (Cross-Region Replication) دارد. می‌توانستیم این اسنپ‌شات‌ها را از منطقهٔ اصلی‌مان در ویرجینیا (آمریکا) به مناطق دیگر مانند سائوپائولو (برزیل) و دوبلین (ایرلند) بازیابی کنیم.

Figure 1: معماری سرویس تکمیل خودکار چندمنطقه‌ای

همان‌طور که در بخش زمینه گفته شد، داده‌های تکمیل خودکار ما متعلق به شرکا و فعالیت‌های آن‌هاست. در حالی که تغییراتی مثل به‌روزرسانی نام، اضافه شدن فعالیت‌ها و ورود/خروج شریک‌ها رخ می‌دهد، اما نیازی به به‌روزرسانی نزدیک به بلادرنگ ندارند. کاربرانی را در بارسلونا در نظر بگیرید که به دنبال فعالیت‌ها می‌گردند؛ آن‌ها لازم نیست بلافاصله بدانند آیا یک شریک در لس‌آنجلس فعالیت جدیدی اضافه کرده است یا نه، مگر این‌که به آن‌جا سفر کنند که کمتر رایج است. بنابراین به این نتیجه رسیدیم که حداکثر تأخیر تکثیر یک روز برای نیاز ما قابل قبول است.

ما دو کران‌جاب روزانه داریم؛ اولی در منطقهٔ اصلی اسنپ‌شات‌ها را ایجاد می‌کند و آن‌ها را داخل یک باکت AWS S3 ذخیره می‌کند. کار دوم، که در مناطق دیگر اجرا می‌شود، فرایندی متفاوت دارد. این فرایند از یک پایپ‌لاین کوچک ساخته‌شده با Curator استفاده می‌کند تا مدیریت خطا و کنترل بهتر باشد، به‌خصوص از دید API. شاید بپرسید API چطور از یک ایندکس جدید باخبر می‌شود اگر در هر عملیات بازیابی لازم باشد یکی بسازیم. این‌جا قابلیت alias در الاستیک‌سرچ بسیار ارزشمند می‌شود. ما از alias برای مدیریت این‌که کدام ایندکس زیرین هدف قرار بگیرد استفاده می‌کنیم. پایپ‌لاین با بازیابی اسنپ‌شات به یک ایندکس موقت شروع می‌کند. سپس در یک عملیات اتمی، alias را از ایندکس اصلی به ایندکس موقت سوییچ می‌کنیم تا اطمینان حاصل شود جدیدترین داده استفاده می‌شود. بعد، ایندکس اصلی را دوباره ایندکس‌گذاری (reindex) می‌کنیم، alias را برمی‌گردانیم و ایندکس موقت را حذف می‌کنیم. کل این فرایند بدون ایجاد اختلال در سرویس اتفاق می‌افتد و اجازه می‌دهد بدون وقفه به درخواست‌ها پاسخ بدهیم. همچنین شامل مدیریت خطای درست، استفاده از retry و timeout و ابزارگذاری مناسب برای مشاهده‌پذیری است.

Figure 2: پایپ‌لاین تکثیر داده

راهبرد تکثیر دادهٔ ما کارآمد و کم‌هزینه است و نیازی ندارد کلاسترها همدیگر را بشناسند یا راهبرد رهبر/پیرو (leader/follower) پیاده‌سازی شود. پردازش ساده است چون تنها تغییری که لازم است انجام شود، احراز هویت به یک کلاستر متفاوت با استفاده از اعتبارنامه‌های ارائه‌شده توسط Vault است. اما ممکن است این سؤال پیش بیاید: ما چطور این داده را سرو می‌کنیم؟ آیا برنامهٔ ما همهٔ endpointها را هاردکد کرده است؟ چطور تصمیم می‌گیریم کاربر به کدام منطقه مسیردهی شود؟

AWS Global Accelerator با استفاده از آی‌پی‌های ثابت و مسیردهی سفارشی، ترافیک را به‌صورت قطعی به نمونه‌های سرویس ما مسیردهی می‌کند. با بهره‌گیری از توان شبکهٔ جهانی AWS، عملکرد را به‌طور قابل توجهی بهتر می‌کند: با کاهش تأخیر اولین بایت، کم کردن جیتر و افزایش گذردهی، تجربه‌ای سریع‌تر و یکنواخت‌تر نسبت به اینترنت عمومی ارائه می‌دهد. این سرویس در لبهٔ شبکه پایان‌دهی TCP انجام می‌دهد و با استفاده از traffic dialها ترافیک را به نزدیک‌ترین منطقه هدایت می‌کند و failover سریع بین مناطق فراهم می‌سازد. این کار به ما اجازه می‌دهد داخل اپلیکیشن موبایل یک endpoint واحد داشته باشیم و نیاز به مدیریت دستی مسیردهی را حذف کنیم.

استفاده از AWS Global Accelerator بهبود عملکردی‌ای را که نیاز داشتیم فراهم کرد، همراه با یک مزیت غیرمنتظره: کنترل ریزدانه روی مسیردهی. این انعطاف‌پذیری در مسیردهی به ما اجازه داد مهاجرت‌ها را بدون اصطکاک انجام دهیم، قابلیت‌ها را به‌صورت تدریجی و منطقه‌به‌منطقه عرضه کنیم و توزیع ترافیک را کنترل کنیم؛ یعنی درصد ترافیکی که به مناطق مختلف هدایت می‌شود را بسته به نیاز تنظیم کنیم. درک عمیق از مبانی شبکه برای ساخت و نگه‌داری یک سرویس کم‌تأخیر حیاتی است.

بلوک‌های سازندهٔ عملکرد بالا

یکی از نکاتی که می‌خواهم در این مقاله روی آن تأکید کنم اهمیت توجه به تک‌تک مؤلفه‌ها، جزئی‌نگری و درک زمینه برای یافتن راهکارهای بهینه است. رسیدن به این موضوع نیازمند تحقیق کامل است. بخش بعدی بر اساس کتاب کلاسیک High Performance Browser Networking نوشتهٔ Ilya Grigorik است. این کتاب برای هر مهندس و مدیری که دغدغهٔ ارائهٔ نرم‌افزار باکیفیت دارد، خواندنیِ ضروری است. بیایید به‌صورت کوتاه برخی از این جنبه‌ها را مرور کنیم.

پروتکل کنترل انتقال (TCP)

TCP یک پروتکل فوق‌العاده است که امکان تنظیم دقیقِ سازوکارهای داخلی‌اش را برای بهینه‌سازی انتقال داده فراهم می‌کند. برای مثال، افزایش پنجرهٔ اولیهٔ ازدحام TCP (initial congestion window) امکان انتقال دادهٔ بیشتر در نخستین رفت‌وبرگشت را فراهم می‌کند و رشد پنجره را بهبود می‌دهد. غیرفعال کردن slow-start بعد از idle می‌تواند عملکرد اتصال‌های TCP با عمر طولانی را بهتر کند. مقیاس‌دهی پنجره (window scaling) در اتصال‌های با تأخیر بالا گذردهی را بهتر می‌کند و TCP Fast Open گاهی می‌تواند داده را همراه با بستهٔ SYN ارسال کند.

AWS Global Accelerator چندین مورد از این بهینه‌سازی‌ها را در خود دارد. از یک پنجرهٔ بزرگ سمت دریافت و بافرهای TCP، یک پنجرهٔ ازدحام بزرگ و پشتیبانی از jumbo frameها بهره می‌گیرد و این امکان را می‌دهد که در هر بسته شش برابر دادهٔ بیشتر ارسال کند. این ویژگی‌ها در کنار هم عملکرد و کارایی انتقال داده در سراسر شبکه را افزایش می‌دهند.

ما معمولاً روی بک‌اند تمرکز می‌کنیم، اجرای پرس‌وجوها را بهینه می‌کنیم، کش اعمال می‌کنیم یا کل سرویس را بازنویسی می‌کنیم. با این حال، مؤلفه‌های دیگر هم در این معادله نقش دارند.

شبکه‌های موبایل

هنگام کار با اپلیکیشن‌های موبایل، مهم است در نظر بگیرید که یک اتصال واحد فقط از طریق کابل‌های فیبر نوری با سرعت نور جریان ندارد. بله، یک بستهٔ داده می‌تواند با فیبر نوری تقریباً در ۲۰۰ میلی‌ثانیه دور محیط استوایی زمین با طول حدود ۴۰,۰۷۵ کیلومتر (۲۴,۹۰۱ مایل) را طی کند (۱۳۳,۷ میلی‌ثانیه در خلأ). اما شبکه‌های موبایل مؤلفه‌های اضافی‌ای دارند که روی عملکرد اثر می‌گذارند.

معماری اپراتور (Carrier architecture)

معماری اپراتور یکی از مؤلفه‌هایی است که هنگام ساخت یک اپلیکیشن موبایل با عملکرد بالا باید در نظر گرفته شود. این معماری‌ها می‌توانند از اپراتوری به اپراتور دیگر و در فناوری‌هایی مانند 4G و 5G تفاوت زیادی داشته باشند. معماری سطح‌بالای یک شبکهٔ LTE معمولاً شامل شبکهٔ دسترسی رادیویی (RAN) و شبکهٔ هسته (CN) است.

شبکهٔ دسترسی رادیویی ترافیک بسته‌های داده را میانجی‌گری می‌کند و دسترسی دستگاه‌های کاربر به کانال رادیویی رزروشده را فراهم می‌کند. همچنین موقعیت همهٔ کاربران را به شبکهٔ هسته اطلاع می‌دهد. این ضروری است چون یک کاربر می‌تواند به هر دکل رادیویی متصل باشد و با حرکت کاربر، جابه‌جایی میان دکل‌ها (handover) باید مدیریت شود. نکتهٔ جالب این است که اگر به نمایش RAN که از «سلول» استفاده می‌کند نگاه کنید، می‌فهمید چرا به آن‌ها تلفن همراه (cell phone) می‌گوییم.

Figure 3: یک معماری سادهٔ LTE

شبکهٔ هسته مسئول مسیردهی داده، حسابداری و مدیریت سیاست‌هاست و عملاً شبکهٔ رادیویی را به اینترنت عمومی متصل می‌کند. این شبکه از چندین مؤلفه تشکیل می‌شود که هرکدام برای کارکرد شبکه حیاتی‌اند:

The Packet Gateway (PGW): اتصال به اینترنت عمومی را مدیریت می‌کند، از جمله تخصیص آدرس IP به دستگاه‌ها. همچنین پالایش بسته، بازرسی و محافظت در برابر حملات محروم‌سازی از سرویس (DoS) را انجام می‌دهد.
The Mobility Management Entity (MME): مانند یک پایگاه دادهٔ کاربران عمل می‌کند و اطلاعات مربوط به موقعیت آن‌ها، نوع حساب و وضعیت صورتحساب را نگه می‌دارد.
The Serving Gateway (SGW): وقتی PGW یک بسته دریافت می‌کند، برای تعیین موقعیت کاربر به SGW متکی است. SGW از MME پرس‌وجو می‌کند و یک اتصال با دکل رادیویی مناسب برقرار می‌کند تا داده ارسال شود و ارتباط بی‌وقفه در سراسر شبکه تضمین شود.

این فرایند پیچیده اما شفاف، به‌شدت روی تأخیر و عملکرد اپلیکیشن موبایل شما اثر می‌گذارد.

کنترل‌کنندهٔ منابع رادیویی (RRC)

مؤلفهٔ دیگر کنترل‌کنندهٔ منابع رادیویی (RRC) است که اتصال‌ها میان دستگاه و ایستگاه پایهٔ رادیویی را مدیریت می‌کند و روی تأخیر، گذردهی و عمر باتری اثر می‌گذارد. برای مدیریت انتقال داده روی یک کانال بی‌سیم، RRC باید یا منابع تخصیص دهد یا دستگاه را دربارهٔ بسته‌های ورودی آگاه کند. RRC از یک ماشین حالت استفاده می‌کند که منابع رادیویی قابل دسترس را در هر حالت تعریف می‌کند و روی عملکرد و مصرف انرژی اثر می‌گذارد. حالت‌های کلیدی شامل RRC Idle و RRC Connected هستند. این حالت‌ها با timeoutها کنترل می‌شوند. برای مثال، در یک اتصال HSPA+، حالت از توان بالا، با منابع اختصاصی بالادست و پایین‌دست شبکه، بعد از ۱۰ ثانیه عدم فعالیت به حالت توان پایین‌تر تغییر می‌کند. این حالت توان پایین‌تر انرژی کمتری مصرف می‌کند اما به یک کانال اشتراکی محدود و کم‌سرعت (کمتر از ۲۰ کیلوبیت بر ثانیه) متکی است. اگر پس از این انتقال یک درخواست داده رخ دهد، باعث بازگشت به حالت توان بالا می‌شود. این فرایند مذاکره چندین میلی‌ثانیه طول می‌کشد، تأخیر را افزایش می‌دهد و عمر باتری را کاهش می‌دهد.

ریزتنظیم برای سرعت و کارایی

ادبیات مربوط به بهینه‌سازی شبکه‌های موبایل چند نکتهٔ مهم برای ارزیابی ارائه می‌کند. یکی از جنبه‌های مهم کمینه‌سازی پولینگ است، چون پولینگ مکرر در شبکه‌های موبایل فوق‌العاده پرهزینه است. در عوض توصیه می‌شود تا جای ممکن از ارسال پوش (push delivery) و اعلان‌ها استفاده شود. همچنین درخواست‌های خروجی و ورودی باید تجمیع و یکپارچه شوند تا تعداد انتقال‌ها کاهش یابد. درخواست‌های غیرحیاتی باید تا زمانی که رادیو از قبل فعال است به تعویق بیفتند تا مجبور نشویم برای عملیات‌های کوچک رادیو را از خواب بیدار کنیم.

حذف keepaliveهای غیرضروری اپلیکیشن نیز حیاتی است، زیرا شبکهٔ اپراتور چرخهٔ عمر اتصال را مستقل از وضعیت رادیوی دستگاه مدیریت می‌کند. پیش‌بینی سربار تأخیر شبکه نکتهٔ مهم دیگری است. برقراری یک اتصال جدید با در نظر گرفتن کنترل پلین، جست‌وجوی DNS، دست‌دادن TCP، دست‌دادن TLS و درخواست HTTP می‌تواند در 4G تا ۶۰۰ میلی‌ثانیه و در 3G تا ۳۵۰۰ میلی‌ثانیه طول بکشد. یک راهبرد مؤثر که ما اتخاذ کردیم این بود که دقیقاً پیش از تعامل کاربر با یک مؤلفهٔ ورودی، یک درخواست «خالی» ارسال کنیم تا اتصال از قبل آماده شود و درخواست‌های بعدی سریع‌تر شوند.

همچنین مفید است انتقال‌های داده را به‌صورت دسته‌ای انجام دهید؛ یعنی هرچه می‌توانید سریع مقدار زیادی داده دانلود کنید و سپس اجازه دهید رادیو به حالت idle برگردد. این رویکرد گذردهی و عمر باتری را به حداکثر می‌رساند، چون رابط رادیویی موبایل برای چنین الگویی بهینه شده است و بهبودهای قابل توجهی در عملکرد و کارایی برای اپلیکیشن‌های موبایل ایجاد می‌کند.

اندازه‌گیری اثر بهینه‌سازی‌های ما

پیش از پیاده‌سازی معماری چندمنطقه‌ای، کاربران ما تأخیر p90 برابر ۶۰۰ تا ۷۰۰ میلی‌ثانیه را تجربه می‌کردند؛ همان‌طور که در شکل‌های ۴ و ۵ مشخص است، که تجربهٔ ضعیفی ایجاد می‌کرد. این سطح از تأخیر به‌طور جدی روی کارکرد سرویس تکمیل خودکار ما اثر می‌گذاشت. انتظار کشیدن به این مدت برای تکمیل خودکار یک عبارت ضدبهره‌ور است، چون کاربران ممکن است ترجیح دهند کل متن را خودشان تایپ کنند، حتی با ریسک غلط تایپی.

پس از آن، تأخیر بهتر شد، اما نه به اندازه‌ای که امیدوار بودیم. در p90 حدود ۲۰۰ میلی‌ثانیه کاهش پیدا کرد؛ به‌طور قابل توجهی بهتر از قبل، اما با توجه به سرمایه‌گذاری انجام‌شده برای راه‌اندازی چندمنطقه‌ای، هنوز به اندازهٔ انتظار پایین نبود. هدف ما رسیدن به تأخیری در حدود ۱۰۰ میلی‌ثانیه بود تا «لحظه‌ای» محسوب شود.

سپس تصمیم گرفتیم سربار تأخیر شبکه را با پیاده‌سازی یک نقطهٔ پایانی پیش‌واکشی (pre-fetch endpoint) که در بخش بهینه‌سازی ذکر شد پیش‌بینی کنیم. بعد از این تغییر، تأخیر در p90 به ۱۲۳,۳ میلی‌ثانیه روی iOS و ۱۳۴,۶ میلی‌ثانیه روی Android رسید. نقطهٔ پایانی پیش‌واکشی تمام کارهای سنگین را انجام می‌دهد، با تأخیر p90 برابر ۵۶۱ میلی‌ثانیه روی Android و ۴۷۱ میلی‌ثانیه روی iOS. اما این بار کاربر آن را حس نمی‌کند، چون درخواست به‌صورت پیش‌دستانه و دقیقاً در زمان مناسب ارسال می‌شود.

Figure 4: تفکیک تأخیر ادراک‌شده قبل و بعد از معماری چندمنطقه‌ای برای iOS

Figure 5: تفکیک تأخیر ادراک‌شده قبل و بعد از معماری چندمنطقه‌ای برای Android

تغییر مهم دیگری که از پروژه حاصل شد، تغییر محسوس در الگوهای استفاده از شبکه بود. در میان کاربران iOS، استفاده از وای‌فای از ۶۳,۴۷٪ به ۴۹,۳۳٪ کاهش یافت، که نشان می‌دهد کاربران بیشتری اکنون از شبکه‌های موبایل خود برای دسترسی به اپلیکیشن استفاده می‌کنند. این تغییر با افزایش استفاده از LTE نیز پشتیبانی می‌شود که از ۲۴,۵۸٪ به ۲۹,۳۰٪ افزایش یافت.

کاربران Android نیز مزایای مشابهی دیدند؛ استفاده از وای‌فای از ۶۷,۰۸٪ به ۵۱,۱۸٪ کاهش یافت. در همین حال، استفاده از LTE از ۳۰,۳۱٪ به ۴۴,۴۶٪ افزایش پیدا کرد. این تغییرات نشان می‌دهد که بهینه‌سازی شبکه به کاربران اجازه داده بیش از قبل به شبکه‌های موبایل تکیه کنند و تجربهٔ کلی آن‌ها بهبود پیدا کند.

Figure 6: تأخیر ادراک‌شده توسط کاربران قبل و بعد از پروژهٔ چندمنطقه‌ای

جمع‌بندی

به سبک سقراطی، «فهمیدن سؤال نصف پاسخ است». هر قطعه نرم‌افزار، با وجود پیروی از چندین الگوی رایج، منحصر به فرد است. این یکتایی از عوامل مختلفی ناشی می‌شود، مانند نیازمندی‌های کسب‌وکار، محدودیت‌های فناوری و تیمی که آن را می‌سازد. نکتهٔ کلیدی ارزیابی و تحلیل نظام‌مند موازنه‌هاست.

بهینه‌سازی یک سرویس با رویکرد چندمنطقه‌ای ممکن است برای بسیاری از موارد کاربرد بهترین انتخاب نباشد یا در برخی موارد پیچیده‌تر و دشوارتر برای پیاده‌سازی باشد. در مورد ما، این معماری به کاهش‌های قابل توجهی در تأخیر منجر شد که در ابتدا انتظار داشتیم، اما پژوهش بیشتر نشان داد که یک تکنیک ساده یعنی پیش‌واکشی (pre-fetching) می‌تواند تأخیر ادراک‌شده را حتی بیشتر کاهش دهد.

گام‌های آینده می‌تواند شامل تحلیل عمیق‌تر با استفاده از معیارهای مقاوم‌تر و مناسب برای چنین سامانه‌هایی باشد، مانند Minimum Keystroke Length (MKS) و Effort Saved (e-Saved). هر دو معیارهای کمک به کاربر هستند که اندازه می‌گیرند سرویس چقدر مفید است: برای مثال e-Saved نسبتِ تعداد کاراکترهایی را نشان می‌دهد که کاربر برای کامل کردن یک پرس‌وجو مجبور نیست تایپ کند. افزون بر این، بهبود مشاهده‌پذیری با تفکیک شاخص‌ها در مناطق مختلف می‌تواند الگوهای دسترسی متفاوتی را آشکار کند که شاید به بهینه‌سازی‌های منطقه‌محور نیاز داشته باشد.