Po pierwsze, nie jest to odpowiedź, lecz podejście diagnostyczne.
Nie jest to bynajmniej wyczerpujące - ani nawet cokolwiek bliskiego, to tylko punkt wyjścia.
Czas na pierwszy bajt
Czas do pierwszego bajtu (TTFB) składa się z wielu elementów:
- Wyszukiwanie DNS: znajdź adres IP domeny (możliwa poprawa: więcej / rozproszone / responsywne serwery DNS)
- Czas połączenia: otwórz gniazdo do serwera, negocjuj połączenie (typowa wartość powinna wynosić około czasu pingowania - zwykle konieczna jest podróż w obie strony - utrzymywanie aktywności powinno pomóc w przypadku kolejnych żądań)
- Oczekiwanie: konieczne jest wstępne przetworzenie przed wysłaniem pierwszego bajtu (to właśnie tam powinno być Twoje ulepszenie - będzie to najbardziej znaczące dla zawartości dynamicznej.
Gdy spojrzysz na wynik ApacheBench, zobaczysz również:
- Przetwarzanie: Jest to suma oczekiwania + całkowity transfer zawartości (jeśli czas przesyłania jest znacznie dłuższy niż oczekiwany do pobrania ilości odebranych danych, następuje dalsze przetwarzanie (po otrzymaniu pierwszego bajtu) (np. Strona jest opróżnianie zawartości, gdy jest dostępna)
Porównania w celu wyeliminowania komponentów
Z nielicznymi wyjątkami, twój problem będzie polegał na przetwarzaniu backendu, co zwykle sprowadza się do zbyt skomplikowanego / nieefektywnego kodu lub źle skonfigurowanego MySQL.
Dobrym sposobem na rozwiązanie tego problemu jest seria porównań, które wyeliminują różne aspekty konfiguracji. Dobre porównanie powinno utrzymywać możliwie stałą wartość, aby pomóc zawęzić problem. Obecnie podałeś następujące porównania:
- Identyczna (sklonowana) witryna działająca na starym serwerze i nowym serwerze:
- Różnica: serwer
- Wynik: stary serwer jest szybki; nowy serwer jest wolny
- Uwagi: Potrzebne jest tutaj określenie ilościowe różnic między tymi serwerami - zarówno pod względem stosu (Nginx itp.), Jak i sprzętu (czy stary serwer jest szybszy, ponieważ jest maszyną o większej mocy?)
- Wniosek: kod może być w stanie szybko działać przy właściwej konfiguracji
- Strona testowa a pełna witryna na nowym serwerze
- Różnica: treść, motywy, wtyczki itp
- Wynik: strona testowa jest szybka, pełna strona działa wolno
- Uwagi: teoretycznie test ten powinien pomóc Ci wyeliminować wiele aspektów konfiguracji - DNS, sieć, a nawet konfigurację nginx / php / mysql - jednak nie jest to całkiem „uczciwe”.
- Wniosek: dodatkowa treść ma znaczący wpływ na wydajność
Idealny test polegałby na skopiowaniu całej witryny, a następnie usunięciu całej zawartości oprócz jednego artykułu i powiązanych komentarzy. Celem tego testu byłoby ostateczne ustalenie, czy problem stanowi duża ilość treści, czy przyczyną są inne aspekty konfiguracji (wtyczki WordPress, motyw itp.). Zasadniczo porównałbyś wydajność identycznych witryn na tym samym (nowym) serwerze - ładowanie tej samej strony (ta sama długość itp.) - jedyną różnicą jest całkowita zawartość witryny (np. Istnieje duża szansa, że niektóre wtyczki nie dobrze skalować ze zwiększoną zawartością).
Nie zmieniając niczego, możesz wykonać kilka innych porównań:
- Testuj z lokalizacji zdalnej w porównaniu z lokalną - pomoże to ustalić, czy przyczyną jest sieć, opóźnienie, dns itp
- Już to (nieco) zrobiłeś i w większości doszedłeś do wniosku, że nie masz problemu z siecią.
- Testuj przez Varnish (tj. Port 80) w porównaniu z nginx bezpośrednio (port 8080) - staraj się nie zmieniać konfiguracji między testami - po prostu użyj właściwego portu. To pokaże ci wpływ lakieru. Ponieważ Varnish jest warstwą buforującą, powinien bardzo szybko obsłużyć wszystkie żądania po pierwszym - zasadniczo powinien ominąć backend i przetwarzanie potrzebne do wygenerowania dynamicznej strony i bardzo szybko udostępnić buforowaną kopię.
- Zrobiłeś to (chociaż nie lokalnie) i wykazałeś, że Lakier ma znaczący pozytywny wpływ na twoją wydajność.
Strojenie backendu
W tym momencie powinieneś znaleźć problem lub stwierdzić, że leży on w twoim backendie. To pozostawia Nginx, PHP lub MySQL.
(Należy tu wspomnieć, że jest ona zawsze pod ręką, aby wiedzieć, czy wąskim gardłem jest procesor, RAM, lub I / O - między sar, top, iostat, vmstat, free., Etc powinieneś być w stanie dojść do jakiegoś wniosku w tej sprawie)
Nginx
Nginx po prostu przyjmuje żądania i albo podaje statyczną zawartość, albo przesuwa żądania do PHP-FPM - zwykle nie ma wiele do optymalizacji z Nginx.
- Ustaw pracowników = # rdzeni procesora
- Włącz utrzymanie aktywności (wartość 10-15 jest dobra)
- Wyłącz niepotrzebne rejestrowanie
- W razie potrzeby zwiększ rozmiary buforów
- Unikaj instrukcji if (w miarę możliwości używaj nazw statycznych zamiast wyrażeń regularnych, eliminuj niepotrzebne rozszerzenia)
Idealnie, twój blog testowy i sklonowany blog mają identyczne konfiguracje, w którym to przypadku skutecznie wyeliminowałeś Nginx jako problem.
Podanie
W przypadku, gdy próbujesz zidentyfikować problem w kodzie (na przykład powolną wtyczkę itp.), Powinieneś zacząć od powolnych logów.
- Włącz powolny dziennik MySQL i powolny dziennik PHP-FPM uruchom swój test porównawczy i zobacz, co będzie wolno.
MySQL
- Zwiększ pamięć podręczną i uruchom mysqltuner.pl, aby uzyskać dobry punkt wyjścia.
PHP
- wyłącz niepotrzebne rozszerzenia,
- wyłącz register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data
- zwiększ limit pamięci
- open_basedir i safe_mode mają znaczący wpływ na wydajność, ale mogą także zapewnić dodatkową warstwę obrony. Testuj z nimi i bez nich, aby ustalić, czy ich wpływ na wydajność jest dopuszczalny.
PHP-FPM
- Dostosuj wartości pm. * - zwiększ je, aby poradzić sobie z dużym obciążeniem
Warto zauważyć, że wyniki htop pokazują php-fpm jako pochłaniające większość procesora - a twój problem wydaje się być bezpośrednio z tym związany.
Buforowanie
Po zoptymalizowaniu każdego prawdopodobnego wąskiego gardła rozpocznij buforowanie.
- Masz już pamięć podręczną opCode (APC) - upewnij się, że działa (zawiera plik testowy) - sprawdź liczbę trafień w pamięci podręcznej i, jeśli to możliwe, umieść pamięć podręczną APC w pamięci zamiast na dysku.
- Skonfiguruj swój kod do buforowania (np. Za pomocą wtyczki do Wordpress, takiej jak W3TC)
- Dzięki nginx możesz ustawić buforowanie FastCGI - ale ponieważ masz Varnish, najlepiej tego uniknąć.
- Skonfiguruj warstwę buforującą, taką jak Lakier (którą już zrobiłeś) - i upewnij się, że działa (np. Użyj lakieru, przeczytaj Osiągnięcie wysokiego Hitrate )
- Dodaj więcej pamięci podręcznej dla komponentów witryny - np. MemCached, jeśli dotyczy
Czasami, biorąc pod uwagę ograniczenia twojej aplikacji i sprzętu, możesz nie być w stanie tak bardzo poprawić wydajności backendu - ale to jest sens buforowania - aby zminimalizować użycie backendu.
Dalsza lektura
if -fdyrektywą, której używasz wlocationkontenerze w konfiguracji nginx. Na podstawie tego, co czytam tutaj wiki.nginx.org/Pitfalls , mam wrażenie, że-frobi nieefektywne wyszukiwanie pliku, co może powodować problem z czasem do pierwszego bajtu, szczególnie jeśli masz katalogi z dużą liczbą akta.