การวิเคราะห์ประสิทธิภาพแอปพลิเคชัน: ตัวชี้วัด การทดสอบ และการติดตาม

Informatec Digital » แหล่งข้อมูล » การวิเคราะห์ประสิทธิภาพแอปพลิเคชัน: ตัวชี้วัด การทดสอบ และการติดตาม

เพื่อให้ได้คุณภาพในระดับนั้น การ "ทดสอบเล็กน้อยก่อนเผยแพร่" เพียงอย่างเดียวไม่เพียงพอ จำเป็นต้องมีการผสมผสานระหว่างการตรวจสอบอย่างต่อเนื่อง (APM และ RUM)การทดสอบประสิทธิภาพที่ออกแบบมาอย่างดี ตัวชี้วัดที่ชัดเจน และเครื่องมือที่สามารถจำลองทุกอย่างตั้งแต่การใช้งานประจำวันไปจนถึงปริมาณการใช้งานที่พุ่งสูงขึ้นอย่างมาก และที่สำคัญยิ่งกว่านั้น ต้องทำอย่างมีกลยุทธ์: วัดสิ่งที่สำคัญต่อธุรกิจอย่างแท้จริง และใช้ระบบอัตโนมัติให้มากที่สุดเท่าที่จะเป็นไปได้เพื่อหลีกเลี่ยงการแก้ไขปัญหาอยู่ตลอดเวลา

ประสิทธิภาพของแอปพลิเคชัน: มันคืออะไร ทำไมจึงสำคัญ และเราวัดอะไรบ้าง

เมื่อเราพูดถึงประสิทธิภาพของแอปพลิเคชัน เราหมายถึงความสามารถของแอปในการตอบสนองอย่างรวดเร็ว มีความเสถียร และปรับขนาดได้ตามจำนวนผู้ใช้หรือปริมาณข้อมูลที่เพิ่มขึ้น โดยไม่ทำให้การใช้ทรัพยากรเพิ่มขึ้นอย่างมากหรือลดทอนประสบการณ์ของผู้ใช้ สิ่งนี้ใช้ได้กับแอปพลิเคชันบนมือถือ เว็บ และเดสก์ท็อปรวมถึง API ไมโครเซอร์วิส และระบบองค์กรที่ซับซ้อน

หัวใจสำคัญคือการวัดตัวชี้วัดประสิทธิภาพแอปพลิเคชัน (KPI) อย่างเป็นระบบ ซึ่งจะช่วยให้คุณเข้าใจว่าแอปพลิเคชันนั้นบรรลุเป้าหมายทางเทคนิคและธุรกิจหรือไม่ และตรวจจับได้ทันท่วงทีเมื่อมีสิ่งผิดปกติเริ่มเกิดขึ้น ก่อนที่ผู้ใช้ปลายทางจะสังเกตเห็นหรือสัญญาณเตือนจะดังขึ้นในระบบการใช้งานจริง

ตัวชี้วัดที่ใช้กันทั่วไปในการประเมินประสิทธิภาพของแอป ได้แก่:

• การใช้งาน CPU: ตรวจสอบว่าแอปพลิเคชันใช้ทรัพยากรหน่วยประมวลผลมากน้อยเพียงใด และมีการเพิ่มขึ้นอย่างผิดปกติที่บ่งชี้ถึงการคำนวณที่มากเกินไป ลูปที่ออกแบบไม่ดี หรือกระบวนการที่ขัดขวางการตอบสนองหรือไม่
• การใช้ความจำ: ปริมาณหน่วยความจำที่ถูกใช้งาน การปรากฏของหน่วยความจำรั่วไหล ข้อผิดพลาดในการเข้าถึงหน้าหน่วยความจำ หรือการแบ่งหน้าหน่วยความจำมากเกินไป ซึ่งบ่งชี้ว่าระบบใช้เวลาในการย้ายข้อมูลมากกว่าการประมวลผลตรรกะทางธุรกิจ
• จำนวนคำขอต่อนาที และจำนวนไบต์ต่อคำขอนี่แสดงให้เห็นว่าแอปหรือ API ประมวลผลคำขอจำนวนเท่าใด และจัดการข้อมูลมากแค่ไหนในแต่ละคำขอ ช่วยให้เห็นว่าระบบแบ็กเอนด์สามารถรองรับการขยายตัวได้มากแค่ไหน และปริมาณข้อมูลต่อการเรียกใช้งานนั้นเหมาะสมหรือไม่
• ความหน่วงและเวลาตอบสนอง: ระยะเวลาที่แอปพลิเคชันใช้ในการตอบสนอง นับตั้งแต่ผู้ใช้ดำเนินการใดๆ หรือไคลเอ็นต์ส่งคำขอ จนกระทั่งได้รับคำตอบที่เป็นประโยชน์
• เวลาการทำงานและความพร้อมใช้งาน: เปอร์เซ็นต์ของเวลาที่บริการทำงานได้ปกติ ซึ่งโดยทั่วไปจะตรวจสอบด้วยการ ping เป็นระยะ หรือการตรวจสอบแบบจำลอง
• อัตราความผิดพลาดสัดส่วนของคำขอที่สิ้นสุดลงด้วยข้อผิดพลาด (รหัส HTTP 4xx/5xx, ข้อผิดพลาดที่ไม่ได้รับการจัดการ, ความล้มเหลวในการทำงาน)
• คะแนน Apdex และความพึงพอใจของผู้ใช้: ดัชนีที่สรุปค่าเปอร์เซ็นต์ของผู้ใช้ที่พึงพอใจ ยอมรับได้ หรือไม่พอใจ โดยพิจารณาจากเวลาตอบสนอง ไว้ในค่าเดียว
• ประสิทธิภาพการเก็บขยะ (GC)บนแพลตฟอร์มที่มีการจัดการหน่วยความจำอัตโนมัติ (Java, .NET, Android) จะใช้เวลานานแค่ไหนในการเก็บขยะ (GC) ทำให้เกิดการหยุดชะงักกี่ครั้ง และส่งผลต่อการใช้งาน CPU และความลื่นไหลอย่างไร
• อัตราผลผลิตหรือประสิทธิภาพจำนวนธุรกรรมหรือคำขอที่ประมวลผลต่อหน่วยเวลา ซึ่งมีความสำคัญในระบบที่มีการทำงานพร้อมกันสูง

