การวางแผนความจุของรายงานที่มีการแบ่งหน้า
นําไปใช้กับ: รายงาน
ที่มีการแบ่งหน้าของ Power BI บริการของ Power BI
Power BI Desktop
เรียนรู้วิธีการวางแผนความจุพรีเมียมของคุณเพื่อให้ได้ประสิทธิภาพที่ดีที่สุดจากรายงานที่มีการแบ่งหน้าของคุณด้วยต้นทุนต่ําสุด ถ้าคุณกําลังโยกย้ายไปยัง Power BI จากเครื่องมือข่าวกรองธุรกิจอื่น ลองอ่านบทความที่แสดงด้านล่างก่อนที่คุณจะตัดสินใจว่าจะใช้ความจุใด
ภาพรวมการโยกย้ายข้อมูล Power BI
โยกย้ายรายงาน SQL Server Reporting Services ไปยัง Power BI - มุ่งเป้าไปที่ผู้เขียนรายงานและผู้ดูแลระบบ Power BI ที่มีความสนใจในการโยกย้ายรายงาน Report Definition Language (.rdl) ไปยัง Power BI จาก SQL Server Reporting Services (SSRS)
การวางแผนกำลังการผลิต
การคํานวณชนิดของความจุที่คุณต้องการจะขึ้นอยู่กับปัจจัยหลายอย่าง เช่น จํานวนวิชวลในรายงานของคุณ ความซับซ้อนของคิวรีกับรายงานและคุณภาพของแหล่งข้อมูลหรือแบบจําลองข้อมูลของคุณ นอกจากนี้ คุณควรพิจารณาการใช้ความจุของคุณในปัจจุบันในช่วงเวลาสูงสุดก่อนที่คุณจะเพิ่มรายงานที่มีการแบ่งหน้า
ก่อนที่คุณจะเริ่มวางแผนความจุที่คุณต้องการ ให้ตรวจสอบ ตารางความจุและ SKU เพื่อดูว่าแต่ละความจุนําเสนอทรัพยากรใดบ้าง
เมื่อคุณวางแผนความจุของคุณ ให้พิจารณาสิ่งต่อไปนี้:
ความซับซ้อนของการออกแบบรายงาน Tablix ที่ซ้อนกัน รายงานย่อยหลายรายการและกลุ่มแถวและคอลัมน์หลายรายการเพิ่มความซับซ้อนของการออกแบบและต้องการทรัพยากรความจุ
จํานวนข้อมูลที่ดึงโดยรายงาน ยิ่งรายงานต้องการข้อมูลมากเท่าไหร่ ทรัพยากรที่ต้องการจากความจุของคุณก็ยิ่งมากขึ้นเท่านั้น
วิธีที่รายงานของคุณดึงข้อมูล เมื่อคุณใช้ตัวเชื่อมต่อ ไดรเวอร์หรือเกตเวย์ การดึงข้อมูลอาจใช้เวลานานขึ้น จําเป็นต้องใช้ทรัพยากรเพิ่มเติม และทําให้มีราคาแพงมากขึ้น
เมื่อคุณส่งออกรายงานขนาดใหญ่ในรูปแบบเช่น Excel และ PDF จําเป็นต้องใช้ทรัพยากรมากกว่าการอ่านทุกหน้า โดยใช้การสลับ และการค้นหาภายในรายงาน
SKU รองรับผู้ใช้จํานวนกี่คน
ในการทดสอบรายงานที่มีการแบ่งหน้าบนความจุที่แตกต่างกัน เราได้ดําเนินการปริมาณงานที่แตกต่างกันสามประเภทกับขนาด SKU ที่แตกต่างกัน ปริมาณงานแต่ละตัวประกอบด้วยการแสดงรายงานเดี่ยวพร้อมกันที่มีขนาดแตกต่างกัน
Small – ตารางการรวมข้อมูลที่สร้างขึ้นมากกว่า 100 แถวจากแหล่งข้อมูล Azure SQL
ปานกลาง – ตารางการรวมข้อมูลที่สร้างขึ้นจากแหล่งข้อมูล Azure SQL มากกว่า 100,000 แถว
ขนาดใหญ่ - ตารางการรวมข้อมูลที่สร้างขึ้นจากแหล่งข้อมูล Azure SQL มากกว่า 250,000 แถว
การวิเคราะห์ของเราสําหรับ Power BI Premium แสดงให้เห็นว่า จํานวนผู้ใช้พร้อมกันในเวลาใดๆ รวมถึงเวลาสูงสุดประจําวัน ไม่มีแนวโน้มเกินห้าเปอร์เซ็นต์ของฐานผู้ใช้ทั้งหมด
ตารางต่อไปนี้อธิบายถึงจํานวนสูงสุดโดยประมาณของผู้ใช้ที่ SKU สามารถจัดการได้ ก่อนที่จะ โอเวอร์โหลด โดยขึ้นอยู่กับอัตราส่วนการเกิดพร้อมกันห้าเปอร์เซ็นต์ เมื่อความจุของคุณโอเวอร์โหลด การจํากัดการใช้งานจะเกิดขึ้นกับความจุของคุณ สําหรับข้อมูลเพิ่มเติม ให้ดู เกิดอะไรขึ้นกับปริมาณการใช้งานในระหว่างการโอเวอร์โหลดถ้าฉันไม่ปรับขนาดอัตโนมัติ
ปริมาณงาน | F64 หรือ P1 SKU | F128 หรือ P2 SKU |
---|---|---|
เล็ก | ผู้ใช้ 2,500 คน | ผู้ใช้ 5,000 ราย |
กลาง | ผู้ใช้ 1,900 คน | ผู้ใช้ 3,800 คน |
ใหญ่ | ผู้ใช้ 1,300 คน | ผู้ใช้ 2,600 คน |
ให้พิจารณาว่าตัวเลขในตารางอ้างอิงถึงความจุที่กําหนดไว้ซึ่งไม่ได้เรียกใช้การดําเนินการอื่น ๆ ความจุของคุณอาจใช้ทรัพยากร CPU สําหรับการดําเนินการเช่น:
การเรียกและการประมวลผลข้อมูล
ปริมาณงานและการทํางานแบบเบื้องหลังอื่นๆ
การจัดกลุ่มและการจัดรูปร่างข้อมูลที่ซับซ้อน
การกรองข้อมูล
คําขอที่เกิดขึ้นพร้อมกัน
ปริมาณงานแต่ละตัวในความจุ รวมถึงปริมาณงานของรายงานที่มีการแบ่งหน้ามีรายงานพร้อมกันสูงสุด 500 รายงานจะแสดงในเวลาที่กําหนด ถ้าความจุของคุณกําลังแสดงรายงาน 100 รายการ และมี 200 คําขอสําหรับ การส่งออกรายงานที่มีการแบ่งหน้า คุณมีคําขอการแสดงผลรายงานพร้อมกัน 200 รายการ
เพื่อหลีกเลี่ยงความแออัด ให้วางแผนการโหลดคําขอที่เกิดขึ้นพร้อมกันล่วงหน้า ถ้าคุณเกินขีดจํากัดของคําขอที่เกิดขึ้นพร้อมกัน คุณจะพบ ข้อผิดพลาด (429) คําขอมากเกินไป
การใช้แอปเมตริก
การใช้แอปเมตริกความจุของ Microsoft Fabric คุณสามารถประเมินผลกระทบของรายงานที่มีการแบ่งหน้าของคุณบนความจุของคุณได้ แอปจะวัดการใช้งาน CPU ของคุณเมื่อเวลาผ่านไป ช่วยให้คุณเข้าใจว่าความจุของคุณทํางานอย่างไร
ในการทดสอบรายงานแบบแบ่งหน้าเราขอแนะนําให้คุณใช้ความจุที่สะอาดเฉพาะ ความจุที่สะอาดช่วยแยกผลลัพธ์ออกจากผลกระทบของผู้ใช้และปริมาณงานอื่น ๆ
ขึ้นอยู่กับสถานการณ์การทดสอบเป้าหมาย ตัวอย่างเช่น ค่าเฉลี่ยหรือการตรวจสอบการใช้งานสูงสุด เลือกหรือสร้างตัวแทนรายงานของการใช้ทรัพยากรที่คาดหวังไว้ และอัปโหลดไปยังพื้นที่ทํางาน Premium/Fabric ในความจุที่คุณสร้างขึ้นสําหรับการทดสอบ
เรียกใช้รายงานหลายครั้ง และใช้แอปเมตริกเพื่อรับจํานวนวินาทีของ CPU โดยเฉลี่ยที่ใช้ในการเรียกใช้รายงานของคุณ เมื่อคํานวณเวลาที่ใช้เพื่อเรียกใช้รายงานของคุณ ให้พิจารณาสิ่งต่อไปนี้:
แอปจะแสดงค่ารวม คุณอาจต้องหารผลลัพธ์ตามจํานวนครั้งที่คุณเรียกใช้รายงาน
มีหลายรายการ Power BI และการดําเนินการที่อาจเกี่ยวข้องกับการแสดงผลรายงาน คุณอาจจําเป็นต้องรวมปริมาณการใช้ CPU ของพวกเขา
มีหลายรายการ Power BI และการดําเนินการที่อาจเกี่ยวข้องกับการแสดงผลรายงานเนื่องจากการแสดงผลอาจใช้เวลานาน การดําเนินการที่นานใน หน้า Timepoint สามารถแสดงเป็นรายการของการดําเนินการ ที่ไม่มีระยะเวลานานกว่า 30 วินาที คุณอาจจําเป็นต้องรวมปริมาณการใช้ CPU สําหรับการดําเนินการแสดงผล การเรียงลําดับตามเวลาเริ่มต้นสามารถช่วยแสดงประวัติการแสดงผลทั้งหมดได้
คํานวณการแสดงผลรายงานสูงสุด
ใช้สูตรนี้เพื่อคํานวณรายงานที่เกิดขึ้นพร้อมกันสูงสุดซึ่งแสดงว่าความจุสามารถจัดการได้ก่อนที่จะโอเวอร์โหลด เมื่อต้องการเรียนรู้เพิ่มเติมเกี่ยวกับหน่วยความจุ (CU), SKU และ Power BI v-cores ดู ที่แนวคิดเกี่ยวกับความจุ
$ \text {max concurrent reports} = {\text {text {capacity units for your capacity} \times {3.75} \over \text {เวลาการประมวลผล CPU ของรายงานของคุณ (เป็นวินาที)} } $
คํานวณจํานวนสูงสุดของผู้ใช้
การใช้ภาวะพร้อมกันห้าเปอร์เซ็นต์โดยประมาณสําหรับความสัมพันธ์ระหว่างจํานวนผู้ใช้ทั้งหมดและการแสดงผลพร้อมกันสูงสุด คุณสามารถรับจํานวนผู้ใช้ทั้งหมดที่ SKU สามารถจัดการได้
$ \text {max SKU users} = {\text {max concurrent report renders} \over 0.05} $
คํานวณทรัพยากรความจุสําหรับรายงานหลายฉบับ
คุณสามารถใช้สูตรแบบขยายเพื่อประเมินความจุที่จําเป็นสําหรับการใช้งานรายงานที่แตกต่างกัน
อัปโหลดรายงานที่มีการแบ่งหน้าหลายรายงานที่มีจํานวนการแสดงผลรายวันที่แตกต่างกัน และใช้แอปเมตริกเพื่อรับเวลาการประมวลผล CPU โดยเฉลี่ยสําหรับแต่ละรายงาน ผลรวมของรายงานทั้งหมดของคุณที่แสดงต่อวันควรเท่ากับ 100% เมื่อคุณมีข้อมูลทั้งหมด ให้ใช้สูตรนี้
$ \text {max concurrent reports} = {\text {text {capacity units for your capacity} \times {3.75} \over {\text {...} \times \text \text {A processing time}} + \text {B renders} \times \text {B processing time} + \text {...} + \text{N renders} \times \text{N processing time}}$
ตัวอย่าง
ส่วนนี้ประกอบด้วยสองตัวอย่าง หนึ่งตัวอย่างสําหรับการคํานวณปกติและอีกตัวอย่างหนึ่งสําหรับการคํานวณขั้นสูง
การคํานวณแบบปกติ
สมมติว่าคุณกําลังเรียกใช้รายงานที่มีการแบ่งหน้าบน F64 หรือ P1 SKU ที่มีแปดแกน การใช้งาน CPU ทั้งหมดสําหรับการเรียกใช้ 10 ครั้งคือ 40 วินาที ดังนั้นเวลา CPU โดยเฉลี่ยต่อรายงานคือสี่วินาที
$ 60 = {8 \times {30} \over 4} $
เมื่อใช้สูตรที่สอง คุณจะได้รับผู้ใช้สูงสุด 1,200 ราย
$ 1,200 = {60 \over 0.05} $
สําหรับ F128 หรือ P2 SKU คุณสามารถคูณจํานวนเหล่านี้ได้โดยสองเนื่องจากความจุมีจํานวนแกน CPU เป็นสองเท่า
การคํานวณขั้นสูง
สมมติว่าคุณมีรายงานที่มีการแบ่งหน้าสามฉบับที่มีเปอร์เซ็นต์การแสดงผลรายวันที่แสดงอยู่ในตารางด้านล่าง
รายงาน | จํานวนของรายงานที่แสดงผลต่อวัน | เวลาการประมวลผล CPU (เป็นวินาที) |
---|---|---|
ท | 60% | 4 |
B | 30% | 10 |
C | 10% | 20 |
สูตรสําหรับ F64 หรือ P1 SKU จะเป็น:
ค่า | สูตร |
---|---|
การแสดงผลรายงานที่เกิดขึ้นพร้อมกันสูงสุด | $ ~ 32.4 = {8 \times {30} \over 0.6 \times{4} + 0.3 \times{10} + 0.1 \times{20}} $ |
ผู้ใช้ SKU ทั้งหมด | $ ~ 650 = {32.4 \over 0.05} $ |