pl  |  en

Jak wziąć na klatę duży ruch w serwisie…

…i przeżyć, by o tym opowiedzieć

Wyobraź sobie, że opiekujesz się wcale-nie-takim-małym portalem informacyjnym. 4 mln odsłon miesięcznie, cytują Was inne media, regularnie trafiacie na Wykop. Macie grono wiernych czytelników, nowych wciąż przybywa. Codziennie kilka nowych artykułów, gorące dyskusje pod każdym z nich. Rozwijacie się stale ale stabilnie. Przeszliście z VPSa na dedyka; macie zapasy mocy. Twoim zadaniem jest wprowadzanie nowych funkcjonalności, poprawianie błędów. Czas płynie miło i przyjemnie.

Nagle… nieoczekiwane wydarzenie – napięta sytuacja na Ukrainie! Media prześcigają się w podawaniu kolejnych informacji, minuta po minucie relacjonują wydarzenia. Wasi czytelnicy szturmują Wasz serwis! Ruch na portalu skacze kilkukrotnie. Marzenie dla wydawcy? Niekoniecznie… Pierwsze odkrycie: serwis nie jest przygotowany na tak duży ruch. Drugie: serwer dedykowany się nie skaluje. Co robić?

keep calm

Poznaj rozwiązania, które zapewnią Ci pełen spokój, gdy w Twoim serwisie pojawi się duży ruch.

Nie jesteś w stanie od ręki zapewnić sobie większej mocy więc postaraj się zmniejszyć zużycie zasobów. Kilka optymalizacji po stronie oprogramowania pozwoli Ci obsłużyć dużo większy ruch.

Po pierwsze baza danych

Często wąskim gardłem jest baza. Wierzę, że na etapie pisania aplikacji używasz narzędzi, które pokazują działania na bazie (używasz, prawda?), zawsze coś jednak może umknąć lub stać się problemem przy dużej liczbie wierszy. Slowlog Twoim przyjacielem! Szukaj długo wykonujących się zapytań oraz zapytań, które generują duże tabele tymczasowe. Jeżeli sam administrujesz serwerem być może będziesz musiał najpierw włączyć logowanie takich zapytań. W Postgresie odpowiadają za to ustawienia

log_temp_files = 0 (loguj wszystkie tabele tymczasowe)
log_min_duration_statement = 2000 (loguj zapytania dłuższe niż 2s)

w MySQLu

slow_query_log = 1
slow_query_log_file = /ścieżka/do/slow.log
log-queries-not-using-indexes

(Dla korzystających z MySQLa: Percona i MariaDB logują więcej użytecznych informacji do slow.loga niż waniliowy MySQL).

Znalezione zapytania przeanalizuj, w miarę możliwości pozakładaj indeksy (potrafią działać cuda).

Jeżeli korzystasz z naszych usług zwróć się do nas – udostępnimy Ci logi, pomożemy znaleźć problematyczne zapytania, założymy indeksy lub doradzimy jak przebudować zapytanie.

Co jednak w sytuacji, gdy nie da się wskazać konkretnych zapytań a baza nie wyrabia po prostu przez nadmierny ruch? Z pomocą przyjdzie Ci Memcached. To prosty serwer trzymający w pamięci dane w formacie klucz=wartość. Robi robotę! Użyj go do cache’owania odpowiedzi od bazy. Jeżeli serwis oparty jest na gotowym frameworku jest duża szansa, że wsparcie dla Memcached jest w standardzie – trzeba go tylko uruchomić i podpiąć w aplikacji. U nas uruchamia się go tak

memcached

Jeżeli sam administrujesz serwerem, zainstalujesz Memcached z repo Twojej dystrybucji. Podpięcie do aplikacji zależy już od konkretnego frameworka. Jest proste w Railsach i Django (w tym drugim przypadku wymaga zewnętrzego modułu Johnny Cache). Podejrzewam, że w innych frameworkach też nie będzie trudne.

Cache’owanie odpowiedzi od bazy siłą rzeczy dotyczy SELECTów, czasem problemem są niepozorne UPDATE’y. Wiesz jak działa aktualizacja wiersza w Postgresie? Aktualizowany rekord jest przepisywany do nowej krotki, stara oznaczana jest jako niewidoczna i czeka sobie na rzeczywiste usunięcie. Jeżeli w tabeli z artykułami trzymasz również licznik odwiedzin każdego z nich, każde podbicie licznika przepisuje cały wiersz. Wyobraź sobie jaką to robi masakrę na dyskach przy dużym ruchu. Liczniki trzymaj w osobnej tabeli i połącz kluczem obcym z odpowiednim artykułem.

Po drugie pliki statyczne

Czego jeszcze nie robić? Nie trzymaj plików w bazie. Albo inaczej: nie serwuj plików statycznych z bazy. Nie serwuj ich też z aplikacji. Od tego jest serwer WWW – zrobi to szybciej i przy zdecydowanie mniejszej utylizacji zasobów. No chyba, że tym serwerem jest Apache 😉 Na naszej platformie z przodu stoi Nginx – samodzielnie serwuje pliki statyczne (i jest w tym świetny!), dynamiczne żądania przekazuje do aplikacji. Polecamy Ci taką konfigurację.

