Czy żądania pamięci podręcznej CURL?

To dość długie pytanie, więc proszę o wyrozumiałość.

Chciałem podkreślić, że mój serwer Akamai zalogowany z instancji AWS. Zacząłem więc testować ab. Wydawało się jednak absurdalnie szybkie pobieranie ~ 3 MB plików wideo. Oczywiście chciałem zobaczyć, co się dzieje. Tak zrobiłem, aby uzyskać plik

curl -v -o / dev / null

Powyższe ukończono w ~ 5 sekund.

Następnie ponownie uruchomiłem to samo polecenie. Tym razem zakończyło się w ~ 200ms! Oczywiście, moja intuicja mówi, że gdzieś plik jest buforowany.

Moje pytania:

1. Czy curl buforuje pliki? Jeśli tak, to czy można to zignorować?
2. Jeśli curl nie, to czy Ubuntu wyodrębnia pamięć podręczną pod curl? Jeśli tak, to czy można to zignorować?
3. Biorąc pod uwagę wymagania, czy uważasz, że może istnieć narzędzie porównawcze oprócz ab, które mogłoby służyć temu celowi?

Dziękuję, Akshay

Klient curl nie buforuje plików, ale równie dobrze może to być zdalna sieć serwerów. Spróbuj dodać dowolną zmienną ciągu zapytania do adresu URL, aby sprawdzić, czy możesz ją odtworzyć.

Z opóźnieniem spróbuj:

curl -v -H "Cache-Control: no-cache"

To powie serwerowi WWW, aby nie buforował. Nie zatrzymuje warstw poniżej buforowania, chyba że jest zakodowane tak, aby były zgodne z nagłówkami.

Użyłem tego polecenia curl z parametrem pomijania pamięci podręcznej.

curl http://example.com/static/changing_file?_=$(date +%s)

date +%sdrukuje sekundy od epoki, jeśli wywołasz adres URL więcej niż raz na sekundę, użyj, date +%s.%Naby dodać w nanosekundach.

Można użyć dodać losowy ciąg kwerendy przy użyciu do $RANDOMzmiennej środowiskowej:

curl --location --silent "https://git.io/lsf-e2e?$RANDOM"

To działało dla mnie na surowych plikach github.

Być może twoje dns buforuje rozdzielczość nazwy i to jest powód różnicy w czasie odpowiedzi.

To tylko teoria.