เป้าหมายของการติดตามตัวชี้วัดเหล่านี้ไม่ใช่เพื่อรวบรวมกราฟ แต่เพื่อทำความเข้าใจสถานะที่แท้จริงของแอปพลิเคชันคาดการณ์ปัญหาคอขวด จัดลำดับความสำคัญของการปรับปรุง และแสดงให้เห็นด้วยข้อมูลว่าการเพิ่มประสิทธิภาพส่งผลกระทบต่อทั้งประสบการณ์ของผู้ใช้และผลลัพธ์ทางธุรกิจ

APM, RUM และการตรวจสอบประสิทธิภาพแบบเรียลไทม์

ในสภาพแวดล้อมสมัยใหม่ที่มีสถาปัตยกรรมแบบกระจาย คอนเทนเนอร์ คลาวด์แบบไฮบริด และไมโครเซอร์วิส การควบคุมประสิทธิภาพโดยปราศจากเครื่องมือตรวจสอบประสิทธิภาพแอปพลิเคชัน (APM) ที่ดี ควบคู่ไปกับเทคนิคการตรวจสอบผู้ใช้จริง (RUM) และส่วนประกอบการสังเกตการณ์ขั้นสูงที่กำลังได้รับความนิยมมากขึ้นเรื่อยๆ นั้น แทบจะเป็นไปไม่ได้เลย

โซลูชัน APM/RUM (เช่น โซลูชันจาก Elastic, Instana, Applications Manager, Turbonomic ที่ผสานรวมกับ APM เป็นต้น) ให้การมองเห็นภาพรวมแบบครบวงจรเกี่ยวกับสิ่งที่เกิดขึ้นในแอปพลิเคชันของคุณ: เวลาตอบสนอง การติดตามแบบกระจาย การสืบค้นฐานข้อมูล การเรียกใช้ภายนอก ข้อผิดพลาดและความผิดปกติ โดยผสานรวมกับเมตริกโครงสร้างพื้นฐาน

การตรวจสอบโดยผู้ใช้ จริง (Real User Monitoring หรือ RUM)จะบันทึกสิ่งที่ผู้ใช้จริงเห็น เช่น เวลาในการโหลดหน้าจอ การค้างของอินเทอร์เฟซ ข้อผิดพลาดของเบราว์เซอร์หรือแอปพลิเคชันบนมือถือ และความหน่วงที่รับรู้ได้ในภูมิภาคและอุปกรณ์ต่างๆ ข้อมูลนี้ช่วยเสริมข้อมูลจากการทดสอบจำลองและการทดสอบในห้องปฏิบัติการ ซึ่งมีความสำคัญ แต่ไม่สามารถทดแทนข้อมูลจากโลกแห่งความเป็นจริงได้

ในทางกลับกัน แพลตฟอร์ม APM สมัยใหม่นำเสนอคุณสมบัติต่างๆ เช่น:

