ปัญหาและวิธีแก้ไขประสิทธิภาพการทำงานของแอปพื้นที่ทำงานทั่วไป

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

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

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

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

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

การโหลดชุดข้อมูลขนาดใหญ่อย่างช้าๆ บนแพลตฟอร์มต่างๆ

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

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

เรียกข้อมูลคอลัมน์มากเกินไป

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

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

หากต้องการเปิดคุณลักษณะการเลือกคอลัมน์ที่ชัดเจนในแอปพื้นที่ทำงาน ให้ไปที่ การตั้งค่า > คุณลักษณะที่กําลังจะมาถึง > ตัวอย่าง แล้วเปิดตัวสลับ การเลือกคอลัมน์ที่ชัดเจน

เบราว์เซอร์ที่ไม่สนับสนุนหรือเบราว์เซอร์แบบดั้งเดิม

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

ประสิทธิภาพช้า เนื่องจากระยะทางทางภูมิศาสตร์

ตำแหน่งทางภูมิศาสตร์ของสภาพแวดล้อมและระยะทางของแหล่งข้อมูลจากผู้ใช้ สามารถส่งผลต่อประสิทธิภาพ

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

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

ไม่ได้กำหนดค่ารายการที่อนุญาต

ตรวจสอบว่าไม่ได้บล็อก URL บริการที่จำเป็นหรือ URL ดังกล่าวมีการเพิ่มในรายการที่อนุญาตของไฟร์วอลล์แล้ว สำหรับรายการของ URL บริการทั้งหมดที่ต้องได้รับอนุญาตสำหรับ Power Apps ไปที่ บริการที่จำเป็น

การใช้งานของฟังก์ชันที่ไม่สามารถมอบสิทธิ์ได้และขีดจำกัดแถวข้อมูลที่ไม่เหมาะสมสำหรับการสอบถามที่ไม่สามารถมอบสิทธิ์ได้

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

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

ข้อมูลเพิ่มเติม: ใช้การมอบสิทธิ์ ภาพรวมการมอบสิทธิ์

เหตุการณ์ OnStart ต้องการการปรับแต่ง

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

ส่วนต่อไปนี้อธิบายถึงปัญหาที่พบบ่อยที่สุดบางส่วนที่พบในสถานการณ์เหล่านี้

การเรียกจำนวนมากในเหตุการณ์ OnStart ที่ทำให้แอปเริ่มทำงานช้า

ในองค์กร ปริมาณการเรียกข้อมูลไปยังแหล่งข้อมูลส่วนกลาง สามารถผลักดันคอขวดของเซิร์ฟเวอร์หรือการแย่งชิงทรัพยากร

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

เวลาแฝงในเหตุการณ์ OnStart เนื่องจากมีสคริปต์จำนวนมาก

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

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

ข้อมูลเพิ่มเติม: เพิ่มประสิทธิภาพคุณสมบัติ OnStart

ความดันหน่วยความจำที่ฝั่งไคลเอ็นต์

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

กอง JavaScript (JS) อาจถึงขีดจำกัด เนื่องจากมีสคริปต์จำนวนมากที่ทำงานที่ฝั่งไคลเอ็นต์สำหรับการเพิ่ม การรวม การกรอง การเรียงลำดับ หรือการจัดกลุ่มคอลัมน์ ในกรณีส่วนใหญ่ ข้อยกเว้นหน่วยความจำที่ไม่เพียงพอที่กองในไคลเอนต์ สามารถทริกเกอร์แอปให้หยุดทำงานหรือค้าง

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

หากการดำเนินการกับไคลเอ็นต์จำนวนมาก เช่น JOIN หรือ จัดกลุ่มโดย เกิดขึ้นที่ฝั่งไคลเอ็นต์ที่มีชุดข้อมูลที่มีเรกคอร์ด 2,000 รายการขึ้นไป วัตถุในกองจะเพิ่มขึ้น ซึ่งส่งผลให้เกินขีดจำกัดหน่วยความจำ

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

ข้อควรพิจารณาด้านประสิทธิภาพสำหรับตัวเชื่อมต่อ SQL Server