Skoro jesteśmy przy plikach to pamiętaj, że duża liczba plików w jednym katalogu obniża wydajność systemu plików. Czyść regularnie sesje, jeżeli zapisujesz je na dysk (możesz je też trzymać w Memcached). Jeżeli masz w aplikacji cache generowanych stron i trzymasz go na dysku, postaraj się przerzucić go do Memcache’a. Dyski są najsłabszym ogniwem.

Po trzecie Varnish

To wszystko jest przydatne, ale serwis uzyska największą wydajność, jeżeli ruch w ogóle do niego nie trafi. Jak to osiągnąć? Postaw przed nim Varnisha – świetny serwer cache’ujący. Może być schowany za Nginxem lub słuchać na porcie 80 i odbierać cały ruch, cache’ować nie tylko dynamiczne żądania, ale i pliki statyczne. Varnish nie obsługuje https więc do połączeń szyfrowanych potrzebujesz osobnego serwera HTTP.

Nasza platforma hostingowa z pudełka umożliwia uruchomienie Varnisha pomiędzy Nginxem a aplikacją. Możesz do tego wykorzystać proxy konfigurowane w panelu. Nginx wyserwuje pliki statyczne, żądania do aplikacji przekaże na wskazany port na którym powinien zostać uruchomiony Varnish.

proxy

Samo postawienie Varnisha jest proste i szybkie, jednak wykorzystanie jego potężnych możliwości to już bardziej skomplikowana sprawa. Przede wszystkich aplikacja musi być cache’owalna. Żądania z ciastkiem sugerują, że użytkownik odwołuje się do unikalnych treści. Sensowne założenie zderza się z rzeczywistością. Są serwisy, które serwują ciastka zawsze i każdemu – upewnij się, że Twój do nich nie należy. W przypadku, gdy wszystkie cookie wydają się mieć sens zastanów się, czy może jednak nie dałoby się z nich bez szkody zrezygnować.

Przykład: masz na stronie głównej wyszukiwarkę artykułów. Formularz zabezpieczony jest przed atakami cross-site request forgery. Powoduje to ustawienie każdemu odwiedzającemu unikalnego ciastka csrftoken. Jednakże wyszukiwarka nie jest wrażliwa pod względem bezpieczeństwa, zabezpieczenie CSRF można dla niej wyłączyć.

Jeżeli użytkownik wejdzie na stronę, która już zdecydowanie powinna być zabezpieczona przed atakami CSRF (np. formularz logowania), znów dostanie odpowiednie ciastko i cache mu nie pomoże (nawet jeżeli się nie zaloguje). Dlatego można pomyśleć nad wyniesieniem wszystkich formularzy do osobnej subdomeny (wyłączenie cache’owania dla zalogowanych użytkowników można zrealizować w obrębie jednej domeny).

Dobra, tylko jak w ogóle ustalić na której warstwie jest problem wydajnościowy?

Nie ma na to jednej odpowiedzi. Logi, narzędzia systemowe, znajomość systemu i własnej aplikacji, wiedza i doświadczenie… Ratowanie serwisu zacznij od postawienia Varnisha – da Ci trochę czasu. Później możesz wprowadzać kolejne ulepszenia.

A najlepiej to już teraz przenieś się do nas! :) Oprócz pomocy w optymalizacji serwisu możemy zaoferować Ci skalowalne serwery z możliwością zwiększenia od ręki zasobów do 64GB pamięci i 16CPU nawet na krótki czas. Zazwyczaj to jest najszybsze rozwiązanie problemów wydajnościowych.

Autor: Magda Zarych

  • magdazarych

    Przydatne informacje przy diagnozowaniu problemów wydajnościowych otrzymacie korzystając z Appenlight (dawniej Errormator) https://appenlight.com/ Tam znajdziecie na przykład wolno wykonujące się zapytania SQL. Wystarczy do aplikacji podpiąć klienta, który przy każdym żądaniu HTTP obsługiwanym przez aplikację, będzie wysyłał do serwera informacje i statystyki z tego żądania. Przez webowy panel będziecie mieć dostęp do tych informacji, możliwość podejrzenia zapytań do bazy w kontekście requestu, listę wolno wykonujących się żądań ze wskazaniem, które części żądania ile trwają itp.

    Dodatkowe informacje we wcześniejszych wpisach na naszym blogu
    http://www.megiteam.pl/blog/case-study/monitoring-appenlight/
    http://www.megiteam.pl/blog/wywiady/polacy-nie-gesi-czyli-o-monitoringu-aplikacji-made/

    Polecamy Appenlight naszym klientom ze względu na m.in. prostotę instalacji. Przy rejestracji u nas, w mailu powitalnym otrzymacie kod na 3 miesiące darmowego korzystania z tego rozwiązania.