• การตรวจสอบตามเวลาจริง ตัวชี้วัดประสิทธิภาพหลัก (KPIs): ความพร้อมใช้งาน, Apdex, อัตราข้อผิดพลาด, ความเร็วในการถ่ายโอนข้อมูล การใช้ทรัพยากร.
• ร่องรอยที่กระจาย เพื่อติดตามธุรกรรมที่เกิดขึ้นในไมโครเซอร์วิส คิว ฐานข้อมูล และบริการภายนอกหลายรายการ และระบุส่วนที่ทำงานช้าที่สุด
• แผนผังความสัมพันธ์ เครื่องมืออัตโนมัติที่แสดงให้เห็นถึงความสัมพันธ์ระหว่างบริการ ฐานข้อมูล คิว และส่วนหน้า ทำให้ตรวจจับสาเหตุหลักของความล้มเหลวได้ง่ายขึ้น
• การวิเคราะห์ประสิทธิภาพโค้ดและเธรด เพื่อค้นหาวิธีการ คำสั่ง SQL หรือส่วนของโค้ดที่ใช้ CPU มากเกินไป หรือทำให้เธรดอินเทอร์เฟซหยุดทำงาน
• การแจ้งเตือนอัจฉริยะและ AIOps ซึ่งเป็นการผสมผสานการเรียนรู้ของเครื่องจักรและการวิเคราะห์อนุกรมเวลาเพื่อตรวจจับความผิดปกติ ลดสัญญาณเตือนที่ผิดพลาด และจัดลำดับความสำคัญของเหตุการณ์วิกฤต

ด้วยการผสานรวม APM, RUM และการตรวจสอบแบบสังเคราะห์ คุณจะได้รับมุมมองที่ครอบคลุม 360 องศาเกี่ยวกับประสิทธิภาพ : สิ่งที่ผู้ใช้เห็น สิ่งที่แอปพลิเคชันกำลังทำอยู่ภายใน และวิธีที่โครงสร้างพื้นฐานที่อยู่เบื้องหลังตอบสนอง สิ่งนี้ช่วยให้ทีม DevOps และ ITOps สามารถตอบสนองต่อเหตุการณ์ได้อย่างรวดเร็ว และที่ดียิ่งกว่านั้นคือสามารถป้องกันเหตุการณ์เหล่านั้นได้

ตัวชี้วัดประสิทธิภาพหลักในแอปพลิเคชันบนมือถือและเว็บ

ในแอปพลิเคชันบนมือถือและเว็บ ตัวชี้วัดประสิทธิภาพบางอย่างมีความอ่อนไหวเป็นพิเศษ เนื่องจากส่งผลโดยตรงต่อการรับรู้ของผู้ใช้และความสำเร็จของผลิตภัณฑ์ การติดตามตัวชี้วัดเหล่านี้อย่างใกล้ชิดจะสร้างความแตกต่างระหว่างแอปที่ดึงดูดผู้ใช้และแอปที่ถูกถอนการติดตั้งหลังจากการใช้งานครั้งที่สอง

หนึ่งในประเด็นสำคัญของอุปกรณ์เคลื่อนที่คือความหน่วงในการเปิดแอปพลิเคชันซึ่งก็คือเวลาที่ผ่านไปนับตั้งแต่ผู้ใช้แตะไอคอน (หรือการแจ้งเตือน) จนกระทั่งเห็นข้อมูลที่เป็นประโยชน์บนหน้าจอ สามารถแบ่งประเภทได้หลายประเภท:

• การสตาร์ทเครื่องยนต์ขณะเย็นแอปไม่ได้อยู่ในหน่วยความจำ ระบบต้องสร้างกระบวนการ โหลดโค้ด เริ่มต้นใช้งานไลบรารี และแสดงหน้าจอแรก
• เริ่มแบบอุ่นๆกระบวนการนั้นมีอยู่จริง แต่กิจกรรมนั้นถูกสร้างขึ้นใหม่หรือถูกฟื้นฟูให้กลับสู่สถานะเดิม
• ฮอตสตาร์ทคุณเพียงแค่ต้องปรับมุมมองหรือกลับมาใช้งานต่อ โดยแทบไม่ต้องทำอะไรเพิ่มเติมเลย

เพื่อเป็นข้อมูลอ้างอิง ขอแนะนำอย่างยิ่งให้ตั้งเป้าหมายให้เวลาในการเปิดแอป (cold launch time) ต่ำกว่า 500 มิลลิวินาทีเพราะจะทำให้ค่าความหน่วง p95 และ p99 (เปอร์เซ็นไทล์สูงสุด) ใกล้เคียงกับค่ามัธยฐาน หากผู้ใช้บางคนรอหลายวินาที ในขณะที่ผู้ใช้คนอื่นเปิดแอปได้ภายในครึ่งวินาที แสดงว่ามีบางอย่างไม่สมดุล

