أعاد GitHub تصميم بنية التنقل وراء مشكلات GitHub لتقليل زمن الاستجابة المتصور للمطورين عن طريق نقل المزيد من العمل إلى جانب العميل. قدم الفريق الهندسي التخزين المؤقت من جانب العميل، والجلب المسبق التنبؤي، ومعالجة الطلبات المستندة إلى عامل الخدمة لتحسين أداء التنقل، وزيادة تجارب التنقل الفورية من 4% إلى 22%. تعالج التغييرات تحديًا شائعًا في تطبيقات الويب واسعة النطاق: تقليل التأخير الناتج عن طلبات الشبكة المتكررة وتهيئة العميل أثناء سير العمل المتكرر بشكل متكرر.
ركز العمل على مستخدمي GitHub Issues الذين يتنقلون بشكل متكرر بين المشكلات والقوائم وطرق العرض ذات الصلة، حيث يمكن إعادة استخدام المعلومات التي تم استردادها مسبقًا بدلاً من جلبها مرة أخرى من الخدمات الخلفية. لتقليل هذه التبعيات المتكررة للشبكة، اعتمد GitHub نهجًا محليًا أولاً يعرض البيانات المتاحة على الفور من المتصفح بينما تقوم العمليات الخلفية باسترداد المعلومات الأحدث عند الحاجة. تستخدم البنية طبقات تخزين متعددة من جانب العميل، بما في ذلك IndexedDB للتخزين المستمر والتخزين المؤقت في الذاكرة للبيانات التي يتم الوصول إليها بشكل متكرر أثناء الجلسات النشطة.
يُصدر GitHub بنية من جانب العميل (المصدر: منشور مدونة GitHub)
سلط BareStack الضوء على تمييز مهم حول الجلب المسبق:
يتم دفع الجلب المسبق عندما يكون الرسم البياني للبيانات صغيرًا ومثقلًا بالقراءة مثل المشكلات. تحتوي معظم التطبيقات على رسم بياني أكبر مع تصادمات القراءة/الكتابة، لذلك قد يتم إعادة جلب طرق العرض المُجلبة مسبقًا بعد الهبوط. النمط القابل لإعادة الاستخدام هو عرض الصدفة أولاً + ترطيب ذاكرة التخزين المؤقت، وليس الجلب المسبق لنفسه.
وأشار أوغوز جوفين أيضًا إلى درس أداء مهم آخر:
إن التحول من ذيل p99 إلى جودة التوزيع هو النضج الهندسي الحقيقي هنا.
يتبع نموذج التخزين المؤقت أسلوبًا قديمًا أثناء إعادة التحقق. عندما يقوم المستخدمون بإعادة زيارة المحتوى الذي تم الوصول إليه مسبقًا، يمكن للتطبيق عرض البيانات المخزنة محليًا دون انتظار استجابة الخادم. يقوم النظام بعد ذلك بإجراء مزامنة في الخلفية لتحديث المعلومات المخزنة مؤقتًا والحفاظ على الاتساق مع البيانات الخلفية.
قدم GitHub التسخين المسبق لتحسين فعالية ذاكرة التخزين المؤقت من خلال إعداد البيانات المطلوبة المحتملة قبل أن يطلبها المستخدمون، وذلك باستخدام أنماط التنقل لملء إدخالات ذاكرة التخزين المؤقت ذات الصلة. قام الفريق أيضًا بتوسيع النهج ليشمل عمال الخدمة الذين يعترضون طلبات المتصفح ويتحققون من الموارد المتاحة محليًا. يمكن عرض البيانات المخزنة مؤقتًا على الفور بينما تقوم تحديثات الخلفية بمزامنة المعلومات الأحدث. تستمر طلبات البيانات غير المتوفرة أو القديمة عبر المسار الخلفي العادي.
تدفق طلب عامل الخدمة (المصدر: منشور مدونة GitHub)
تتطلب البنية تحقيق التوازن بين الاستجابة ونضارة البيانات. بدلاً من انتظار كل تفاعل لتلقي أحدث حالة للخادم قبل العرض، سمح GitHub بعرض بعض المحتوى على الفور وتحديثه بشكل غير متزامن. يقلل هذا الأسلوب من وقت انتظار المستخدم مع الحفاظ على التزامن مع الأنظمة الخلفية.
أوضح ألكسندر ليليديس، كبير مهندسي البرمجيات في GitHub، أن الفريق نظر إلى زمن الاستجابة باعتباره أكثر من مجرد قياس، قائلًا:
الكمون ليس مجرد مقياس. إنه تبديل السياق.
قام GitHub بقياس التحسينات عبر توزيعات زمن انتقال التنقل. انخفض زمن الوصول P10 من حوالي 600 مللي ثانية إلى 70 مللي ثانية، وP25 من 800 مللي ثانية إلى 120 مللي ثانية، ومتوسط زمن الوصول من 1200 مللي ثانية إلى 700 مللي ثانية. كما تحسن زمن الاستجابة P75 وP90، حيث انخفض من 1800 إلى 1400 مللي ثانية ومن 2400 إلى 2100 مللي ثانية على التوالي.