คุณสามารถใช้ ตัวเชื่อมต่อ SQL Server สำหรับ Power Apps เพื่อเชื่อมต่อกับ SQL Server ในสถานที่ หรือ Azure SQL Database ส่วนนี้อธิบายปัญหาทั่วไปเกี่ยวกับประสิทธิภาพและวิธีแก้ไขสำหรับการใช้ตัวเชื่อมต่อนี้สำหรับแอปพื้นที่ทำงาน ข้อมูลเพิ่มเติม: เชื่อมต่อกับ SQL Server จาก Power Apps สร้างแอปพื้นที่ทำงานจาก Azure SQL Database

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

การสอบถาม N+1

แกลเลอรีที่สร้างคำขอไปยังเซิร์ฟเวอร์มากเกินไป ทำให้เกิดปัญหาการสอบถาม N + 1 ปัญหาการสอบถาม N+1 เป็นหนึ่งในปัญหาที่พบบ่อยที่สุดกับการใช้ตัวควบคุม แกลเลอรี

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

การสแกนตาราง แทนการค้นหาดัชนี

แอปอาจทำงานช้าลง หากฟังก์ชันที่แอปใช้เรียกใช้การสอบถามในฐานข้อมูลที่ส่งผลให้มีการสแกนตารางแทนที่การค้นหาดัชนี ข้อมูลเพิ่มเติม: คำแนะนำ Table SCAN และ Index SEEK

ในการแก้ไขปัญหาดังกล่าว ให้ใช้ StartsWith แทน IN ในสูตร ด้วยแหล่งข้อมูล SQL ตัวดำเนินการ StartsWith ส่งผลต่อการค้นหาดัชนี แต่ตัวดำเนินการ IN ส่งผลต่อการสแกนดัชนีหรือตาราง

การสอบถามที่ช้า

คุณสามารถจัดทำโปรไฟล์และปรับแต่งการสอบถามและดัชนีที่ช้าบนฐานข้อมูล SQL ตัวอย่างเช่น หากสูตรรับข้อมูลบางอย่างที่มีลำดับจากมากไปหาน้อย (DESC) ในคอลัมน์หนึ่งคอลัมน์ คอลัมน์ที่เรียงลำดับนั้นควรมีดัชนีที่มีลำดับจากมากไปหาน้อย คีย์ดัชนีจะสร้างลำดับจากน้อยไปมาก (ASC) ตามค่าเริ่มต้น

นอกจากนี้ คุณยังตรวจสอบที่อยู่ URL ของคำขอข้อมูลได้อีกด้วย ตัวอย่างเช่น ส่วนย่อยคำขอข้อมูลต่อไปนี้ (การเรียก OData บางส่วน) ขอให้ SQL ส่งคืนเรกคอร์ด 500 รายการที่ตรงกับคอลัมน์ไปยัง ค่า และเรียงลำดับตาม ID ตามลำดับจากมากไปหาน้อย

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

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

ตรวจสอบแผนการดำเนินการของการสอบถามที่ช้า เพื่อดูว่ามีการสแกนตารางหรือดัชนีใดๆ หรือไม่ ตรวจสอบค่าใช้จ่ายที่มากเกินไปใดๆ ของ Key Lookup ในแผนการดำเนินการ

ข้อมูลเพิ่มเติม:

• ตรวจสอบและปรับแต่งสำหรับประสิทธิภาพการทำงาน
• การตรวจสอบประสิทธิภาพโดยใช้ Query Store
• ภาพรวมกิจกรรมเพิ่มเติม

การแย่งชิงทรัพยากรฐานข้อมูล

ตรวจสอบให้แน่ใจว่าฐานข้อมูล—ของแหล่งข้อมูล—ไม่มีการแย่งชิงทรัพยากร เช่น คอขวดของตัวประมวลผล การแย่งชิง I/O ความดันหน่วยความจำ หรือการแย่งชิง tempDB นอกจากนี้ ตรวจสอบการล็อก การรอ การหยุดชะงัก และการหมดเวลาของแบบสอบถาม

ลูกค้าจำนวนมาก หรือคำขอมากเกินไป

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