อีกประเด็นสำคัญคือการเลื่อนและการค้างของอินเทอร์เฟซบนหน้าจอที่เคลื่อนไหว (ฟีด รายการ แกลเลอรี) ผู้ใช้คาดหวังความลื่นไหลที่สมบูรณ์แบบ เมื่อระบบไม่สามารถสร้างเฟรมได้ที่อัตราการรีเฟรชของอุปกรณ์ (60 Hz, 90 Hz หรือแม้แต่ 120 Hz) จะเกิดการกระตุกและสะดุด การกระตุกเหล่านี้เกิดขึ้นเมื่อแอปใช้เวลานานกว่าระยะเวลาของเฟรม (ตัวอย่างเช่น มากกว่า 16,7 มิลลิวินาทีที่ 60 FPS) ในการแสดงผลเนื้อหา

นอกเหนือจากความลื่นไหลแล้วการเปลี่ยนหน้าจอ ต้องได้รับการตรวจสอบอย่างระมัดระวัง การสลับแท็บ การเปิดรายละเอียดจากรายการ หรือการแสดงกล่องโต้ตอบ ควรเกิดขึ้นแทบจะในทันที ด้วยภาพเคลื่อนไหวที่ราบรื่น และไม่มีการกระพริบหรือหน้าจอว่างเป็นเวลานาน

ในเบื้องหลัง แต่มีความสำคัญไม่แพ้กัน คือการใช้พลังงานแบตเตอรี่และประสิทธิภาพการใช้พลังงานงานที่ไม่จำเป็น การจัดสรรหน่วยความจำจำนวนมาก และการใช้งาน CPU อย่างหนักหน่วงจะทำให้แบตเตอรี่หมดเร็วและเครื่องร้อนเกินไป Android Runtime (ART) ได้ปรับปรุงประสิทธิภาพแล้ว แต่หากลูปภายในของแอปของคุณสร้างอ็อบเจ็กต์ใหม่หลายพันรายการต่อวินาที ต้นทุนในการจัดสรรและการเก็บกวาดขยะจะเห็นได้ชัดเจน

ขั้นตอนการทำงานเพื่อระบุและแก้ไขปัญหาด้านประสิทธิภาพ

เพื่อหลีกเลี่ยงการพึ่งพาโชค การสร้างขั้นตอนการวิเคราะห์ประสิทธิภาพอย่างเป็นระบบซึ่งผสมผสานการทดสอบด้วยตนเองอย่างละเอียดในห้องปฏิบัติการกับการรวบรวมตัวชี้วัดโดยรวมในสภาพแวดล้อมการใช้งานจริงนั้นเป็นสิ่งที่มีประโยชน์อย่างยิ่ง แนวทางทั่วไปประกอบด้วยขั้นตอนเหล่านี้:

ขั้นแรก จำเป็นต้องระบุเส้นทางการใช้งานของผู้ใช้ที่สำคัญซึ่งก็คือขั้นตอนที่มีผลกระทบมากที่สุดต่อประสบการณ์และธุรกิจ:

• การเปิดแอปบ่อยครั้ง (ไอคอน การแจ้งเตือน ลิงก์โดยตรง)
• หน้าจอที่มีการเลื่อนข้อมูลอย่างต่อเนื่องบนข้อมูลจำนวนมาก
• การเปลี่ยนผ่านที่สำคัญระหว่างมุมมองและกิจกรรมต่างๆ
• กระบวนการที่ใช้เวลานาน เช่น การเรียกดูเว็บไซต์ การเล่นไฟล์เสียง/วิดีโอ การชำระเงิน เป็นต้น

เมื่อกำหนดค่าแล้ว อุปกรณ์เหล่านั้นจะถูกตรวจสอบและวิเคราะห์โดยใช้เครื่องมือวิเคราะห์และติดตามเช่น Perfetto หรือ Systrace เพื่อดูว่าอุปกรณ์กำลังทำอะไรด้วยความแม่นยำระดับไมโครวินาที เครื่องมือสร้างโปรไฟล์หน่วยความจำเพื่อตรวจจับการรั่วไหลและจุดที่มีการจัดสรรหน่วยความจำสูง หรือเครื่องมือเช่น Simpleperf เพื่อค้นหาว่าฟังก์ชันใดใช้ CPU มากที่สุด

สิ่งสำคัญคือต้องเน้นย้ำว่า การวิเคราะห์ประสิทธิภาพอย่างละเอียดนั้นจำเป็นต้องทำการดีบั๊กการทำงานแต่ละครั้งของเส้นทางเหล่านี้ โดยการจำลองปัญหาในลักษณะที่มีการควบคุม การวิเคราะห์ข้อมูลโดยรวมมีประโยชน์ในการตรวจจับรูปแบบและการถดถอย แต่ไม่สามารถทดแทนการวิเคราะห์เชิงลึกของร่องรอยเฉพาะได้

