การแก้ปัญหาและคำถามที่พบบ่อยเกี่ยวกับการตรวจสอบประสิทธิภาพและ

วิธีดูข้อความบันทึกสำหรับเหตุการณ์ด้านประสิทธิภาพ

1. เปิดใช้การบันทึกการแก้ไขข้อบกพร่อง ดังนี้

   1. ใน Xcode (ขั้นต่ำ v14.1) ให้เลือกผลิตภัณฑ์ > รูปแบบ > แก้ไขรูปแบบ
   2. เลือกเรียกใช้จากเมนูด้านซ้าย แล้วเลือกแท็บอาร์กิวเมนต์
   3. ในส่วนอาร์กิวเมนต์ที่ผ่านเมื่อเปิดตัว ให้เพิ่ม -FIRDebugEnabled

2. ตรวจสอบข้อความบันทึกของคุณเพื่อหาข้อความแสดงข้อผิดพลาด

3. การตรวจสอบประสิทธิภาพจะติดแท็กข้อความบันทึกด้วย Firebase/Performance เพื่อให้คุณกรองข้อความบันทึกได้

4. ตรวจหาบันทึกประเภทต่อไปนี้ซึ่งระบุว่าการตรวจสอบประสิทธิภาพกำลังบันทึกเหตุการณ์ด้านประสิทธิภาพ

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. คลิก URL เพื่อดูข้อมูลในคอนโซล Firebase ระบบอาจใช้เวลา 2-3 นาทีในการอัปเดตข้อมูลในหน้าแดชบอร์ด

หากแอปไม่บันทึกเหตุการณ์ด้านประสิทธิภาพ ให้อ่านเคล็ดลับการแก้ปัญหา

เพิ่ม SDK ในแอปแล้ว แต่คอนโซลยังคงระบุว่าให้เพิ่ม SDK

Firebase จะตรวจจับได้ว่าคุณเพิ่ม Performance Monitoring SDK ลงในแอปสำเร็จแล้วหรือไม่ เมื่อรับข้อมูลเหตุการณ์ (เช่น การโต้ตอบในแอป) จากแอป โดยปกติแล้ว แดชบอร์ดประสิทธิภาพของคอนโซล Firebase จะแสดงข้อความ "ตรวจพบ SDK" ภายใน 10 นาทีนับจากที่แอปเริ่มทำงาน จากนั้น แดชบอร์ดจะแสดงข้อมูลแรกที่ประมวลผลภายใน 30 นาที

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

Console แจ้งว่าตรวจพบ SDK แต่ไม่มีการแสดงข้อมูล

การตรวจสอบประสิทธิภาพจะประมวลผลข้อมูลเหตุการณ์ประสิทธิภาพก่อนแสดงในแดชบอร์ดประสิทธิภาพ

หากข้อความ "ตรวจพบ SDK" ปรากฏขึ้นมานานกว่า 24 ชั่วโมงแล้ว และคุณยังไม่เห็นข้อมูล ให้ตรวจสอบแดชบอร์ดสถานะ Firebase ในกรณีที่ทราบว่ามีข้อขัดข้องแล้ว หากไม่มีการหยุดชะงัก โปรดติดต่อฝ่ายสนับสนุน Firebase

แอปไม่บันทึกเหตุการณ์ด้านประสิทธิภาพ

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

1. ตรวจสอบว่าไม่ได้ปิดใช้ Performance Monitoring SDK ผ่านแฟล็กอย่างใดอย่างหนึ่งต่อไปนี้ในไฟล์ Info.plist

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

2. ตรวจสอบว่าไม่ได้ปิดใช้การตรวจสอบประสิทธิภาพขณะรันไทม์ (Swift | Obj-C)

3. หากคุณไม่พบการปิดใช้ในแอป ให้ติดต่อฝ่ายสนับสนุน Firebase

แดชบอร์ดประสิทธิภาพไม่มีข้อมูลการติดตามหน้าจอ

หากข้อมูลการติดตามการแสดงผลหน้าจอขาดหายไป ให้ลองทำตามขั้นตอนการแก้ปัญหาต่อไปนี้

แดชบอร์ดประสิทธิภาพไม่มีข้อมูลการติดตามที่กำหนดเอง

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

1. ตรวจสอบการตั้งค่าการติดตามโค้ดที่กำหนดเองโดยใช้ Trace API โดยเฉพาะรายการต่อไปนี้

   • ชื่อของการติดตามโค้ดที่กำหนดเองและเมตริกที่กำหนดเองต้องเป็นไปตามข้อกำหนดต่อไปนี้ กล่าวคือ ไม่มีช่องว่างนำหน้าหรือต่อท้าย ไม่มีอักขระขีดล่าง (_) นำหน้า และความยาวสูงสุดคือ 32 อักขระ
   • การติดตามทั้งหมดต้องเริ่มต้นและหยุดลง ระบบจะไม่บันทึกการติดตามที่ไม่ได้เริ่มต้น ไม่หยุด หรือหยุดก่อนเริ่มต้น

