დიდი 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';

წაიკითხეთ მთვლელი შეზღუდული დატვირთვის დროს, არა უსაქმური საათის შემდეგ, რადგან კუმულაციური მთვლელები ინსტანციის გაშვებიდან ყველა სესიას ურევს. შეადარეთ დელტა გაშვების განმავლობაში და არა სიცოცხლის ჯამური მაჩვენებელი. გადაცემის დროს მზარდი დელტა კითხვას მოხმარებამდე ან მიწოდებამდე ავიწროებს.

დასვით ორივე კლიენტი ერთ საათზე

გაუშვით შეზღუდული დატვირთვა მონაცემთა ბაზასთან ახლოს მყოფი კლიენტიდან და დისტანციური კლიენტიდან. მოთხოვნა, პარამეტრები, შედეგის ზომა და კავშირის პარამეტრები იდენტურად შეინახეთ. გამოიყენეთ იგივე გაზომვა ორივე მხარეს, რადგან სერვერის შესრულების დრო, ბადის ჩვენების დრო და ექსპორტის დრო სამი სხვადასხვა საათია. სერვერის მხარის რიცხვის შედარება კლიენტის მხარის ექსპორტის ტაიმერთან იძლევა დასკვნას, რომელიც ვერ შემოწმდება.

როცა გზა პასუხისმგებლად გვეჩვენება, სთხოვეთ ქსელის მფლობელს, გადაცემის დროს დააკვირდეს დანაკარგებს, ხელახალ გაგზავნებს და მიღწეულ გამტარუნარიანობას სწორედ ამ ნაკადისთვის. ზოგადი სიჩქარის ტესტი შეიძლება სხვა მარშრუტს, საბოლოო წერტილს ან პარალელურობის ნიმუშს იყენებდეს. პატარა წარმატებული მოთხოვნა ცოტას ამბობს ხანგრძლივი შედეგის გადაცემაზე.

შეამცირეთ ბაიტები, სანამ გზას დაადანაშაულებთ

ფილტრაცია, აგრეგაცია და მხოლოდ საჭირო სვეტების არჩევა ამცირებს როგორც გადაცემის მოცულობას, ისე იმ სამუშაოს, რომელსაც კლიენტი თითოეულ რიგზე ასრულებს. შეინარჩუნეთ განზრახული შედეგი, რადგან ანგარიშს შეიძლება დასჭირდეს დეტალი, რომელიც ეკრანზე არსებულ შეჯამებაში არ არის.

განმეორებადი ექსპორტებისთვის მონაცემთა ბაზასთან ახლოს დამტკიცებულ შესრულების ადგილს შეუძლია განსაზღვრული გამომავალი ჩაწეროს, რომელიც შემდეგ ერთხელ მიეწოდება. ეს ცვლის სამუშაო ნაკადს და მისი წვდომის კონტროლს, და ეს არ არის ნებართვა გაზიარებულ ჰოსტზე შეუზღუდავი dump დატოვოთ.

შეკუმშვა ნაგულისხმევი შესწორება არ არის. მხარდაჭერა და უსაფრთხოება დამოკიდებულია რეალურ პროტოკოლსა და განლაგებაზე, და შეკუმშული ნაკადი, რომელსაც კლიენტი ნელა ხსნის, შეიძლება გამოცდილება გააუარესოს. ჯერ გაზომეთ ეტაპი, შემდეგ აირჩიეთ მხარდაჭერილი ცვლილება ამ ეტაპისთვის.