ในขณะเดียวกัน ควรตั้งค่าการเก็บรวบรวมข้อมูลเมตริกอย่างต่อเนื่องในสภาพแวดล้อมการทดสอบอัตโนมัติและในสภาพแวดล้อมการใช้งานจริง เช่น เวลาเริ่มต้นระบบ อัตราการบล็อก ข้อมูลเมตริกเฟรม (ตัวอย่างเช่น ผ่าน FrameMetricsAggregator บน Android) ข้อมูลเมตริกฟิลด์ใน Play Console การวัดประสิทธิภาพการเลื่อนหน้าจอแบบมาโคร เป็นต้น ข้อมูลเมตริกเหล่านี้ช่วยให้คุณเห็นความแปรปรวนที่แท้จริงระหว่างอุปกรณ์ เวอร์ชันระบบปฏิบัติการ และสภาพเครือข่าย

การตั้งค่าแอปและระบบเพื่อการวัดที่แม่นยำ

หนึ่งในข้อผิดพลาดที่พบบ่อยที่สุดคือการวัดประสิทธิภาพภายใต้สภาวะที่ไม่สมจริง เพื่อให้ผลลัพธ์มีประโยชน์ทั้ง APK และระบบ จะต้อง ได้รับการกำหนดค่าอย่างระมัดระวัง โดยต้องแน่ใจว่าสภาพแวดล้อมการทดสอบคล้ายคลึงกับสภาพแวดล้อมการใช้งานจริง ในขณะเดียวกันก็ต้องควบคุมสัญญาณรบกวนด้วย

ในส่วนของแอปพลิเคชันนั้น สิ่งสำคัญคือต้องไม่ทำการวัดประสิทธิภาพเทียบกับเวอร์ชันดีบักเวอร์ชันดีบักจะเพิ่มการตรวจสอบ บันทึก และแฟล็กต่างๆ ที่เปลี่ยนแปลงการทำงานในขณะรันไทม์อย่างมาก ใน Android 10 ขึ้นไป คุณสามารถใช้ แอตทริบิวต์ `profileable android:shell="true"`ในไฟล์ manifest เพื่อเปิดใช้งานการวัดประสิทธิภาพเทียบกับเวอร์ชันรีลีส ซึ่งจะช่วยรักษาพฤติกรรมที่ใกล้เคียงกับความเป็นจริง

นอกจากนี้ ยังควรใช้เครื่องมือลดขนาดโค้ด สำหรับการใช้งานจริง (เช่น ProGuard, R8 เป็นต้น) เนื่องจากขนาดและการจัดระเบียบโค้ดส่งผลต่อประสิทธิภาพอย่างเห็นได้ชัด อย่างไรก็ตาม คุณควรตรวจสอบกฎต่างๆ ด้วย เพราะการตั้งค่าบางอย่างอาจทำให้จุดติดตามที่สำคัญสำหรับการวัดผลหายไป และจำเป็นต้องปรับเปลี่ยนการตั้งค่าเหล่านี้สำหรับเวอร์ชันทดสอบ

ในส่วนของการคอมไพล์นั้น การทำให้แอปอยู่ในสถานะที่ทราบแน่ชัด ซึ่งโดยทั่วไปแล้วคือ โหมด ความเร็วหรือ โหมด โปรไฟล์ความเร็ว ถือเป็นเรื่องที่คุ้มค่า ทั้งสองโหมดนี้ช่วยลดปริมาณโค้ดที่ DeX ตีความ และลดความจำเป็นในการคอมไพล์ JIT ในพื้นหลัง ซึ่งทำให้ผลลัพธ์มีความเสถียรมากขึ้น โหมดโปรไฟล์ความเร็วพยายามจำลองพฤติกรรมการใช้งานจริงให้ใกล้เคียงที่สุด แต่จำเป็นต้อง "วอร์มเครื่อง" แอปและจัดการโปรไฟล์ (เช่น โปรไฟล์พื้นฐาน)

จากมุมมองของระบบ เมื่อต้องการการวัดที่มีความแม่นยำสูงมาก (ไมโครเบนช์มาร์ค) มักจะทำการปรับเทียบอุปกรณ์ : ทำการทดสอบ A/B บนเทอร์มินัลและเวอร์ชันระบบปฏิบัติการเดียวกัน ตั้งค่าความถี่ CPU/GPU ปิดใช้งานคอร์ขนาดเล็ก หรือจำกัดความร้อนด้วยสคริปต์เช่น lockClocks เป็นต้น วิธีนี้ไม่ได้แสดงถึงโลกแห่งความเป็นจริง แต่ช่วยลดสัญญาณรบกวนในสถานการณ์เฉพาะเจาะจงได้

สำหรับการวัดผลที่ใกล้เคียงกับประสบการณ์ของผู้ใช้ (การเริ่มต้นระบบ การใช้พลังงานแบตเตอรี่ การทำงานผิดพลาดของ UI) ขอแนะนำให้ใช้เฟรมเวิร์กการทดสอบ เช่น Macrobenchmarkซึ่งจะช่วยทำให้ขั้นตอนเหล่านี้เป็นไปโดยอัตโนมัติและหลีกเลี่ยงข้อผิดพลาดในการกำหนดค่าที่ละเอียดอ่อนแต่สำคัญได้

