Dlaczego gadatliwa aplikacja SQL wlecze się przez VPN i co warto łączyć w partie

Formularz, który w sieci lokalnej otwiera się w mniej niż sekundę, przez VPN zajmuje pięć sekund, podczas gdy kopiowanie pliku tym samym łączem idzie z pełną prędkością. Różnicą nie jest przepustowość. Formularz czeka na sekwencję odpowiedzi i na każdym kroku płaci całą rundę, a kopiowanie pliku utrzymuje bajty w ciągłym locie. Policz te czekania, zanim dotkniesz łącza dostępowego.

Objawem jest ekran, a nie zapytanie

Każde zapytanie na tym ekranie może być szybkie, a ekran wciąż może być wolny, bo suma to suma czekań, a nie suma czasów wykonania. Instrukcja wykonująca się w dwie milisekundy nadal kosztuje całą rundę, gdy klient musi odebrać wynik, zanim wyśle następną. Na ścieżce z opóźnieniem czterdziestu milisekund sto zależnych wywołań sumuje się do około czterech sekund, zanim zacznie się jakakolwiek praca renderowania. Ta arytmetyka jest modelem czekania, a nie pomiarem twojego łącza.

Dlatego test prędkości wygląda niewinnie. Duży transfer mierzy przepustowość, gadatliwy formularz mierzy opóźnienie, a VPN może być znakomity w jednym, pozostając zwyczajny w drugim. Diagnozowanie ekranu oznacza więc mierzenie ekranu, a nie łącza.

Zapisz czas od początku do końca jednej akcji użytkownika, zanim cokolwiek zmienisz. Ta liczba to jedyna linia odniesienia, która powie ci, czy późniejsza poprawka zadziałała.

Policz sekwencyjne czekania w jednej akcji użytkownika

Instrumentuj klienta zamiast zgadywać. W psql \timing on wypisuje czas, jaki upłynął dla każdej instrukcji, a EXPLAIN (ANALYZE, BUFFERS) pokazuje, ile z tego czasu serwer naprawdę spędził na pracy.

Luka między tymi dwiema liczbami to twój narzut sieci i klienta. Jeśli instrukcja wykonuje się w dwie milisekundy, a klient rejestruje sześćdziesiąt, pozostałe pięćdziesiąt osiem to podróż i przetwarzanie lokalne, i żaden indeks ich nie usunie. Powtórz to porównanie dla każdej instrukcji wysyłanej przez ekran i sumuj luki, a nie czasy wykonania.

Zapisz wynik jako liczbę sekwencyjnych czekań. To właśnie tę wielkość mogą zmniejszyć dwa następne rozdziały, i to liczba, o którą można się spierać z dowodami.

Połącz wywołania niezależne, zachowaj zależne

Dwie instrukcje, które nie czytają swojego wyniku nawzajem, mogą podróżować razem i zostać odebrane raz, co zamienia dwa czekania w jedno. Dwie instrukcje, w których druga potrzebuje wartości pierwszej, nie mogą, bo zależność jest rzeczywista, a łączenie zmieniłoby to, co robi program. Posortuj wywołania do tych dwóch kup przed przepisaniem czegokolwiek, a rozmiar każdej kupy mówi, co jest możliwe.

Praca zbiorcza usuwa czekania gruntowniej niż łączenie. Jedno zapytanie zwracające wiersze, które pętla pobierała po jednym, eliminuje zarówno pętlę, jak i rundy. Szukaj najpierw pętli, bo zwykle daje większy zysk i jest łatwiejszą do przejrzenia zmianą.

Partia nadal musi zachować obsługę błędów i granice transakcji. Sklejanie niepowiązanych instrukcji w jeden łańcuch nie jest bezpieczną optymalizacją, a partia, która ukrywa nieudaną instrukcję za udanym zgłoszeniem, jest gorsza niż zaoszczędzone czekania.

Używaj połączeń ponownie, zanim kupisz przepustowość

Nowe połączenie kosztuje rozwiązywanie nazw, uścisk dłoni TCP, negocjację TLS i uwierzytelnienie, a na ścieżce o wysokim opóźnieniu każde z nich to kolejna runda, zanim wykona się pierwsze zapytanie. Pule połączeń istnieją po to, by płacić ten koszt raz na proces, a nie raz na wywołanie.

W ADO.NET zamknięcie lub dispose połączenia z puli zwraca je do ponownego użycia, zamiast otwierać nowe fizyczne, więc wzorzec wyglądający na wyciek jest często poprawnym użyciem. Sprawdź, czy pula naprawdę jest używana, zamiast to zakładać: loguj tworzenie połączeń fizycznych albo obserwuj liczbę sesji na serwerze, gdy ekran działa. Wskazówki dotyczące wydajności SQL mówią to samo o ograniczaniu rund i łączeniu częstych wywołań ad hoc, z przykładami dla konkretnych usług, które należy przełożyć na własne wdrożenie.

Pulowanie usuwa koszt konfiguracji i pozostawia sekwencyjne czekania zapytań nietknięte. To warunek czystego pomiaru, a nie samodzielna poprawka.

Rozważ przeniesienie wykonania bliżej danych

Uruchamianie aplikacji blisko bazy danych zastępuje wiele zdalnych wymian z bazą jedną zdalną sesją ekranu. Dla gadatliwego obciążenia może to być duża zmiana i jest to zmiana operacyjna w takim samym stopniu jak wydajnościowa: zarządzanie sesjami, kontrola dostępu, wdrażanie oprogramowania i doświadczenie użytkownika przenoszą się razem z aplikacją.

Zmierz rzeczywisty interfejs i dane, które przenosi, zanim uznasz, że któryś kierunek jest szybszy. Zdalna sesja pulpitu przenosi piksele, a ekran z gęstą grafiką może działać gorzej po tej samej ścieżce niż zapytania, które zastąpił, zwłaszcza gdy klient stale przerysowuje.

Potem powtórz pierwotną akcję i porównaj trzy liczby: sekwencyjne czekania, objętość wyników i czas ukończenia od początku do końca. Ulepszenie, które zmienia mierzone zadanie użytkownika, zachowując poprawność danych i politykę dostępu, jest tym, które warto zachować.