ربما يكون من الصحيح القول أنه إذا سألت مستخدما عاديا عما يجعل تطبيق الويب رائعا ، فمن المحتمل أن يقول “السرعة”. لكن السرعة هي على الأرجح الجانب الأقل أهمية في مجموعة واسعة من العناصر. من المحتمل أن تكون عوامل مثل تطوير التطبيقات وتقديمها في البرنامج أعلى في تلك القائمة. وما الذي يشكل تطبيقا رائعا للأداء؟ وعندما يحدث خطأ ما ، كيف تعرف؟ هذه هي بعض الأسئلة التي تكدس مراقبة التتبع ومراقبة أداء تطبيقات الويب الاصطناعية التي تم تحديدها للإجابة عليها. كلاهما له مزاياه وعيوبه ، ولكن هذه المقالة ستنطلق لشرح ما الذي يجعل أداة أفضل لضمان وضع تجربة المستخدم في طليعة تحديد ما الذي يجعل تطبيق الويب رائعا.
ما هو تتبع المكدس؟
تتبع المكدس هو أداة تحقيق مفيدة. إنه يعرض “Call Stack” ، وهي أكوام من الوظائف / المنهجيات التي تم استدعاؤها حتى الحالة الحالية لتنفيذ البرنامج ، في الوقت الذي تم فيه إلقاء حالة خاصة غير معروفة من قبل المترجم (أو اللحظة التي تم فيها إنتاج مسار المكدس جسديا).
هذا أمر ذو قيمة استثنائية لأنه لا يمنحك فقط مكان حدوث الخطأ ، بل يمكن أن يمنحك أيضا نظرة ثاقبة حول كيفية انتهاء البرنامج في تلك البقعة من البرنامج. الهدف من ذلك هو توفير الطرق التي تم استدعاؤها حتى النقطة التي تعطل فيها البرنامج ويعطي متهدمة من استدعاءات الطريقة التي كان التطبيق يواجهها. إنه يساعدنا في فهم كيفية تحول شيء ما بالطريقة التي حدث بها ، ويعرض فرصة لتصحيح الخطأ. وبدون هذا التعقب، فإن هذه الإجراءات لن يكون مصيرها، وستصبح أي أخطاء صامتة. تصبح الخدمة لاحقا ما يشار إليه بشكل بارز باسم “الصندوق الأسود”.
ما هو الاستثناء؟
الاستثناء هو الشيء الذي يستخدمه شرط وقت التشغيل لإبلاغنا بأنه تمت مواجهة خطأ. النماذج المعروفة هي NullPointerException أو IndexOutOfBoundsException أو ArithmeticException. يحدث كل من هذه عندما تحاول إنجاز شيء لا يمكن تصوره حرفيا (بواسطة الكمبيوتر الموجود). على سبيل المثال ، سيتم رمي NullPointerException بمجرد محاولة الإشارة إلى مقالة غير صالحة
الصورة أعلاه تصور تتبع مكدس. نبدأ نحو بداية المتهدمة من “في…“، يمكننا معرفة مكان حدوث الخطأ. ما نحاول اكتشافه هو اللقاء الأول لاستدعاء طريقة ، والتي يمكن أن تكون جزءا من تطبيقنا أو جزءا من الوحدات المستخدمة في التطبيق. في هذه الحالة ، يكون الجاني “في com.example.myproject.Book.getTitle(كتاب.java:16).” يمكننا بالتالي فتح الكتاب.java وألق نظرة على السطر 16. هذه حالة أساسية لما يحدث عندما نتتبع مكدسا.
وبالمثل ، يمكن أيضا أن يحدث ذلك من خلال سلسلة من الإعفاءات مثل ما يلي:
الجاني في هذه الحالة هو المكان الذي يبدأ فيه في “سبب: java.lang. NullPointerException على com.example.myproject. Book.getId(Book.java:22) على com.example.myproject. Author.getBookIds(المؤلف.java:36)”
ما يميز هذا هو شرط “الناجم عن“. من حين لآخر ، سيكون للإعفاءات مجالات مختلفة “ناجمة عن“. في بعض الحالات ، تحتاج إلى البحث عن “السائق الأساسي” ، والذي يمكن أن يكون واحدا من العديد من هذه الأجزاء داخل المسار الخلفي.
كيف يؤثر رمز الطرف الثالث على تراجع المكدس
غالبا ما تحتوي التطبيقات الحالية على طبقات عديدة من استدعاء الوظائف التي يتم تشغيلها بطريقة متقاطعة (أي وظيفة تستدعي الآخرين أو في بعض الحالات نفسها). لجعل الأمور مربكة بشكل متزايد ، لدينا بانتظام العديد من طبقات التعليمات البرمجية للبرمجة التي تضيف إلى مكدس المكالمات. يمكن أن تقلل التعليمات البرمجية من وقت التشغيل أو المكتبات المستوردة من نقاء مكدس المكالمات الخاص بنا ، مما يجعل من الصعب الاطلاع عليها أو فك تشابكها أثناء إصلاح الاستثناءات. الآن قد تفكر ، “ماذا تفعل كتلة الإخراج هذه لمساعدتي في تحديد الأخطاء؟”
كيف تساعد مكدسات المكالمات وتتبعها في التنفيذ
حتى هذه اللحظة ، تحدثنا في الغالب عن حوادث التعليمات البرمجية ، وليس التنفيذ. عند ظهور خطأ ، نحتاج إلى عزل الظروف التي تشمل مظهره وإعادة تشغيلها لإعادة إنتاج الخطأ. وفي حالة الأداء ، نحتاج إلى نهج لإنجاز التقنيات المذكورة أعلاه أيضا. علينا محاكاة الظروف الإطارية الحالية ، وإعادة النظر في ظروفنا الحالية ، وإجراء التغييرات اللازمة ، وإعادة معاينات ظروف الإطار الحالية لتحليل النتائج.
يبدأ ضبط التنفيذ باكتشاف وتقدير وترقية للتخفيف من أكبر الاختناقات أولا. بصفتنا منتجين لأي وحدة ضبط أداء ، يجب أن نعرف هذا الإجراء الخاص بالقياس والتحديث والتحسين بشكل جيد للغاية. هذه هي اللحظة التي يمكن أن تساعدنا فيها مكدسات المكالمات في فحص هذه العملية. للحصول على المعلومات التي تم جمعها ، نستخدم بشكل أساسي التنميط العام كممارسة لنا. عند النقطة التي يحدث فيها ملف التعريف ، فإنه يأخذ صورا عرضية للحالة الحالية لمكدس المكالمات. عند النقطة التي نحصل فيها على لقطة من المعلومات ، نكون مستعدين لرؤية كتل التعليمات البرمجية التي تظهر مرارا وتكرارا ، وبهذه الطريقة قد يشكل التتبع إمكانية لتحسين الأداء. ولكن للتأكد تماما ، سيتعين علينا فهم إجراءاتنا لإجراء قياسات إطار النظام هذه. ومع ذلك ، هناك مشكلة هنا. تتبع المكدس له حدوده الخاصة. يتضمن التطبيق المتطور العديد من الحسابات ، وبالتالي ، العديد من مكدسات المكالمات. إذن كيف سنقوم بشكل معقول بالتصفية من خلال وفهم جبال المعلومات؟
قيود تتبع المكدس
من حين لآخر ، لا يمكنك التأكد من عدم حصولك على خطأ. على سبيل المثال ، في حالة عدم وجود فرصة لاستخدام تطبيق مدفوع بالويب في برنامجك ، لا يمكنك منع الكمبيوتر من فقدان ارتباطه بالويب (على سبيل المثال ، لا يمكنك منع العميل من فك ارتباط شبكة نظام الكمبيوتر). ما يحدث الآن هو أن مكتبة النظام تعاملنا مع إعفاء. في عالم مثالي ، هذه هي النقطة التي “يلتقط” فيها المهندسون الحالة الخاصة ويديرونها. هذا يعني أنه في النموذج مع اقتران الشبكة ، يجب أن تحاول إحياء الجمعية أو إبلاغ العميل. يجب أن يتذكر المهندس أثناء الحصول على الإعفاء ، أنهم استولوا على الحالة التي توقعوها ، لذلك يجب ألا يستخدموا إعلانات واسعة النطاق مثل “Exception e” التي من شأنها الحصول على جميع الإعفاءات. اتضح أن هذا عامل محوري في إعادة تتبع المكدس. إنه لا يلتقط الحالات الخاصة التي كان لا بد من معالجتها بطريقة معينة ، ولكن تم الاعتناء بها بطريقة مختلفة تماما.
أدوات تتبع المكدس ليست مضمونة قليلا من حيث مراقبة التطبيقات. من الصعب تجميع المحتويات ، ويصعب فهمها وتفكيكها ، وعرضة للأخطاء الشاملة.
المراقبة الاصطناعية
على عكس أدوات تتبع المكدس ، تعمل المراقبة الاصطناعية عن طريق إنشاء تبادلات / معاملات مستخدم محاكية لتطبيقك والتي تنتحل شخصية كيف يمكن للمستخدم العادي أو العميل السير عبر تطبيقك. يمكن تطبيقه داخل جدار الحماية ، داخل مساحة الخادم لضمان تشغيل جميع الأجهزة بشكل مناسب ، أو خارج جدار الحماية لإعطاء بيانات حول إمكانية الوصول والتنفيذ من وجهة نظر عالمية. تصبح مكالمات الخادم هذه ومحتويات الاختبار “أدوات” للمراقبة من خلال تشغيلها بترددات محددة مسبقا ، مثل كل 5 دقائق أو كل 3 ساعات.
يمكن أن يكون هذا النوع من المراقبة أساسيا لعملك لأنه يسمح لك بتمييز المشكلات ومسح ما إذا كان موقعك أو تطبيقاتك بحاجة إلى تعديل قبل أن يتأثر العملاء النهائيون حقا. نظرا لأن هذا النوع من التحقق لا يعتمد على حركة مرور الويب الحقيقية ، يمكن مراقبة تطبيق الويب أو الصفحة في أي وقت ومن أي مكان ، ويمكن إعداد وكلاء المراقبة قبل دخول التطبيقات في الإنتاج. هذا هو السبب في أن الكثير من المطورين يميلون إلى المراقبة الاصطناعية ، لأنها تعطي رؤية 24 / 7 وتوفر النفوذ للمؤسسة لإصلاح الأخطاء قبل أن يتعثر العملاء فيها.
هل تحتاج إلى مراقبة اصطناعية؟
الإجابة الأقل تعقيدا على هذا السؤال هي أنك بحاجة إلى مساعدة لضمان أن تطبيقك أو موقعك جاهز للعمل. ولكن من الناحية الفنية أكثر بكثير، فإن الرد الحقيقي على هذا التحقيق يذهب إلى أبعد من ذلك بكثير. لا يقوم وكيل مراقبة الجودة ببساطة باختبار موقعك للتأكد من توفره. ستقوم إدارات الجودة بالتحقق من سجلات إطار اسم المنطقة وسرعة النقل وقاعدة البيانات بالإضافة إلى توفر النظام وتحميل وحدة المعالجة المركزية وتخزين محرك الأقراص والأحداث وذاكرة الوصول العشوائي والعوامل الأساسية الأخرى. في حين أن وقت التشغيل ووقت رد الفعل هما بلا شك أمران مهمان يجب قياسهما كميا ، إلا أن موثوقية واتساق تطبيقك أو صفحتك أمران حيويان بالإضافة إلى ذلك وقياسات ويجب إعدادهما لفحص هذه الأشياء.
بالإضافة إلى ذلك ، فإن مجرد التحقق من إمكانية الوصول ووقت تشغيل واجهات برمجة التطبيقات والتطبيقات الخاصة بك من داخل جدار الحماية الخاص بك ليس كافيا عندما تتطلع إلى توفير تجربة من الدرجة الأولى. يمكن للمستخدمين الوصول إلى تطبيقاتك من أي مكان في العالم ، من أجهزة ومتصفحات وشبكات مختلفة. تسمح لك المراقبة الاصطناعية بتقليد إجراءات العمل هذه أو تبادل العملاء ، على سبيل المثال ، تسجيل الدخول ، والبحث عن العناصر ، وملء النماذج / الاستطلاعات ، وإضافة أشياء إلى عربات التسوق ، وعملية تسجيل الخروج ، وما إلى ذلك ، من مواقع مختلفة حول العالم ، ومراجعة أدائها. ستتمكن بعد ذلك من تحليل تفاصيل التنفيذ بين المواقع الجغرافية والخطوات في البورصات والبدء في تحديد خطط التحسين الخاصة بك.
تتبع المكدس والمراقبة الاصطناعية: الخلاصة
تتبع المراقبة الاصطناعية نهجا استباقيا من الخارج للمساعدة في اكتشاف المشكلات قبل أن يفعل عملاؤك. في حالة استخدام الإجراءات الصحيحة ، يمكن أن تمنحك المراقبة الاصطناعية نفس وجهة نظر المستخدمين النهائيين والعملاء ، ناهيك عن كيفية أدائهم – وما إذا كان العملاء سيكونون سعداء بالتجربة. هذا ليس هو الحال مع تتبع المكدس. إنه بلا شك بروتوكول تحليل موثوق به ومختص للغاية ، لكنه لا يمكنه تتبع خطوات حدث فاشل إلا بطريقة سابقة. هذا يقودنا إلى فهم راسخ للغاية بأن تتبع المكدس ، جنبا إلى جنب مع المراقبة الاصطناعية ، يمكن أن يساعد في ربط المكدس الكامل معا وتوفير حل قوي لمراقبة الأداء. جرب منصة Dotcom-Monitor الكاملة مجانا لمدة 30 يوما.