รูปแบบทั่วไปของปัญหาด้านประสิทธิภาพ

ในการวิเคราะห์แอปพลิเคชันเกือบทั้งหมดอย่างละเอียด จะพบ รูปแบบปัญหาที่เกิดขึ้นซ้ำๆซึ่งควรค่าแก่การทราบ เพราะโดยปกติแล้วจะมีวิธีแก้ไขที่ค่อนข้างชัดเจนหากตรวจพบได้ทันเวลา

หนึ่งในปัญหาที่พบบ่อยที่สุดคือการเริ่มต้นทำงานช้าเนื่องจากกิจกรรมกระโดด (jumper activity ) ปัญหานี้เกิดขึ้นเมื่อหลังจากมีการแสดงเจตนาเริ่มต้น (ไอคอน การแจ้งเตือน ลิงก์แบบเจาะลึก) แล้ว จะมีการเปิดใช้งานกิจกรรมระดับกลางที่ไม่แสดงเฟรมใดๆ จากนั้นกิจกรรม "จริง" จึงเริ่มต้นขึ้น ในการติดตามการทำงาน จะปรากฏเป็นเหตุการณ์ `activityStart` สองครั้งติดต่อกันโดยไม่มีการแสดงผลใดๆ ระหว่างนั้น การ "กระโดด" นี้ทำให้เกิดความล่าช้าในการเริ่มต้นโดยไม่ให้ประโยชน์ใดๆ วิธีแก้ปัญหาโดยทั่วไปคือการปรับโครงสร้างการเริ่มต้นใหม่ให้เป็นส่วนประกอบที่สามารถนำกลับมาใช้ใหม่ได้ หรือรวมเข้ากับกิจกรรมหลักโดยตรง

อีกตัวอย่างคลาสสิกคือการจัดสรรหน่วยความจำที่ไม่จำเป็นซึ่งกระตุ้นการเก็บขยะ (garbage collection ) หาก Systrace หรือโปรไฟล์หน่วยความจำแสดงให้เห็นว่ารอบการเก็บขยะทำงานทุกๆ สองสามวินาทีในระหว่างการทำงานที่ใช้เวลานาน เป็นไปได้มากว่ามีโค้ดที่จัดสรรวัตถุซ้ำๆ อย่างต่อเนื่องภายในลูปที่ใช้ทรัพยากรมาก วิธีแก้ปัญหาไม่ใช่การลบวัตถุใหม่ทุกชิ้น แต่เป็นการแก้ไขจุดที่มีการใช้งานมาก โดยการนำโครงสร้างกลับมาใช้ใหม่หรือใช้รูปแบบการพูล (pooling) เมื่อเหมาะสม

เฟรมที่มีการบล็อก มักพบได้บ่อยในไปป์ไลน์กราฟิกในการติดตามการทำงานที่ปกติ การเรียกใช้ Choreographer.doFrame() จะเกิดขึ้นในจังหวะที่สม่ำเสมอ (ตัวอย่างเช่น ทุกๆ 16,7 มิลลิวินาที) การซูมเข้าไปในบริเวณที่มีจังหวะการทำงานนี้สามารถเปิดเผยวิวที่ใช้ทรัพยากรมาก เลย์เอาต์ที่ซับซ้อนเกินไป การดำเนินการ I/O ที่ทำงานบนเธรด UI หรือ RecyclerView ที่ตั้งค่าไม่ถูกต้องได้

RecyclerView เป็นต้นเหตุของปัญหามากมาย เช่น การทำให้ชุดข้อมูลทั้งหมดไม่ถูกต้องด้วย `notifyDataSetChanged()` ทั้งๆ ที่มีการเปลี่ยนแปลงเพียงไม่กี่องค์ประกอบเท่านั้น การกำหนดค่าพูลมุมมองที่นำกลับมาใช้ใหม่ใน RecyclerView ที่ซ้อนกันอย่างไม่เหมาะสม หรือการไม่ดึงข้อมูลล่วงหน้า อย่างเพียงพอ เมื่อถึงจุดสิ้นสุดของรายการ ทั้งหมดนี้ส่งผลให้การแสดงผลใช้เวลานาน การเลื่อนกระโดด และเวลาที่ผู้ใช้ต้องรออย่างเห็นได้ชัด

การทดสอบประสิทธิภาพ: ประเภท ขั้นตอน และแนวปฏิบัติที่ดีที่สุด

