Czas oczekiwania (TTFB) dla skryptów/stylów w witrynie Azure

Question

Mam ten intrygujący problem w witrynie Azure. Moja strona internetowa wykorzystuje 4 pliki skryptów i 3 pliki stylu, z których każdy jest zminimalizowany. Nie są tak duże, największa ma blisko 200 KB. Witryna już się rozpoczęła. Włączono opcję Zawsze włączona na Azure. Kiedy dzwonię do WebApi dla danych, zwraca się < 50ms.

A gdy aplikacja jest przeładowane potrzebuje 250 ms po prostu, żeby pierwszy bajt z najdrobniejszych skryptu, a inni potrzebuje znacznie więcej. Początkowy HTML jest ładowany w 60 ms. Skrypty/style są buforowane, więc nie są pobierane, ale czas TTFB zabija wydajność. Powtarza to każde ponowne załadowanie. Aplikacja nie zawiera żadnej zaawansowanej konfiguracji, więc powinna działać znacznie szybciej.

Co może powodować takie problemy?

Answer 1

dobrze ... Są 2 główne problemy ze swojej strony:

1. używasz Azure - drogich usługi słabej wydajności .... Nie pytaj mnie, dlaczego ludzie uważają, że jest to dobra obsługa

2. są przechowywane pliki klienta side-by-side z plików serwera .. natomiast pliki serwerowe powinny być przechowywane w konkretnego serwera, pliki klienta można praktycznie można zjeść z powrotem m ... wszędzie

tak - proszę użyć CDN (lub innego serwera) dla swoich klientów (głównie boczne plików CSS i JS, można rozważyć przeniesienie czcionek i obrazów, jak również)

Answer 2

Domyślam się, że Azures jest zawsze włączony.
Jeśli działa w sposób podobny do tego, który zapewnia CloudFlare, zasadniczo prosi o to żądanie i próbuje go buforować.
W zależności od dokładnej implementacji tej pamięci podręcznej po stronie Azure, może poczekać na zakończenie wyprowadzania skryptów, aby ją buforować/zweryfikować pamięć podręczną, a następnie przekazać ją do przeglądarki.

Możliwe, że masz szansę sprawdzenia konfiguracji buforowania i jeśli to możliwe, zawsze wyłączaj skrypty.

Answer 3

Skrypty i style są plikami statycznymi i domyślnie są kompresowane (można to sprawdzić za pomocą nagłówka HTTP "kodowanie treści": gzip) przed wysłaniem do klienta. TTFB składa się zatem z opóźnień sieciowych, harmonogramu kanałów HTTP przeglądarki i statycznego czasu kompresji plików z serwera.

Z drugiej strony dane Web API są danymi dynamicznymi i domyślnie nie są skompresowane, więc ich wartość TTFB jest mniejsza niż TTFB dla plików statycznych.

Jednak nie trzeba wyłączać kompresji statycznej, w przeciwnym razie TTFB zostanie zminimalizowany, ale czas przesyłania treści zostanie wydłużony. W rzeczywistości nie musisz martwić się o TTFB, zobacz więcej informacji: https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Answer 4

Chociaż twoje pliki statyczne są buforowane, przeglądarka wciąż wysyła żądania z if-modifies-since header (co daje 304).

Nie trzeba pobierać rzeczywistej zawartości, ale trzeba jeszcze poczekać, aż serwer RTT + poświęci czas na kontynuację.

chciałbym zaproponować dwie rzeczy:

1. Dodawanie Cache-Control i wygasa nagłówki - pomoże uniknąć 304 w niektórych przypadkach (dość dużo, chyba że trafisz F5)
2. Korzystanie z właściwego CDN - takie jak Incapsula lub inne, które zminimalizują czas myślenia RTT +. Może być również używany do łatwego kontrolowania ustawień pamięci podręcznej dla różnych zasobów.

Więcej dobrych rzeczy tutaj.

Powodzenia!

Answer 5

Skończyłem z przechowywaniem plików w usłudze Azure Storage i udostępnianiem ich przez Azure CDN. Zapewnia dużą szybkość reakcji i nic nie kosztuje. Dodaję je do każdego bloga w wydaniu pre-build Gulpa.

Answer 6

Od here:

Jak widzieliśmy wcześniej, IIS 7 buforuje skompresowane wersje statycznych plików. Tak więc, jeśli przychodzi żądanie dla pliku statycznego, którego skompresowana wersja jest już w pamięci podręcznej, nie trzeba ponownie kompresować .

Ale co, jeśli w pamięci podręcznej nie ma skompresowanej wersji? Czy IIS 7 skompresuje plik od razu i umieści go w pamięci podręcznej? Odpowiedź jest twierdząca, ale tylko w przypadku częstego żądania pliku. Aby nie kompresować plików, które są wymagane tylko nieczęsto, usługa IIS 7 zapisuje użycie procesora i przestrzeń pamięci podręcznej.

Domyślnie plik jest często żądany, jeśli jest wymagany żądany dwa lub więcej razy na 10 sekund.

Powodem, dla którego użytkownicy są obsługiwani przez nieskompresowaną wersję pliku javascript, jest to, że nie osiągnął on domyślnego progu kompresji; innymi słowy, plik javascript nie był wymagany 2 razy w ciągu 10 sekund.

Aby to kontrolować, musimy zmienić jeden atrybut na elemencie <serverRuntime>, który kontroluje kompresję: frequentHitThreshold. Aby pliku mają być kompresowane, kiedy jest to wymagane raz, zmienić elementu <serverRuntime> wyglądać tak:

<serverRuntime enabled="true" frequentHitThreshold="1" /> 

To będzie nieznacznie wpłynąć na wydajność procesora, jeśli masz wiele plików JavaScript, które są podawane i masz użytkownicy dość często, ale prawdopodobne, jeśli masz wystarczająco często użytkowników, aby wpłynąć na procesor z kompresowania tych plików, są one już skompresowane i zapisane w pamięci podręcznej!