Rails Performance Tuning do produkcji?

Spędziłem trochę czasu na strojeniu mojej aplikacji na heroku i spędziłem trochę czasu pracując nad strojeniem wydajności aplikacji Rails w różnych ustawieniach.

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 przeciwko stronie głównej, która nie robi nic intensywnego, więc podaję to tylko jako "jak szybko heroku może być na bezpłatnym planie z bardzo prostą stroną?"przykład, a nie" twoje aplikacje powinny be this fast")

Oto moja lista kontrolna Rails Performance Tuning 101:

1. Najpierw Zmierz czas ładowania przeglądarki/strony (przeglądarka wysyła wiele żądań, ab informuje Cię tylko o jednym z nich, a zazwyczaj żądanie strony głównej nie jest problemem), uzyskaj numery linii bazowych ładowania strony z narzędzi takich jak www.webpagetest.org lub www.gtmetrix.com[13]} dla stron publicznych, lub narzędzia przeglądarki Yslow, Google page speed, lub dynatrace dla stron prywatnych. Jeśli patrzysz na diagram ładowania strony (panel 'Net' w chrome/firefox), zwykle pokazuje, że Twój html ładuje się szybko( w ciągu sekundy), ale wszystko inne trwa 1-3 sek. Należy postępować zgodnie z zaleceniami dotyczącymi prędkości Yslow/page, aby dowiedzieć się, jak poprawić (upewnij się, że używasz w pełnym zakresie materiałów potoku zasobów Rails 3.1)

2. Przeczytaj pliki dziennika / nowy relic, aby znaleźć słodki punkt żądania "najwolniejszy/najczęściej trafiony" i profiluj, co się stanie w tym przypadku request (czy to powolne użycie ruby/dużo mem, czy dużo zapytań?) Musisz mieć niezawodny sposób wykrywania i monitorowania problemów z wydajnością, a nie tylko zmieniać rzeczy losowo. Po zidentyfikowaniu niektórych obszarów docelowych Utwórz skrypty testowe, aby pomóc w testowaniu przed/po testowaniu i udowodnić, że Twoja zmiana pomaga, a także wykryć, czy regresja wkrada się.

3. Brak indeksów w kolumnach db jest jednym z najczęstszych i najłatwiejszych do rozwiązania problemów. Uruchom wyjaśnij na zapytaniach docelowych, możesz też przejrzeć dziennik powolnych zapytań, aby zobaczyć, co robi planista zapytań. Dodawanie indeksów dla kluczy obcych, kolumn wyszukiwania lub danych podstawowych (indeks pokrycia), stosownie do potrzeb. Ponownie przetestuj rzeczywiste dane produkcyjne, aby udowodnić, że to robi różnicę. (możesz uruchamiać explain w heroku, a także uruchamiać zapytania o brakujące lub nieużywane indeksy)

4. Większość słabo działających aplikacji Rails cierpi na N + 1 zapytań, ponieważ jest tak łatwa do napisania.właściciel.adres.miasto i nie myśleć o tym, co się dzieje kiedy to będzie w pętli. N + 1 zapytania niekoniecznie są powolne zapytania, więc nie pojawiają się w dzienniku powolnych zapytań, to po prostu, że jest ich wiele, a jego bardziej efektywne, aby zrobić to wszystko na raz. Zastosowanie: include lub .includes() dla chętnego ładowania tych danych, lub spójrz na wykonanie zapytania w inny sposób.

5. Analizuj przepływ aplikacji i Szukaj możliwości buforowania. Jeśli użytkownik odbija się tam iz powrotem między stroną indeksu i stroną szczegółów i z powrotem, być może ajax widok szczegółów, bez opuszczania strony indeksu, dałby im dane, których potrzebują w szybszy sposób. Napisałem kilka więcej myśli na ten temat na moim blogu