Czy AWS CloudFront * powinien zwiększyć * czas ładowania plików, do których rzadko uzyskiwany jest dostęp?


9

Jestem nowy w CDN i eksperymentuję z CloudFront. Ustawiłem wszystko i wszystko wydaje się działać dobrze. Mogę utworzyć obraz statyczny na stronie i uzyskać do niego dostęp za pośrednictwem mojej dystrybucji CloudFront. Używam niestandardowego źródła (tj. Nie wiadra s3).

Martwię się, że mogę być gorzej z punktu widzenia wydajności. Mam stronę testową, która ładuje te same 20 obrazów z CDN i bez. Patrząc na panel sieci w Firebug, po raz pierwszy ładuję tę stronę obrazy ładowane bezpośrednio z serwera źródłowego pojawiają się znacznie szybciej. Przy kolejnych ładowaniach strony korzyści CDN stają się oczywiste - po 3-5 odświeżeniach CDN radzi sobie lepiej niż serwer źródłowy.

Widzę więc, że na popularnej stronie w naszej witrynie, która jest ciągle odwiedzana, będzie to korzyść. I powinienem spodziewać się korzyści, ponieważ jestem w Seattle (za rogiem od Amazon), a mój serwer znajduje się w Kalifornii.

Chodzi o to, że jeśli opuszczę stronę na kilka minut, a następnie przeładuję, wszystko wróci do normy, a CloudFront będzie gorszy niż serwer źródłowy. Czy jest to oczekiwane? Czy rzeczy tak szybko wypadają z „pamięci podręcznej” CDN?

Czy to możliwe, że coś w mojej konfiguracji szkodzi wydajności? Czy też rzeczywistość jest taka, że ​​CDN będzie dodatnią wartością netto tylko dla treści, które są obecnie dostępne średnio co kilka sekund?

(wysłano z forum AWS, ponieważ zepsuły mnie na zawsze czasy realizacji SO)

AKTUALIZACJA:

Poniżej znajdują się dwie dobre odpowiedzi, na które warto zwrócić uwagę, jeśli masz pytania dotyczące wydajności CloudFront. Niedawno znalazłem jedno wyjaśnienie mojego konkretnego problemu, o którym nie wspomniano. Opuściłem TTL po 5 minutach jako nadzór. Ponieważ używam również niestandardowego źródła, istnieje dodatkowa podróż w obie strony do autorytatywnego serwera nazw, aby rozwiązać ten problem w rzeczywistej domenie Amazon CloudFront. Teraz, gdy ustawienie TTL powróciło do 12 godzin, wydaje się, że długie ładunki zdarzają się rzadziej.


Tak, możliwe, że CloudFront działa wolniej niż tylko przejście bezpośrednio na szybki serwer, ponieważ CloudFront jest jedną z najwolniejszych sieci CDN ze względu na sposób, w jaki Amazon wdrożył go z wieloma warstwami rozdzielczości DNS itp. Uruchom niektóre testy porównawcze z poziomu differnet lokalizacje na całym świecie i zdecyduj, czy jest to dobre dla Ciebie, czy nie - użyj webpagetest.org do testowania.
Jesper M

Odpowiedzi:


5

Cloudfront ustawia nagłówek w odpowiedziach takich jak „X-Cache: Hit from cloudfront” w odpowiedziach. Prawdopodobnie powie „Miss”, jeśli twój plik nie znajdował się w pamięci podręcznej węzła, do którego zostałeś przekierowany.

Możliwe, że Twoje pliki nie są wystarczająco popularne, więc są usuwane z pamięci podręcznej CloudFront przez bardziej popularne treści, mimo że nie upłynęły 24 godziny. Możliwe jest również, że przeciążenie we / wy lub inna okoliczność wewnątrz określonego węzła CloudFront powoduje, że dostęp jest wolny. Cloudfront jest bardzo tani w porównaniu z Akamai lub LimeLight. Najgorsza wydajność i gwarantowany poziom usług to dwa powody, dla których warto korzystać z droższych odtwarzaczy.

Zrobiłbym test, umieszczając tylko jeden popularny plik w środowisku produkcyjnym w chmurze, a następnie korzystałem z okresowych testów, aby sprawdzić, czy CloudFront wskazuje trafienia (również rejestruje całkowity czas transakcji).


Zaktualizowałem pytanie innym potencjalnym wyjaśnieniem problemu perf, który widziałem, a mianowicie pozostawiłem ustawienie TTL na niskim poziomie 5 minut, ale po przejściu z powrotem na 12 godzin nie sądzę, że je widzę sporadyczne problemy z perf jak najczęściej.
Greg

7

To jest możliwe. Jednak jednym z celów CDN jest skalowalność. Możesz oczekiwać, że CDN będzie działać tak samo, jeśli rzucisz 100 wizyt naraz lub 1 milion wizyt naraz.