นอกเหนือจากการตรวจสอบการผลิตแล้ว กลยุทธ์ที่จริงจังใดๆ ก็ตามจำเป็นต้องมี แผนการ ทดสอบประสิทธิภาพแอปพลิเคชัน ที่แข็งแกร่ง ในสภาพแวดล้อมที่มีการควบคุม การทดสอบนี้ช่วยให้คุณตรวจสอบความสามารถ ความเสถียร และความสามารถในการขยายขนาดก่อนที่จะเปิดเผยการเปลี่ยนแปลงหรือเวอร์ชันใหม่ให้ผู้ใช้ได้ใช้งาน

มีการทดสอบหลายประเภท แต่ละประเภทมีวัตถุประสงค์เฉพาะของตนเอง:

• การทดสอบโหลดพวกเขาประเมินพฤติกรรมของแอปภายใต้ปริมาณผู้ใช้หรือธุรกรรมที่คาดการณ์ไว้ โดยวัดเวลาตอบสนอง ปริมาณงาน และการใช้ทรัพยากร เพื่อตรวจจับปัญหาคอขวดก่อนการใช้งานจริง
• การทดสอบความเครียดพวกเขาทดสอบระบบเกินขีดจำกัดปกติเพื่อดูว่ามันจะรับมือได้ไกลแค่ไหน จะล้มเหลวอย่างไร และจะฟื้นตัวได้อย่างไร พวกเขามีบทบาทสำคัญในการวางแผนกำลังการผลิตและการจัดการช่วงที่มีความต้องการสูงอย่างเช่นในวันแบล็กฟรายเดย์
• การทดสอบความทนทาน/การแช่อุปกรณ์เหล่านี้จะถูกใช้งานอย่างต่อเนื่องเป็นเวลาหลายชั่วโมงหรือหลายวัน เพื่อค้นหาปัญหาที่เกิดจากการเสื่อมสภาพอย่างช้าๆ การรั่วไหลของหน่วยความจำ หรือการหมดลงของทรัพยากร
• การทดสอบสูงสุดพวกเขาจำลองการเพิ่มขึ้นของภาระงานอย่างฉับพลันและซ้ำๆ (เช่น แคมเปญ การเปิดตัวฟีเจอร์ การถ่ายทอดสด) เพื่อตรวจสอบว่าแอปพลิเคชันและโครงสร้างพื้นฐานสามารถรับมือกับการเปลี่ยนแปลงอย่างฉับพลันได้หรือไม่
• การทดสอบปริมาตรพวกเขาทำการวิเคราะห์พฤติกรรมของแอปเมื่อจำนวนผู้ใช้งานเพิ่มขึ้นอย่างมีนัยสำคัญ ปริมาณข้อมูล (ขนาดฐานข้อมูล ไฟล์ ข้อความ) การตรวจสอบเวลาตอบสนอง ความน่าเชื่อถือในการจัดเก็บ และการสูญหายของข้อมูล
• การทดสอบความสามารถในการขยายขนาดพวกเขาตรวจสอบว่าแอปพลิเคชันตอบสนองอย่างไรเมื่อโหลดเพิ่มขึ้นทีละน้อย และการขยายขนาดในแนวนอนหรือแนวตั้งจะทำให้ประสิทธิภาพดีขึ้นตามที่คาดหวังหรือไม่

กระบวนการทดสอบประสิทธิภาพโดยทั่วไปประกอบด้วยหลายขั้นตอนที่แตกต่างกัน ขั้นแรกคือการวิเคราะห์ความต้องการ : ทำความเข้าใจว่าเวลาตอบสนอง อัตราปริมาณงาน ระดับความพร้อมใช้งาน และขีดจำกัดข้อผิดพลาดใดที่ยอมรับได้สำหรับธุรกิจ จากนั้นจะ เป็นขั้นตอน การวางแผนและกลยุทธ์ซึ่งจะกำหนดขอบเขตของการทดสอบ สภาพแวดล้อม เครื่องมือ และตัวชี้วัดที่จะต้องตรวจสอบ

ขั้นตอนต่อไป คือการออกแบบ กรณีทดสอบเพื่อให้ครอบคลุมสถานการณ์การโหลดที่แตกต่างกัน สภาพเครือข่าย และปริมาณข้อมูล การกำหนดค่าสภาพแวดล้อมการทดสอบ (ฮาร์ดแวร์ ซอฟต์แวร์ เครือข่าย การจำลองการโหลด และเครื่องมือตรวจสอบ) และการดำเนินการทดสอบ พร้อมทั้งรวบรวมข้อมูลประสิทธิภาพอย่างระมัดระวัง

