Spędziłem trochę czasu dostrajając swoją aplikację na heroku i pracowałem nad dostrajaniem wydajności aplikacji Railsowych w różnych ustawieniach.
Kiedy uruchamiam ab -n 300 -c 75 ...myapp.com.... # który jest kopią zapasową mojej głównej strony i jest na bezpłatnym planie cedrowym z jednorożcem
Requests per second: 132.11 [#/sec] (mean)
Time per request: 567.707 [ms] (mean)
Time per request: 7.569 [ms] (mean, across all concurrent requests)
(to jest w stosunku do strony głównej, która nie robi niczego intensywnego, więc podaję to tylko jako przykład „jak szybko heroku może być na bezpłatnym abonamencie z bardzo prostą stroną?”, a nie „twoje aplikacje powinny być tak szybko")
Oto moja lista kontrolna Rails Performance Tuning 101:
-
Najpierw zmierz czas wczytywania przeglądarki/strony (przeglądarka wysyła wiele żądań, ab mówi tylko o jednym z nich, a zwykle żądanie strony głównej nie stanowi problemu), uzyskaj wartości bazowe ładowania strony z narzędzi takich jak www.webpagetest.org lub www.gtmetrix.com w przypadku stron dostępnych publicznie lub narzędzi przeglądarki Yslow, szybkości strony google lub dynatrace w przypadku stron prywatnych. Jeśli spojrzysz na diagram kaskadowy ładowania strony (panel „Sieć” w chrome/firefox), zwykle pokazuje, że Twój html ładuje się szybko (poniżej sekundy), ale wszystko inne trwa 1-3 sekundy, aby się wczytać. Postępuj zgodnie z zaleceniami Yslow/prędkości strony, aby poprawić (upewnij się, że używasz potoku zasobów Rails 3.1 w pełnym zakresie)
-
Przeczytaj swoje pliki dziennika/nową relikwię, aby znaleźć najlepsze miejsce żądania „najwolniejszego/najczęściej trafiającego” i sprofiluj, co się dzieje z tym żądaniem (czy jest to powolny rubin/duże użycie pamięci, czy dużo zapytań?). mieć niezawodny sposób na wykrywanie i monitorowanie problemów z wydajnością, a nie tylko losowe zmiany. Po zidentyfikowaniu niektórych obszarów docelowych utwórz skrypty testowe, które pomogą przed/po testowaniu i udowodnij, że Twoja zmiana pomaga, oraz wykryj, czy wkrada się regresja.
-
Brak indeksów w kolumnach bazy danych jest jednym z najczęstszych problemów i najłatwiejszym do rozwiązania. Uruchom wyjaśnianie zapytań docelowych lub przejrzyj dziennik powolnych zapytań, aby zobaczyć, co robi planer zapytań. Dodaj odpowiednio indeksy kluczy obcych, kolumn wyszukiwania lub danych podstawowych (indeks pokrywający). Przetestuj ponownie z rzeczywistymi danymi produkcyjnymi, aby udowodnić, że ma to znaczenie. (możesz uruchomić wyjaśnienie w heroku, a także uruchomić zapytania o brakujące lub nieużywane indeksy)
-
Większość słabo działających aplikacji Rails cierpi z powodu zapytań N+1, ponieważ tak łatwo jest napisać order.owner.address.city i nie myśleć o tym, co się dzieje, gdy jest to pętla. Zapytania N+1 niekoniecznie są powolnymi zapytaniami, więc nie pojawiają się w wolnym dzienniku zapytań, po prostu jest ich wiele i bardziej wydajne jest wykonywanie wszystkich naraz. Użyj :include lub .includes() do szybkiego ładowania tych danych lub spójrz na wykonanie zapytania w inny sposób.
-
Przeanalizuj przepływ swojej aplikacji i poszukaj możliwości buforowania. Jeśli użytkownik przeskakuje tam iz powrotem między stroną indeksu a stroną szczegółów i z powrotem, być może widok szczegółów ajax, bez opuszczania strony indeksu, dostarczyłby mu potrzebnych danych w szybszy sposób. Napisałem więcej przemyśleń na ten temat na moim blogu
Przedstawiłem te techniki i inne pomysły w Chicago na tegorocznej konferencji WindyCityRails. Możesz obejrzeć film tutaj na moim www.RailsPerformance blog .com To, co kocham w heroku, to to, że od samego początku musisz być skalowalny. Kiedy spojrzysz na dyskusje na liście mailingowej, zobaczysz, że większość ludzi jest świadoma najlepszych praktyk dotyczących wydajności i tego, jak najlepiej wykorzystać serwer. Podoba mi się również to, że jeśli chcesz pozostać tani, uczysz się sztuczek dostrajania wydajności, które przyniosą Ci największy efekt.
Powodzenia!
