C

url może być pomocnym narzędziem przy debugowaniu. Gdy na rozpoznanie problemu składają się problemy z: siecią, DNS, serwerem lub wydajnością samej webaplikacji – możemy bez wahania po niego sięgnąć. W celu izolacji problemu możemy uruchomić curl’a w następujący sposób:

curl -w "$(date +%FT%T) dns: %{time_namelookup} connect: %{time_connect}\
 firstbyte: %{time_starttransfer} total: %{time_total} HTTP: %{http_code}\n"\
 -o /dev/null -s "https://apka.dev"

Polecenie takie puszczone w pętli da nam ładny podgląd na każde żądanie HTTP:

00:05:45 dns: 0.060664 connect: 0.060947 firstbyte: 0.356445 total: 0.406772 HTTP: 200
00:05:45 dns: 0.060646 connect: 0.060937 firstbyte: 0.378697 total: 0.438995 HTTP: 200
00:05:45 dns: 0.060639 connect: 0.060928 firstbyte: 0.364003 total: 0.417276 HTTP: 200
00:05:45 dns: 0.060695 connect: 0.060980 firstbyte: 0.354468 total: 0.407462 HTTP: 200
00:05:45 dns: 0.012455 connect: 0.012728 firstbyte: 0.290889 total: 0.343331 HTTP: 200
00:05:45 dns: 0.012495 connect: 0.012780 firstbyte: 0.320539 total: 0.373262 HTTP: 200
00:05:45 dns: 0.012436 connect: 0.012727 firstbyte: 0.296931 total: 0.348798 HTTP: 200
00:05:45 dns: 0.004364 connect: 0.004608 firstbyte: 0.307080 total: 0.359770 HTTP: 200
00:05:45 dns: 0.060583 connect: 0.060874 firstbyte: 0.362638 total: 0.415715 HTTP: 200
00:05:45 dns: 0.004368 connect: 0.004614 firstbyte: 0.286901 total: 0.338624 HTTP: 200

Poszczególne kolumny mogą pomóc nam w identyfikowaniu klas problemów: “dns” – jest oczywiste, “connect” (czyli czas na połączenie) pomaga identyfikować problemy z systemem operacyjnym lub siecią, a “firstbyte” daje wskazówkę na temat reakcji serwera aplikacji; różnica pomiędzy “firstbyte”, a “total” zwykle wskazuje rzeczywisty czas reakcji aplikacji. Co w przypadku trwałych połączeń wykorzystujących możliwości HTTP/1.1 ? Dzięki użyciu przełącznika -K curl pozwala przekazać plik adresów URL do pobrania. Wraz z –keepalive możemy wykonać wielokrotne pobranie tych samych adresów URL w jednym połączeniu. Przykład:

curl -sw "$(date +%FT%T) dns: %{time_namelookup} connect: %{time_connect}\
 firstbyte: %{time_starttransfer} total: %{time_total} HTTP: %{http_code}\n" 
--keepalive -K <(printf 'url="https://apka.dev/"\n%.0s' {1..10000}) 2>/dev/null\
 | grep firstbyte

Polecenie curl wygląda podobnie jak w pierwszej wersji – tylko, że teraz nie potrzebujemy pętli, ponieważ do jej utworzenia używamy trzech elementów magii bash. Na początku przekazujemy sekwencję liczb {1..10000} do printf, czyli liczbę żądań, które chcemy wykonać. Wybieramy do tego zadania wzorzec “% .0s” w printf – liczba nie jest drukowana, a ciąg znaków (adres URL) pozostaje statyczny. W ten sposób otrzymujemy adres URL wydrukowany 10.000 razy jako dane wejściowe do polecenia curl. Używając konstrukcji bash "<()" tworzymy ad hoc uchwyt pliku, którego zawartość przekazujemy do parametru -K. Przekierowanie wyjścia (-o) nie działa podczas pobierania wielu adresów URL za pomocą tej sztuczki z parametrem -K, ponieważ curl oczekuje osobnego uchwytu wyjścia dla każdego adresu URL. Dlatego problem ten jest rozwiązany za pomocą filtrowania z poziomu polecenia: | grep firstbyte:

20:54:58 dns: 0.060630 connect: 0.060953 firstbyte: 0.401369 total: 0.461396 HTTP: 200
20:54:58 dns: 0.000080 connect: 0.000085 firstbyte: 0.221342 total: 0.274136 HTTP: 200
20:54:58 dns: 0.000110 connect: 0.000114 firstbyte: 0.211099 total: 0.262712 HTTP: 200
20:54:58 dns: 0.000055 connect: 0.000058 firstbyte: 0.224127 total: 0.277788 HTTP: 200
20:54:58 dns: 0.000073 connect: 0.000076 firstbyte: 0.208820 total: 0.260877 HTTP: 200
20:54:58 dns: 0.000080 connect: 0.000083 firstbyte: 0.209641 total: 0.261629 HTTP: 200
20:54:58 dns: 0.000079 connect: 0.000082 firstbyte: 0.222640 total: 0.275348 HTTP: 200
20:54:58 dns: 0.000086 connect: 0.000090 firstbyte: 0.222734 total: 0.278043 HTTP: 200
20:54:58 dns: 0.000076 connect: 0.000080 firstbyte: 0.245476 total: 0.329606 HTTP: 200
20:54:58 dns: 0.000087 connect: 0.000091 firstbyte: 0.327699 total: 0.405365 HTTP: 200

Zwróćmy uwagę, że tylko pierwsze czasy dns oraz connect znajdowały się w zakresie milisekund, podczas gdy wszystkie kolejne są zaledwie mikrosekundami wskazującymi na ponowne użycie połączenia i brak nowych zapytań DNS.

Więcej informacji: curl and HTTP 1.1 keepalive test traffic