ขั้นตอนที่สำคัญที่สุดคือการตรวจสอบและวิเคราะห์ : การเชื่อมโยงเวลาตอบสนองกับการใช้งาน CPU, ความหน่วงของเครือข่ายกับอัตราข้อผิดพลาด, ปริมาณการรับส่งข้อมูลที่พุ่งสูงขึ้นกับการโอเวอร์โหลดของฐานข้อมูล และอื่นๆ หลังจากบันทึกผลการค้นพบในรายงานที่ชัดเจนสำหรับผู้มีส่วนได้ส่วนเสียแล้ว กระบวนการจะย้ายไปยังขั้นตอนการปรับปรุงและทดสอบซ้ำ : โค้ด การกำหนดค่า หรือทรัพยากรจะถูกปรับเปลี่ยน และทำการทดสอบซ้ำจนกว่าจะได้รับการยืนยันว่าการปรับปรุงนั้นได้ผล

เครื่องมือและกรอบการทำงานสำหรับการทดสอบประสิทธิภาพ

เพื่อให้สามารถนำสิ่งที่กล่าวมาทั้งหมดไปปฏิบัติได้จริง จำเป็นต้องอาศัยเครื่องมือทดสอบประสิทธิภาพ เฉพาะด้าน ทั้งแบบโอเพนซอร์สและเชิงพาณิชย์ ที่ครอบคลุมการทำงานอัตโนมัติ การสร้างโหลด การตรวจสอบ และการวิเคราะห์ หมวดหมู่ที่เกี่ยวข้องบางส่วน ได้แก่:

• เครื่องมือโอเพนซอร์สโครงการต่างๆ เช่น Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder หรือเฟรมเวิร์กสำหรับการทดสอบหน่วยและการทดสอบฟังก์ชัน (JUnit, XCTest, Appium) ที่เพิ่มเติมด้วยสถานการณ์การทดสอบประสิทธิภาพ จะช่วยให้สามารถสร้างชุดทดสอบที่มีประสิทธิภาพสูงมากด้วยต้นทุนด้านลิขสิทธิ์ที่ต่ำ
• เครื่องมือทดสอบโหลดเชิงพาณิชย์และ APMโซลูชันต่างๆ เช่น WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest หรือ Parasoft นำเสนอสภาพแวดล้อมแบบบูรณาการพร้อมการสร้างโหลดบนระบบคลาวด์ การรายงานขั้นสูง และการสนับสนุนระดับมืออาชีพ
• โซลูชันเฉพาะทางและตรวจสอบได้ผลิตภัณฑ์ต่างๆ เช่น Applications Manager, Instana, Dynatrace, IBM Turbonomic หรือแพลตฟอร์มตรวจสอบเครือข่ายอย่าง SolarWinds ซึ่งเน้นการตรวจสอบอย่างต่อเนื่อง การตรวจจับความผิดปกติ และความสัมพันธ์ระหว่างประสิทธิภาพของแอปพลิเคชัน โครงสร้างพื้นฐาน และประสบการณ์ของผู้ใช้
• เครื่องมือเฉพาะแพลตฟอร์มตัวอย่างเช่น ในกรณีของ Android เครื่องมือต่างๆ เช่น Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace หรือตัวชี้วัดเฟรมของ Play Console ช่วยให้สามารถวิเคราะห์พฤติกรรมระดับระบบได้อย่างละเอียดมาก

เมื่อต้องเลือกใช้ระหว่างสองอย่างนี้ ควรพิจารณาปัจจัยต่างๆ เช่นความง่ายในการใช้งาน การรองรับโปรโตคอลและเทคโนโลยี ความสามารถในการขยายขนาด การบูรณาการกับ CI/CDรูปแบบการอนุญาตใช้งาน ความสามารถในการขยาย และคุณภาพของการสนับสนุน (การสนับสนุนจากชุมชนหรือเชิงพาณิชย์) นอกจากนี้ การผสมผสานหลายๆ อย่างเข้าด้วยกันก็ไม่ใช่เรื่องแปลก เช่น ตัวหนึ่งสำหรับการสร้างโหลด อีกตัวสำหรับ APM และอีกตัวสำหรับการตรวจสอบโครงสร้างพื้นฐาน

กล่าวโดยสรุป การวิเคราะห์และตรวจสอบประสิทธิภาพของแอปพลิเคชันนั้นต้องอาศัยการผสมผสานระหว่างตัวชี้วัดที่เลือกสรรมาอย่างดี เครื่องมือที่เหมาะสม และวินัยในกระบวนการทดสอบ แต่ผลลัพธ์ที่ได้นั้นคุ้มค่าอย่างยิ่ง: แอปที่เร็วขึ้น เสถียรขึ้น และมีประสิทธิภาพมากขึ้นผู้ใช้พึงพอใจมากขึ้น เหตุการณ์ที่เกิดขึ้นในระบบการผลิตน้อยลง และแน่นอนว่าส่งผลดีโดยตรงต่อชื่อเสียงและรายได้ของแบรนด์

บทความที่เกี่ยวข้อง:

ค้นพบ Qt Creator IDE: สภาพแวดล้อมอันทรงพลังที่สุดสำหรับการสร้างแอปพลิเคชันข้ามแพลตฟอร์ม