2. ตรวจสอบข้อความบันทึกเพื่อให้แน่ใจว่า Performance Monitoring บันทึกการติดตามโค้ดที่กำหนดเองตามที่คาดไว้

3. หากการตรวจสอบประสิทธิภาพบันทึกเหตุการณ์อยู่ แต่ไม่มีข้อมูลแสดงหลังจากผ่านไป 24 ชั่วโมง โปรดติดต่อทีมสนับสนุนของ Firebase

แดชบอร์ดประสิทธิภาพไม่มีข้อมูลคำขอเครือข่าย

หากข้อมูลคำขอเครือข่ายขาดหายไป ให้ลองทำตามขั้นตอนการแก้ปัญหาต่อไปนี้

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

   • สำหรับ Swift: URLSession และ URLConnection
   • สำหรับ Objective-C: NSURLSession และ NSURLConnection

   โปรดทราบว่าคุณเพิ่มการตรวจสอบที่กำหนดเองสำหรับคำขอเครือข่ายได้

2. ข้อควรระวังมีดังต่อไปนี้

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

   • การตรวจสอบประสิทธิภาพจะไม่รายงานเกี่ยวกับคำขอเครือข่ายที่มีส่วนหัว Content-Type ที่ไม่ถูกต้อง อย่างไรก็ตาม คำขอเครือข่ายที่ไม่มีส่วนหัว Content-Type จะยังคงได้รับการยอมรับ

ข้อมูลคำขอเครือข่ายไม่รวบรวมข้อมูลตามที่คาดไว้

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่การตรวจสอบประสิทธิภาพรวบรวมข้อมูลคำขอเครือข่ายภายใต้รูปแบบ URL

คุณยังลองใช้รูปแบบ URL ที่กำหนดเองได้ด้วย

เกิดอะไรขึ้นกับปัญหาที่พบบ่อยในการ์ดประสิทธิภาพในหน้าแรกของโปรเจ็กต์

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

ตัวเลือกแอปที่ด้านบนของการ์ดประสิทธิภาพจะกรองรายการการแจ้งเตือนในส่วนการแจ้งเตือนล่าสุด ระบบจะแสดงเฉพาะการแจ้งเตือน 3 รายการล่าสุด สำหรับแอปที่เลือกเท่านั้น

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

เกิดอะไรขึ้นกับความสามารถในการตั้งค่าเกณฑ์สำหรับปัญหาในคอนโซล

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

เกิดอะไรขึ้นกับข้อมูลรายละเอียดและเมตริกในคอนโซล Firebase

เราเปลี่ยนหน้ารายละเอียดและเมตริกด้วยอินเทอร์เฟซผู้ใช้ (UI) ส่วนกลางที่ออกแบบใหม่เพื่อปรับปรุงวิธีแก้ปัญหา UI การแก้ปัญหาใหม่นี้มีฟังก์ชันหลักแบบเดียวกับ "รายละเอียดและเมตริก" ดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ปัญหาได้ที่ดูข้อมูลเพิ่มเติมสำหรับการติดตามที่เฉพาะเจาะจง

เหตุใดจำนวนตัวอย่างจึงไม่ใช่จำนวนที่ฉันคาดหวัง

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

การตรวจสอบประสิทธิภาพจะใช้ตัวเลือกการสุ่มตัวอย่างต่อไปนี้เพื่อจัดการปริมาณข้อมูลที่เรารวบรวม

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

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

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

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

  • จำนวนการติดตามอาจแตกต่างจากจำนวนครั้งที่เรียกใช้โค้ดชิ้นหนึ่ง
  • การติดตามที่มีการเชื่อมต่ออย่างใกล้ชิดในโค้ดแต่ละรายการอาจมีจำนวนตัวอย่างต่างกัน

เกิดอะไรขึ้นกับแท็บปัญหาในคอนโซล

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

เกิดอะไรขึ้นกับแท็บในอุปกรณ์และเครือข่ายในคอนโซล ฉันจะดูการติดตามในหน้าเหล่านั้นได้อย่างไร

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

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

ดูการติดตามในแท็บย่อยต่อไปนี้ของตารางการติดตาม