ในสถานการณ์เช่นนี้ ให้ใช้วัตถุ มุมมอง ในฐานข้อมูล SQL สำหรับการดำเนินการ จัดกลุ่มตาม กรองตาม หรือ JOIN มุมมองสามารถใช้คอลัมน์ที่เลือก และลบคอลัมน์ที่ไม่จำเป็นที่มีชนิดข้อมูลขนาดใหญ่ เช่น NVARCHAR(MAX), VARCHAR(MAX) และ VARBINARY(MAX)

ขนาดข้อมูลที่ถ่ายโอนไปยังไคลเอนต์

ตามค่าเริ่มต้น แอปพื้นที่ทำงานจะแสดงข้อมูลโดยใช้ตาราง หรือมุมมอง จากวัตถุฐานข้อมูลที่มีอยู่ การดึงคอลัมน์ทั้งหมดจากตารางอาจทำให้การตอบสนองช้า โดยเฉพาะอย่างยิ่งเมื่อใช้ชนิดข้อมูลขนาดใหญ่ เช่น NVARCHAR(MAX)

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

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

ข้อพิจารณาเฉพาะสำหรับ SQL Server ในสถานที่

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

เกตเวย์ข้อมูลภายในองค์กรที่ไม่สมบูรณ์

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

ตรวจสอบว่าโหนดเกตเวย์ข้อมูลในสถานที่ทั้งหมดมีความสมบูรณ์ และกำหนดค่าด้วยเวลาแฝงของเครือข่ายขั้นต่ำระหว่างโหนดและอินสแตนซ์ SQL

ตำแหน่งที่ตั้งของเกตเวย์ข้อมูลในสถานที่

เกตเวย์ข้อมูลต้องการการเรียกเครือข่ายไปยังแหล่งข้อมูลในสถานที่ เพื่อตีความคำขอ OData ตัวอย่างเช่น เกตเวย์ข้อมูลจำเป็นต้องเข้าใจ Schema ตารางข้อมูลเพื่อแปลคำขอ OData เป็นคำสั่งภาษาการจัดการข้อมูล SQL (DML) ค่าใช้จ่ายพิเศษจะถูกเพิ่ม เมื่อมีการกำหนดค่าเกตเวย์ข้อมูลในตำแหน่งที่ตั้งแยกต่างหากที่มีเวลาแฝงของเครือข่ายสูงระหว่างเกตเวย์ข้อมูลและอินสแตนซ์ SQL

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

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

ความสามารถในการปรับสเกลของเกตเวย์ข้อมูล

หากคุณคาดว่าจะเข้าถึงข้อมูลจำนวนมากจากเกตเวย์ข้อมูลในสถานที่ เพียงโหนดเดียวของเกตเวย์ข้อมูลในสถานที่ อาจกลายเป็นคอขวดในการจัดการคำขอจำนวนมากดังกล่าว

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

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

ข้อควรพิจารณาเฉพาะสำหรับ Azure SQL Database

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

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

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

ตรวจสอบระดับบริการของ Azure SQL Database ระดับที่ต่ำกว่าจะมีขีดจำกัดและข้อจำกัดบางประการ จากมุมมองด้านประสิทธิภาพ CPU, ปริมาณงาน I/O และเวลาแฝง เป็นสิ่งสำคัญ ดังนั้น เราแนะนำให้คุณตรวจสอบประสิทธิภาพของฐานข้อมูล SQL เป็นระยะ และตรวจสอบว่าการใช้ทรัพยากรเกินเกณฑ์หรือไม่ ตัวอย่างเช่น SQL Server ในสถานที่ โดยปกติจะตั้งค่าขีดจำกัดของการใช้งาน CPU ไว้ที่ประมาณ 75 %

ข้อควรพิจารณาด้านประสิทธิภาพสำหรับตัวเชื่อมต่อ SharePoint

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

คอลัมน์การค้นหาแบบไดนามิกมากเกินไป

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

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

คอลัมน์รูปภาพและไฟล์แนบ