Jeśli chodzi o twoją konfigurację, nic nie mogę wiedzieć o podanych przez ciebie informacjach, ale myślę, że powyższy punkt sprawia, że ​​CDN jest tak cenny. Jeśli tworzysz witrynę, która nie generuje dużego ruchu, lepiej byłoby bez CDN. Jednak CDN zapewni mniejsze obciążenie na twoim serwerze internetowym, jeśli uzyskasz duży ruch, ponieważ przekazujesz obsługę swoich multimediów na inny serwer. I na koniec, dobry CDN (a Amazon's) będzie korzystał z ich rozległej sieci, aby udostępniać twoje treści z lokalizacji najbliżej requestera. W wielu przypadkach mogą wyświetlać treści od dostawcy usług internetowych żądającego, co oznacza BARDZO szybki czas ładowania.

Mam nadzieję, że to pomaga.


Dzięki Jesse - bardzo pomocny. Punkt dotyczący skalowania jest dobrze przyjęty. I mamy wystarczający ruch, aby zrobić dużą różnicę. Jednak nadal chciałbym poznać zasady buforowania. Znalazłem ogromną ilość informacji o tym, jak skonfigurować CDN, a bardzo niewiele o jego cechach. Zastanawiam się na przykład, czy powinienem wykluczyć (z CDN) stare treści, do których dostęp jest bardzo rzadki.
Greg

Greg - Nie widzę argumentu za wykluczeniem treści, chyba że z powodów finansowych. Możesz jednak kontrolować nagłówki pamięci podręcznej swojego obiektu w Amazon. Możesz spróbować przyjrzeć się temu: stackoverflow.com/questions/269840/…
Jesse Bunch

To pozwoli ci określić nagłówki wygasające w przyszłości, tak jak w przypadku zwykłych mediów na stronie.
Jesse Bunch

Dzięki jeszcze raz. Ten link kontrolujący pamięć podręczną nie ma związku z moją sytuacją, ponieważ używam niestandardowego serwera źródłowego, a nie s3. Ale zasada ma zastosowanie i mam daleką przyszłość wygasła zestaw nagłówków. BTW, doktorzy Amazon twierdzą, że zawartość żyje w pamięci podręcznej przez 24 godziny, ale moje eksperymenty wskazują coś innego.
Greg

1

Czy źle zrozumiałem? Czy kontrola pamięci podręcznej nie zarządza, jak długo rzeczy żyją w lokalizacjach brzegowych, zanim lokalizacje brzegowe przeładują je z S3? Czy na pewno mają one znaczenie dla Twojej sytuacji, niezależnie od tego, czy używasz S3, czy własnego pochodzenia? Nie?

Amazon FAQ mówi: „Q. Jak długo będzie Amazon CloudFront zachować swoje pliki w miejscach brzegowych Domyślnie, jeśli nie ma nagłówka kontrola cache jest ustawiony, każda krawędź sprawdza lokalizacja dla zaktualizowanej wersji pliku, gdy tylko otrzyma wniosek więcej niż 24 godziny po poprzednim sprawdził źródło pod kątem zmian w tym pliku. Nazywa się to „okresem ważności”. Możesz ustawić ten okres ważności na 1 godzinę lub tak długo, jak chcesz, ustawiając nagłówki kontroli pamięci podręcznej na plikach w twoim źródle. Amazon CloudFront używa tych nagłówków kontroli pamięci podręcznej, aby określić, jak często musi sprawdzać pochodzenia zaktualizowanej wersji tego pliku. Jeśli pliki nie zmieniają się zbyt często, najlepiej jest ustawić długi okres ważności i wdrożyć system kontroli wersji w celu zarządzania aktualizacjami plików ”.

[Zakładam, że ostatnie zdanie oznacza „pech, jeśli ustawisz na 50 lat, a następnie zechcesz zmienić plik”.]

Czy głównym celem korzystania z sieci CDN nie jest umieszczanie zawartości statycznej? Jeśli tak, czy pomogłoby to w użyciu znacznie dłuższego czasu TTL niż jeden dzień? Dla praktycznie wszystkiego (wszystkich obrazów i CSS) używam Cache-Control = "max-age = 604800, public, must-revalidate" (tj. 1 tydzień). Z mojego doświadczenia wynika, że ​​zmiana plików z pewnością zajmuje nawet tydzień, jeśli załaduję nowe wersje do S3.

Mam nadzieję że to pomoże. [BTW: Jeśli chodzi o bardziej ogólną kwestię, ja też zastanawiam się, czy CDN pomaga wydajności tak bardzo, jak myślisz. Mam zamiar przenieść całą moją witrynę (w tym CDN) na superszybki serwer dedykowany i zrobić kilka testów, aby się dowiedzieć.]


Masz rację, że kontrola pamięci podręcznej wpływa na to, jak długo zawartość jest przechowywana na krawędzi. TTL to jednak osobna sprawa. TTL kontroluje buforowanie adresu IP przypisanego do nazwy domeny. Niezależnie od tego, czy plik statyczny jest buforowany na brzegu, czy nie, serwer po raz pierwszy widzi adres URL pliku, musi znaleźć adres IP tej domeny. Przy 1-dniowym TTL prawdopodobne jest, że pobliski serwer ma te informacje w swojej pamięci podręcznej DNS. O 5 minut TTL jest to o wiele mniej prawdopodobne, a wymagana jest pełna w obie strony do mojego serwera pochodzenia (nie do pliku, ale aby rozwiązać URL) ..
Greg

Ach, dziękuję. Myliłem DNS TTL i kontrolę pamięci podręcznej :)
Chris W

1

Powody korzystania z CDN są, jeśli oczekujesz

  • Treść statyczna - rzadkie lub kontrolowane aktualizacje
  • Oglądany na całym świecie
  • Dostęp często

Dostęp do naszej strony internetowej jest rzadki, ale twoja usługa monitorowania monitoruje naszą witrynę na całym świecie. Dzięki temu utrzymuje pamięć podręczną CDN w cieple. Chciałbym również podzielić się naszą sprawą, która jest prosta i pokazuje możliwości CDN.

Co więcej, oczekujemy miesięcznej opłaty w wysokości 2,2 $ w porównaniu do 7 $ za serwer GoDaddy (który nie radzi sobie z skokami)

Średni czas ładowania strony

Średni rozkład czasu ładowania strony

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.