Oceń ten artykuł :
5/5 | 1 opinia
Ten artykuł był dla Ciebie przydatny ?
Tak
Nie
Vous avez noté 0 étoile(s)
Sommaire
Procédure
WordPress, najpopularniejszy CMS, bardzo często narażony jest na problemy z wydajnością. CMS ten nie udostępnia jednak natywnego narzędzia do analizy wąskich gardeł powodujących spowolnienia, co nie ułatwia analizy.
Query Monitor to darmowa wtyczka do WordPressa, która zapewnia niezbędne narzędzia do profilowania podczas wykonywania każdej strony generowanej przez WordPressa, aby zidentyfikować punkty, które należy sprawdzić w przypadku problemów z szybkością i wydajnością.
Podczas gdy zwykła metoda polega na próbach i błędach poprzez dezaktywację każdej wtyczki, aż problem zniknie, Query Monitor przyjmuje nowe podejście, natychmiast identyfikując wtyczkę i / lub motyw powodujący powolne żądanie SQL lub HTTP.
W tym przewodniku dowiesz się wszystkiego, co musisz wiedzieć, aby zidentyfikować problemy z wydajnością za pomocą Query Monitor.
Aby zainstalować Query Monitor, przejdź do pulpitu nawigacyjnego witryny WordPress i przejdź do Rozszerzenia, a następnie Dodaj.

Wyszukaj wtyczkę Query Monitor i zainstaluj ją.

Po zainstalowaniu aktywuj rozszerzenie.

Gdy tylko wtyczka będzie aktywna, na pasku menu WordPress pojawi się nowe menu. Kliknięcie menu spowoduje wyświetlenie okna debugowania:

Następnie należy przejść do strony, na której występują problemy z wydajnością i kliknąć menu, aby zobaczyć szczegóły.
Nie zapomnij dezaktywować wtyczki Query Monitor zaraz po zakończeniu debugowania, ponieważ generowanie danych debugowania jest dość uciążliwe i może prowadzić do problemów z wydajnością.
Menu przeglądu Query Monitor pokazuje aktualnie otwarty adres URL.
Czas generowania strony to czas, w którym PHP wykonuje skrypt. Limit wspomniany poniżej to max_execution_time zdefiniowany dla PHP. Ogólnie rzecz biorąc, czas generowania strony powinien być w przybliżeniu taki sam jak czas oczekiwania przeglądarki (widoczny z konsoli programisty):

W tym przykładzie widać, że występuje problem: czas generowania strony wynosi tylko 377 ms, ale przeglądarka potrzebuje aż 959 ms, zanim będzie mogła odebrać stronę. Problem ten występuje, gdy sieć między przeglądarką a serwerem strony jest wolna. W takim przypadku konieczne będzie skonfigurowanie serwera bliżej klienta za pomocą Ipxchange lub Cloudflare.
Sekcja"Szczytowe użycie pamięci" wskazuje maksymalne zużycie pamięci witryny podczas generowania strony. Limit WordPress jest definiowany przez stałą WP_MEMORY_LIMIT w wp-config.php, podczas gdy limit serwera jest definiowany przez wartość memory_limit ustawioną w interfejsie cPanel.
Kolejna sekcja,"Zapytania do bazy danych", pokazuje czas spędzony na pobieraniu informacji z bazy danych.
Sekcja"HTTP API Calls" pokazuje żądania HTTP wykonane przez witrynę podczas generowania strony w celu uzyskania dostępu do zewnętrznych interfejsów API. Czas odpowiedzi interfejsu API nieuchronnie zależy od serwera, na którym jest on hostowany.
Ostatnie dwie sekcje,"Pamięć podręczna obiektów" i"Pamięć podręczna kodu operacyjnego", wskazują stan wykorzystania tych dwóch pamięci podręcznych. Należy pamiętać, że pamięć podręczna obiektów przechowuje obiekty WordPress w pamięci, aby zmniejszyć liczbę żądań MySQL wykonywanych do bazy danych, a tym samym zoptymalizować czas odpowiedzi, podczas gdy pamięć podręczna Opcode pozwala PHP nie rekompilować pliku PHP za każdym razem. Gdy plik PHP zostanie wykonany po raz pierwszy, pamięć podręczna Opcode przechowuje Opcode pliku PHP (skompilowaną, binarną wersję pliku PHP) do przyszłego wykonania.

Jeśli chcesz dowiedzieć się więcej o wyzwaniach związanych z buforowaniem obiektów, zalecamy przeczytanie naszej dokumentacji poświęconej konfigurowaniu trwałej pamięci podręcznej obiektów za pomocą Redis.

To menu wyświetla błędy PHP napotkane przez WordPress (niekoniecznie błędy krytyczne i/lub blokujące). Często są one ukryte i trudne do znalezienia bez modyfikacji progów raportowania błędów PHP. Query Monitor pozwala jednak szybko je wyświetlić bez modyfikowania jakiejkolwiek konfiguracji. Kolumna"Component" pokazuje pochodzenie skryptu powodującego błąd, niezależnie od tego, czy pochodzi on z rdzenia WordPressa, motywu czy konkretnej wtyczki. Kolumna"Lokalizacja" pokazuje plik i numer jego linii.
Jeśli napotkasz błędy PHP, nawet jeśli nie są one blokujące, może to mieć wpływ na wydajność. Jeśli masz wiele błędów do zarejestrowania, proces PHP będzie musiał otwierać, zapisywać i zamykać plik dziennika PHP przy każdej nowej wizycie. Jeśli masz przestarzałe rozwiązania, dostosuj progi raportowania błędów PHP tak, aby nie były one uwzględniane w plikach dziennika, aby uniknąć niepotrzebnych zapisów do pliku dziennika PHP, jeśli nie możesz ich poprawnie rozwiązać w danym momencie.
To menu grupuje zapytania SQL wykonywane przez WordPress, a także komponenty stojące za zapytaniami i ich czasy wykonania:

Jeśli zauważysz szczególnie powolne zapytania :
Menu "Wywołania API HTTP", znajdujące się nieco dalej na liście, pozwala wyświetlić żądania API wykonane przez witrynę podczas ładowania strony:

Jeśli zauważysz interfejs API, który reaguje zbyt wolno, zalecamy wyłączenie go poprzez dezaktywację powiązanej wtyczki.
Jeśli jednak czas trwania jest w przybliżeniu zaokrąglony (np. 30,001 s), może to oznaczać, że żądanie API przekracza limit czasu, często z powodu blokady zapory. Jeśli API uzyskuje dostęp do zasobu, który nie znajduje się na standardowym porcie 80 lub 443, nie zapomnij sprawdzić, czy żądanie jest autoryzowane na zaporze serwera cPanel.
Teraz już wiesz, jak korzystać z darmowej wtyczki Query Monitor, aby zidentyfikować źródło problemów ze spowolnieniem witryny WordPress. Zachęcamy do dzielenia się swoimi przemyśleniami i pytaniami w sekcji komentarzy.
Oceń ten artykuł :
5/5 | 1 opinia
Ten artykuł był dla Ciebie przydatny ?
Tak
Nie
1mn czytanie
Jak skonfigurować Cloudflare na stronie hostowanej w cPanel?
3mn czytanie
Jak korzystać z Memcached na stronie cPanel?
4mn czytanie
Używanie Redis jako trwałej pamięci podręcznej obiektów dla WordPress na cPanel
4mn czytanie
Przyspiesz swoją witrynę dzięki Fastest Cache - Cache Varnish