• การติดตามคำขอเครือข่าย (ทั้งในตัวและที่กำหนดเอง) — แท็บย่อยคำขอเครือข่าย
• การติดตามโค้ดที่กำหนดเอง — แท็บย่อยการติดตามที่กำหนดเอง
• การเริ่มแอป การติดตามในเบื้องหน้า การติดตามในแอปในเบื้องหลัง — แท็บย่อยการติดตามที่กำหนดเอง
• การติดตามการแสดงผลหน้าจอ — แท็บย่อยการแสดงผลหน้าจอ
• การติดตามการโหลดหน้าเว็บ — แท็บย่อยการโหลดหน้าเว็บ

ดูรายละเอียดเกี่ยวกับตารางการติดตามรวมถึงการดูเมตริกและข้อมูลได้ที่หน้าภาพรวมคอนโซล (iOS+ | Android | เว็บ)

เหตุใดจำนวนเฟรมที่ช้าและค้างจึงไม่ใช่จำนวนที่คาดไว้

เฟรมการแสดงผลช้าและเฟรมที่ค้างจะคำนวณโดยใช้อัตราการรีเฟรชอุปกรณ์สมมติที่ 60Hz หากอัตราการรีเฟรชอุปกรณ์ต่ำกว่า 60Hz แต่ละเฟรมจะใช้เวลาในการแสดงผลช้าลงเนื่องจากมีการแสดงเฟรมต่อวินาทีน้อยลง เวลาแสดงผลที่ช้าลงอาจทำให้รายงานเฟรมช้าหรือค้างมากขึ้นเพราะเฟรมจำนวนมากขึ้นจะแสดงผลช้าลงหรือค้าง อย่างไรก็ตาม หากอัตราการรีเฟรชอุปกรณ์สูงกว่า 60Hz แต่ละเฟรมจะใช้เวลาแสดงผลที่เร็วขึ้น ซึ่งอาจทําให้การรายงานเฟรมที่ช้าหรือค้างน้อยลง นี่เป็นข้อจำกัดปัจจุบันใน Performance Monitoring SDK

ข้อมูล Performance Monitoring ของฉันใช้เวลาในการส่งออกไปยัง BigQuery นานกว่าที่คาดไว้ นี่ไม่ใช่แบบเรียลไทม์ใช่ไหม

หากคุณเปิดใช้การผสานรวม BigQuery สำหรับการตรวจสอบประสิทธิภาพของ Firebase ระบบจะส่งออกข้อมูลของคุณไปยัง BigQuery ภายใน 12 ถึง 24 ชั่วโมงหลังจากสิ้นสุดวัน (เวลาเขตแปซิฟิก)

ตัวอย่างเช่น ข้อมูลของวันที่ 19 เมษายนจะพร้อมใช้งานใน BigQuery ตั้งแต่เวลา 12:00 น. ถึงเที่ยงคืน (วันที่และเวลาทั้งหมดเป็นเวลาแปซิฟิก)

ข้อมูลประสิทธิภาพแบบ "เกือบเรียลไทม์" หมายความว่าอย่างไร

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

ในการใช้ประโยชน์จากการประมวลผลข้อมูลแบบเกือบเรียลไทม์ ให้ตรวจสอบว่าแอปของคุณใช้เวอร์ชัน SDK ที่เข้ากันได้แบบเรียลไทม์

ฉันจะรับข้อมูลประสิทธิภาพแบบเกือบเรียลไทม์ของแอปได้อย่างไร

เพื่อใช้ประโยชน์จากการประมวลผลข้อมูลแบบเกือบเรียลไทม์ เพียงแค่ต้องแน่ใจว่าแอปใช้เวอร์ชัน Performance Monitoring SDK ที่เข้ากันได้กับการประมวลผลข้อมูลแบบเรียลไทม์เท่านั้น

ต่อไปนี้คือเวอร์ชัน SDK ที่เข้ากันได้แบบเรียลไทม์

• iOS — v7.3.0 ขึ้นไป
• tvOS — v8.9.0 ขึ้นไป
• Android — v19.0.10 ขึ้นไป (หรือ Firebase Android BoM v26.1.0 ขึ้นไป)
• เว็บ — v7.14.0 ขึ้นไป

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

Performance Monitoring SDK เวอร์ชันใดถือว่าเข้ากันได้แบบเรียลไทม์

เวอร์ชัน SDK ต่อไปนี้คือเวอร์ชันที่รองรับการประมวลผลข้อมูลแบบเรียลไทม์

• iOS — v7.3.0 ขึ้นไป
• tvOS — v8.9.0 ขึ้นไป
• Android — v19.0.10 ขึ้นไป (หรือ Firebase Android BoM v26.1.0 ขึ้นไป)
• เว็บ — v7.14.0 ขึ้นไป

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

จะเกิดอะไรขึ้นหากฉันไม่อัปเดตแอปเพื่อใช้ SDK เวอร์ชันที่เข้ากันได้แบบเรียลไทม์

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

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

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

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