เมื่อทำการสนับสนุนทางเทคนิคสำหรับลูกค้าเรามักจะเห็นความผิดปกติของลูกค้าจำนวนมากเลย หลังจากกำจัดความผิดปกติเหล่านี้ความเร็วในการทำงานของรหัสได้รับการปรับปรุงอย่างมากเมื่อเทียบกับก่อน สิ่งนี้ช่วยให้เราสามารถคาดเดาได้ว่าการใช้ความผิดปกติในรหัสจะนำมาซึ่งค่าใช้จ่ายที่สำคัญ เนื่องจากความผิดปกติเป็นส่วนสำคัญของสถานการณ์ที่ไม่ถูกต้องจึงเป็นไปไม่ได้ที่จะละทิ้งดังนั้นเราจึงจำเป็นต้องวัดผลกระทบของการรักษาที่ผิดปกติต่อประสิทธิภาพ
การทดลอง
การทดลองของฉันขึ้นอยู่กับรหัสง่าย ๆ ที่ทำให้เกิดการสุ่ม จากมุมมองทางวิทยาศาสตร์นี่ไม่ใช่การวัดที่แม่นยำอย่างสมบูรณ์และในเวลาเดียวกันฉันไม่ทราบวิธีการทำรหัสปฏิบัติการในรหัสที่กำลังทำงาน แต่ไม่ว่าในกรณีใดรหัสนี้ควรช่วยให้เราเข้าใจสถานการณ์พื้นฐานบางอย่าง
ผลที่ได้นั้นน่าสนใจมาก: ค่าใช้จ่ายในการขว้างปาและจับความผิดปกติดูเหมือนจะต่ำมาก ในตัวอย่างของฉันมันประมาณ 0.02 มิลลิวินาที เว้นแต่คุณจะโยนความผิดปกติมากเกินไป (เราหมายถึง 100,000 หรือมากกว่า) สิ่งนี้จะถูกละเว้นโดยทั่วไป แม้ว่าผลลัพธ์เหล่านี้แสดงให้เห็นว่าการประมวลผลที่ผิดปกตินั้นไม่ส่งผลกระทบต่อประสิทธิภาพของรหัส แต่ก็ไม่ได้แก้ไขปัญหาต่อไปนี้: ใครเป็นผู้รับผิดชอบผลกระทบอย่างมากต่อประสิทธิภาพ
เห็นได้ชัดว่าฉันพลาดปัญหาสำคัญใด ๆ
หลังจากคิดถึงเรื่องนี้อีกครั้งฉันก็รู้ว่าฉันพลาดส่วนสำคัญของการรักษาที่ผิดปกติ ฉันไม่ได้พิจารณาสิ่งที่คุณทำเมื่อความผิดปกติเกิดขึ้น ในกรณีส่วนใหญ่คุณไม่เพียง แต่จะจับความผิดปกติ! ปัญหาอยู่ที่นี่: โดยทั่วไปคุณจะพยายามเสริมปัญหาและปล่อยให้แอปพลิเคชันยังคงเล่นกับผู้ใช้ปลายทาง ดังนั้นสิ่งที่ฉันพลาดคือ: "" "" รหัสเสริม "" เพื่อจัดการกับความผิดปกติ การสูญเสียประสิทธิภาพอาจมีความสำคัญมากขึ้นอยู่กับรหัสที่แตกต่างกัน ในบางกรณีสิ่งนี้อาจหมายถึงการมุ่งเน้นไปที่การเชื่อมต่อกับเซิร์ฟเวอร์และในกรณีอื่น ๆ อาจหมายถึงการใช้โซลูชันการย้อนกลับเริ่มต้นและโซลูชันที่ได้จากโซลูชันนี้จะนำประสิทธิภาพที่ไม่ดีมาใช้อย่างแน่นอน สิ่งนี้ดูเหมือนจะให้คำอธิบายที่ดีสำหรับพฤติกรรมที่เราเห็นในหลายกรณี
อย่างไรก็ตามฉันไม่คิดว่าการวิเคราะห์คือทุกสิ่งที่นี่ แต่ฉันรู้สึกว่ามีบางอย่างที่พลาดไปที่นี่
สแต็คร่องรอย
ฉันยังคงอยากรู้อยากเห็นเกี่ยวกับปัญหานี้และด้วยเหตุนี้ฉันจึงตรวจสอบว่าประสิทธิภาพการเปลี่ยนแปลงอย่างไรเมื่อรวบรวมร่องรอยของ Strack
นี่เป็นกรณีที่เกิดขึ้นบ่อยครั้ง: เพื่อเขียนความผิดปกติและวิถีสแต็กของมันพยายามค้นหาว่าปัญหาอยู่ที่ไหน
ด้วยเหตุนี้ฉันจึงปรับเปลี่ยนรหัสและรวบรวมร่องรอยของ Strack ที่ผิดปกติ สิ่งนี้เปลี่ยนสถานการณ์อย่างมีนัยสำคัญ ผลการปฏิบัติงานในการรวบรวมการติดตาม Strack ที่ผิดปกตินั้นสูงกว่าเพียงแค่การจับและการขว้างความผิดปกติ 10 เท่า ดังนั้นแม้ว่าการติดตาม Strack จะช่วยให้เข้าใจว่าปัญหาเกิดขึ้น (อาจช่วยให้เข้าใจว่าทำไมปัญหาเกิดขึ้น) แต่ก็มีการสูญเสียประสิทธิภาพ เนื่องจากเราไม่ได้พูดถึงร่องรอยของเส้นรอบวงผลกระทบที่นี่มักจะยอดเยี่ยมมาก ในกรณีส่วนใหญ่เราต้องโยนและจับความผิดปกติในหลายระดับ ลองดูตัวอย่างง่ายๆ: ไคลเอนต์บริการเว็บเชื่อมต่อกับเซิร์ฟเวอร์ ก่อนอื่นมีความผิดปกติในระดับห้องสมุด Java ตั้งแต่นั้นมาจะมีลูกค้าผิดปกติในระดับเฟรมเวิร์กและอาจมีการโทรตรรกะทางธุรกิจที่ผิดปกติในระดับแอปพลิเคชันในอนาคต จนถึงขณะนี้จะต้องรวบรวมร่องรอยทั้งหมดสามอัน ในกรณีส่วนใหญ่คุณสามารถเห็นการติดตาม strack เหล่านี้จากไฟล์บันทึกหรือเอาต์พุตแอปพลิเคชันและการเขียนร่องรอยระยะยาวเหล่านี้มักจะมีเอฟเฟกต์ประสิทธิภาพเช่นกัน
สรุปแล้ว
ก่อนอื่นมันไม่ดีที่จะทิ้งความผิดปกติที่ผิดปกติเนื่องจากผลกระทบของประสิทธิภาพ ผิดปกติช่วยในการจัดหาวิธีที่สอดคล้องกันในการแก้ปัญหาการทำงานและช่วยเขียนรหัสที่สะอาด แต่เราควรติดตามปริมาณที่ผิดปกติในรหัสซึ่งอาจทำให้เกิดผลกระทบอย่างมีนัยสำคัญ ดังนั้น ONEAPM จะต้องติดตามความผิดปกติที่เกิดขึ้นโดยค่าเริ่มต้น -ในหลายกรณีผู้คนจะต้องประหลาดใจกับความผิดปกติในรหัสและการสูญเสียประสิทธิภาพเมื่อแก้ปัญหาความผิดปกติเหล่านี้ ประการที่สองแม้ว่ามันจะเป็นประโยชน์มากในการใช้งานคุณควรหลีกเลี่ยงการจับการติดตาม Strack มากเกินไป ความผิดปกติควรได้รับการออกแบบสำหรับสภาพที่ผิดปกติและหลักการนี้ควรคำนึงถึงเมื่อใช้ แน่นอนว่าในกรณีที่คุณไม่ต้องการติดตามพฤติกรรมการเขียนโปรแกรมที่ดีภาษา Java จะแจ้งให้คุณทราบว่าการทำเช่นนั้นสามารถทำให้โปรแกรมของคุณทำงานได้เร็วขึ้นและกระตุ้นให้คุณทำเช่นนั้น
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้