რატომ ცოცავს მრავალმოთხოვნიანი SQL აპლიკაცია VPN-ზე და რა უნდა დაჯგუფდეს

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

სიმპტომი ეკრანია და არა მოთხოვნა

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

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

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

დათვალეთ თანმიმდევრული ლოდინები ერთ მომხმარებლის მოქმედებაში

გაზომეთ კლიენტში და ნუ გამოიცნობთ. psql-ში \timing on ბეჭდავს თითოეული განცხადების გასულ დროს, და EXPLAIN (ANALYZE, BUFFERS) გვიჩვენებს რამდენი დახარჯა სერვერმა ამ დროიდან რეალურად სამუშაოზე.

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

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

დააჯგუფეთ დამოუკიდებელი გამოძახებები, დატოვეთ დამოკიდებულები

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

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

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

სანამ გამტარობას იყიდით, კავშირები ხელახლა გამოიყენეთ

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

ADO.NET-ში აუზური კავშირის დახურვა ან გაუქმება აბრუნებს მას ხელახალი გამოყენებისთვის და არ ხსნის ახალ ფიზიკურ კავშირს, ამიტომ გაჟონვას მსგავსი ნიმუში ხშირად სწორი გამოყენებაა. დაადასტურეთ, რომ აუზი ნამდვილად გამოიყენება და ნუ ჩათვლით: ჩაწერეთ ფიზიკური კავშირების შექმნა ან დააკვირდით სერვერზე სესიების რაოდენობას, სანამ ეკრანი მუშაობს. SQL-ის წარმადობის სახელმძღვანელო იმავეს ამბობს მოგზაურობების შემცირებასა და ხშირი ad hoc გამოძახებების დაჯგუფებაზე, სერვისისთვის დამახასიათებელი მაგალითებით, რომლებიც თქვენს განლაგებაზე უნდა გადაიტანოთ.

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

აწონეთ შესრულების მონაცემებთან უფრო ახლოს გადატანა

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

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

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