ผลลัพธ์ SQL ขนาดใหญ่ผ่าน VPN: แถวรออยู่ที่ไหน

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

สามช่วง หนึ่งนาฬิกาจับเวลา

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

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

อ่านการรอก่อนเครือข่าย

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

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

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

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

วางไคลเอนต์ทั้งสองบนนาฬิกาเดียวกัน

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

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

ตัดไบต์ก่อนโทษเส้นทาง

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

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

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