ขนาดของรูปภาพ และไฟล์ที่แนบสามารถกระจายไปยังการตอบสนองที่ช้า ในขณะที่ดึงข้อมูลไปยังไคลเอนต์

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

ในการสอบถามเฉพาะคอลัมน์ที่แอปใช้ ให้เปิดใช้งานคุณลักษณะการเลือกคอลัมน์ที่ชัดเจน ดังที่ อธิบายไว้ก่อนหน้านี้ในบทความนี้

รายการขนาดใหญ่

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

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

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

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

ข้อควรพิจารณาด้านประสิทธิภาพสำหรับการใช้ Dataverse เป็นแหล่งข้อมูล

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

แอปพื้นที่ทำงานที่เชื่อมต่อกับ Dataverse อาจทำงานได้ช้า หากรันการเขียนสคริปต์ที่มีไคลเอนต์จำนวนมาก เช่น กรองตาม หรือ JOIN ที่ฝั่งไคลเอ็นต์ แทนที่จะเป็นฝั่งเซิร์ฟเวอร์

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

ข้อควรพิจารณาด้านประสิทธิภาพสำหรับตัวเชื่อมต่อ Excel

ตัวเชื่อมต่อ Excel ให้การเชื่อมต่อจากแอปพื้นที่ทำงานไปยังข้อมูลในตารางในไฟล์ Excel ตัวเชื่อมต่อนี้มีข้อจำกัดเมื่อเทียบกับแหล่งข้อมูลอื่นs—ตัวอย่างเช่น ฟังก์ชัน สามารถมอบสิทธิ์ได้ ที่จำกัด—ซึ่งจำกัดแอปพื้นที่ทำงานให้โหลดข้อมูลจากตารางสูงสุด 2,000 เรกคอร์ดเท่านั้น หากต้องการโหลดมากกว่า 2,000 รายการ ให้แบ่งพาร์ติชันข้อมูลของคุณในตารางข้อมูลต่างๆ เป็นแหล่งข้อมูลอื่น

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

ตารางข้อมูลมากเกินไปและขนาดข้อมูลขนาดใหญ่

แอปอาจดำเนินการล่าช้า เมื่อใช้ไฟล์ Excel ที่มีตารางข้อมูลมากเกินไป หรือตารางข้อมูลที่มีข้อมูลขนาดใหญ่มากในหลายๆ คอลัมน์ ไฟล์ Excel ไม่ใช่ฐานข้อมูลเชิงสัมพันธ์ หรือแหล่งข้อมูลที่ให้ฟังก์ชันที่สามารถมอบสิทธิ์ได้ Power Apps ต้องโหลดข้อมูลจากตารางข้อมูลที่กำหนดไว้ก่อน แล้วจึงใช้ฟังก์ชันต่างๆ เช่น Filter, Sort, JOIN, Group By และ Search

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

เพื่อให้แน่ใจว่าแอปของคุณไม่ได้รับผลกระทบจากปัญหานี้ ให้กำหนดเฉพาะคอลัมน์ที่คุณต้องการบนตารางข้อมูลในไฟล์ Excel

ธุรกรรมจำนวนมาก

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

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

หากคุณมีข้อมูลแบบอ่านอย่างเดียว คุณสามารถนำเข้าข้อมูลดังกล่าวลงในแอปภายในเครื่อง แทนที่จะโหลดจากแหล่งข้อมูล สำหรับแอปขององค์กร ให้ใช้แหล่งข้อมูล เช่น Dataverse, SQL Server หรือ SharePoint แทน

ขนาดไฟล์

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

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

ตำแหน่งที่ตั้งไฟล์

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

ซึ่งควรเก็บไฟล์ไว้ใกล้ผู้ใช้ของคุณ (หรือผู้ใช้ส่วนใหญ่ ถ้าคุณมีผู้ชมส่วนกลาง) เพื่อให้สามารถดาวน์โหลดไฟล์ได้อย่างรวดเร็ว

ขั้นตอนถัดไป

เคล็ดลับและแนวทางปฏิบัติที่ดีที่สุดเพื่อปรับปรุงประสิทธิภาพแอปพื้นที่ทำงาน

ดูเพิ่มเติม

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