React.Js: Osiągnięcie czasu odpowiedzi serwera 20 ms przy renderowaniu po stronie serwera i buforowaniu

1. Małe tło
2. Wchodzi w reakcję!
3. Zagadnienia !
4. Wchodzi Redis!
5. Ściśnij Więcej!
6. Usuwanie pamięci podręcznej
7. Wnioski

Wszyscy uwielbiamy ReactJs, ponieważ zapewnia on wydajność, modułowość i swobodę wyboru stosu. Ale jest jedna rzecz, która ją wyróżnia. Renderowanie po stronie serwera . Przed Reactem większość frameworków javascript skupiała się na budowaniu aplikacji jednostronicowych i wykonała całkiem niezłą robotę. Ale teraz jest rok 2016, era aplikacji hybrydowych! Aplikacje, które mogą działać poza środowiskiem przeglądarki . React rozpoczął trend, wspierając renderowanie po stronie serwera, co umożliwia nam tworzenie kompleksowych aplikacji javascript.

Małe tło

Obecnie pracuję nad Praktyczna karma Practo , miejsce, w którym lekarze i specjaliści ds. zdrowia piszą artykuły zdrowotne i dzielą się swoją wiedzą. Jeśli nie ma nic innego, każda platforma blogowa musi być dobra w JEDNEJ rzeczy: SEO . Każdy blog z dobrym SEO jest przeznaczony dla większej liczby czytelników niż ktokolwiek inny. I więcej czytelników oznacza więcej SEO!

Aby uzyskać lepszy SEO, musisz zrobić wiele rzeczy dobrze. Ale tutaj porozmawiamy tylko o dwóch najważniejszych, najbardziej podstawowych zasadach dobrego SEO:

• Dokonywanie indeksowania witryny dla botów .
• Zrób to SZYBKO . Jak Millennium Falcon szybko!

Wchodzi w reakcję!

Kiedy pojawił się React, jedną z jego zalet było to, że wspierał renderowanie po stronie serwera (SSR). Aby twoja aplikacja wspierała SSR, wszystko czego potrzebujesz to serwer węzłów i API . Nowoczesna architektura wygląda mniej więcej tak:

Ogłoszenie ! Serwer węzłów działa jako osoba pośrednicząca między użytkownikiem a serwerem API. Przepływ przebiega w ten sposób:

• Użytkownik trafia na adres URL, Żądanie przechodzi na serwer Node .
• Serwer Node wysyła żądanie do serwera API i pobiera dane z serwera API .
• Przesyła dane do aplikacji , która w zamian tworzy ostateczny kod HTML dla użytkownika.
• Zwraca ciąg HTML z powrotem do użytkownika.

Teraz cała konfiguracja została zakończona! Serwer przyjmuje żądania, API udziela odpowiedzi i ostatecznie użytkownicy / boty otrzymują w pełni renderowaną stronę HTML. Ale może to okazać się koszmarem dla użytkownika .

Zagadnienia !

• Co jeśli serwer API jest wolny ! Jak czas reakcji 500ms.

Jednym z problemów związanych z renderowaniem po stronie serwera jest to, że czas odpowiedzi zależy w dużym stopniu od czasu odpowiedzi serwera API. Oznacza to, że niezależnie od tego, jak wydajna i szybka jest aplikacja, użytkownik zobaczy biały ekran przez co najmniej 500 ms, pod warunkiem, że serwer węzła ma czas odpowiedzi 0 ms. Co jest praktycznie niemożliwe (na razie).

Zobaczmy więc podział tutaj:

• Czas odpowiedzi 500 ms od API
• 150 ms dla renderowania po stronie serwera (tak, to zajmuje tyle)
• 10 ms dla serwera węzłów
• Opóźnienie sieci 150 ms

Użytkownik otrzyma odpowiedź po prawie 810 ms ! Oczywiście są to tylko liczby średnie, ale w prawdziwym świecie może być dużo gorzej. Ponieważ nie mamy zbyt dużej kontroli nad opóźnieniem sieci, nie będziemy tego robić. Czas odpowiedzi serwera wynosi obecnie 660 ms .

Aby poprawić sytuację, najpierw złapiemy największą rybę: czas odpowiedzi API.

Wchodzi Redis!

Redis to jeden z najmocniejszych magazynów struktury danych, który jest super szybki i wydajny. Możesz tam przechowywać wszystko jako pary kluczowych wartości. Integracja redis do przechowywania środowiska węzła jest bardzo łatwa. Jeśli przechowamy wynik API w redis , możemy zapisać naszą podróż do sieci na serwerze API.

Więc teraz, gdy użytkownik wykona jakąś prośbę, serwer węzłów zapyta Redis, czy już ma odpowiedź. Jeśli tak, przekaże go bezpośrednio do aplikacji w celu renderowania i ostatecznie zwróci ciąg HTML. Jeśli nie ma odpowiedzi, zadzwonimy do API i teraz zapiszemy ten wynik w redis przed przekazaniem go do aplikacji.

Nowy podział będzie:

• 150 ms dla renderowania po stronie serwera
• 5 ms dla serwera redis (UWAGA: Czas renderowania może być mniejszy lub bardzo wysoki, w zależności od rozmiaru aplikacji).
• 10 ms dla serwera węzłów

Po buforowaniu odpowiedzi API spadliśmy z 660 ms do 160 ms .

Ściśnij Więcej!

Chociaż 160 ms jest dobre, możemy uzyskać więcej za pomocą tylko małej sztuczki.

Zamiast przechowywać odpowiedź API w redis, dlaczego nie przechowywać całego łańcucha HTML?

i to był wynik!

Średni czas odpowiedzi spadł do 20 ms !

Usuwanie pamięci podręcznej

Jeśli nie zostanie odpowiednio obsłużony, buforowanie staje się bólem w dupie. Ludzie zaczynają stale zgłaszać starsze dane / błędy stają się powszechne. Tak więc ze świetną pamięcią podręczną potrzebujemy również dobrej strategii eliminacji pamięci podręcznej. Zazwyczaj mamy dwa przypadki, w których musimy wyczyścić pamięć podręczną:

• Kiedy autor aktualizuje artykuł. (Po aktualizacji danych)

Kiedy autor coś aktualizuje, chce natychmiast zauważyć zmiany. W tym celu stworzyliśmy małą pamięć podręczną param = false. Za każdym razem, gdy adres URL zostanie trafiony tym adresem URL, serwer węzła wykonuje wywołanie API zamiast pobierać dane z pamięci podręcznej redis. A zatem pamięć podręczna jest aktualizowana nowszymi danymi.

Po wdrożeniu generowany jest nowy skrót mieszania dla plików js i css. Oznacza to, że jeśli przechowujesz cały łańcuch HTML w pamięci podręcznej, stanie się on nieprawidłowy wraz z wdrożeniem. Dlatego przy każdym wdrożeniu redis db należy całkowicie przepłukać.

Wnioski

Węzeł jest szybki. Tak jest React! Ale czasami musimy dodać nowego gracza, aby osiągnąć ten niemożliwy cel bez poświęcania jakichkolwiek punktów doświadczenia użytkownika. Redis jest niesamowity. Używaj tych wszystkich mądrze.