Co wszystko przyczynia się do czasu wykonania strony Drupal?

Mam witrynę, którą badam, która ma poważne problemy z wydajnością, dzięki memcache udało mi się zmniejszyć liczbę zapytań zarówno pod względem liczby, jak i całkowitego czasu oczekiwania (od 3 sekund do 230 ms), ale czas wykonania strony mi umyka (jestem patrząc na wartości wyprowadzane przez devel) rozumiem, że czas wykonania strony = czas potrzebny na wykonanie php, dlatego zainstalowałem APC i widzę buforowanie kodu operacyjnego php i statystyki pokazujące trafienia w panelu sterowania APC (apc.php dostarczany z APC), ale mój czas wykonania strony nie spada. Myślę więc, że moje pytanie jest dwojakie:

• Co wszystko przyczynia się (lepiej spowalnia) czas wykonywania strony? Czy to tylko czas potrzebny na wykonanie php?
• Jakie podejścia powinienem zastosować, aby skrócić czas wykonywania strony. Próbowałem APC, ale niewiele pomocy

Liczba modułów PS użytych na tej stronie jest po prostu ogromna (168), ale w tej chwili nie jestem w stanie wydać tego zalecenia, bardziej przypomina to pożar w dziurze.

Edycja: Dane wyjściowe uruchamiania xhprof na lokalnej instancji (zalecane przez mikeytown), wydaje się to szalone. Myślę, że późniejsze wyniki są spowodowane thrashowaniem? Uruchamianie różnic dla tego samego adresu URL ma drastyczną różnicę i zbyt duże zużycie zasobów. Nie jestem również pewien, dlaczego pokazuje wartości, które nie pochodzą z dzisiaj: | (Właśnie zainstalowałem xhprof na tym laptopie)

Uzyskaj cachegrind swojej witryny. xdebug lub xhprof mogą go wygenerować. Dzięki temu dowiesz się, jakie funkcje trwają najdłużej. Dopóki tego nie zrobisz, jest to gra polegająca na zgadywaniu.

EDYCJA: Źle odczytałem oryginalny post. 168 modułów to dużo, a od 300 do 700 ms zapytań SQL jest ogromne . Im więcej modułów użyjesz, tym więcej zapytań znajdą się, gdy tylko moduły zrobią.

Używaj agresywnego buforowania, póki możesz, buforuj wszystko, jeśli to nie wystarczy, spróbuj odwrócić bufor proxy. Używanie CDN do plików może znacznie poprawić całość. Odwrotna pamięć podręczna proxy może również pomóc, usuwając niektóre uwierzytelniające pliki cookie podczas odwiedzania stron, które jej nie potrzebują (wówczas rdzeń będzie uważał, że użytkownik jest anonimowy dla tych danych i zmaksymalizuje buforowanie).

Dynamika rdzenia Drupala spowalnia cały świt, gdy tylko zbyt wiele modułów oddziałuje jednocześnie.

Powiedziałbym na przykład, że jeśli użyjesz wielu modułów, które ładują dane w czasie hook_node_load () zamiast używać pól, spowoduje to wiele zapytań, podczas gdy użycie pola zapewniłoby wydajność buforowania.

Renderowanie może również zająć dużo czasu, drupal_render () (kiedyś wywoływany interfejs API renderowania) to niezły kawałek API (naprawdę przydatny), ale także trochę powolny. Przejście na PDO (D7) i pełne DBTNG (co jest świetne, nawiasem mówiąc) również dodaje niezauważalne opóźnienie.

To powiedziawszy, rdzeń sam w sobie jest dość szybki (ale wykonuje zbyt wiele zapytań SQL, nawet przy prawie niczego nie zainstalowanym), źle zakodowane moduły często stanowią wąskie gardło.

APC może podzielić czas wykonania na 2 lub 3, w zależności od uruchomionego kodu. jeśli dobrze go skonfigurujesz (włączysz wszystkie optymalizacje APC, oficjalna instrukcja APC jest dobrze napisana i poprowadzi cię).

Jeśli używasz wolnego systemu plików (sieciowego systemu plików lub wolnego dysku twardego), może to oznaczać widoczny wpływ na czas wykonywania. Drupal składa się z wielu małych plików, co zmusza PHP do wykonywania operacji wejścia / wyjścia na FS za każdym razem, gdy ładuje jeden z nich (APC również bardzo w tym pomaga).

Błędnie skonfigurowany DBMS może być również brzydkim wąskim gardłem, jeśli używasz MySQL, pomyśl o dostrajaniu. Jeśli korzystasz z hostingu współdzielonego, jeśli nie jest on specyficzny dla Drupala (lub gotowy), DBMS i stos PHP prawdopodobnie będą źle skonfigurowane lub nie dostrojone, co może prowadzić do naprawdę wolnych stron.

Nie zapomnij aktywować wszystkich pamięci podręcznych. Jeśli Twoja witryna nie jest uwierzytelniona zorientowana na użytkownika, aktywuj agresywne buforowanie strony (to naprawdę niesamowite).

Im więcej będziesz mieć bloków, tym więcej pełnych stron będzie powolnych, bloki modułów Widoku będą wąskim gardłem (w zależności od używanych wtyczek Widoku blok OG może być prawdziwym bólem), jeśli nie ograniczysz ich widoczności na stronie lub z niestandardowym kodem PHP (każdy inny blok również zawsze ustawia widoczność bloku ręcznie, bardzo pomaga ramie, unikając próby renderowania pustych bloków).

Unikaj modułów korzystających z hook_init (), hook_init () jest uruchamiany na każdej stronie, nawet jeśli dostajesz 403 lub 404, co spowalnia wszystko (nawet spowalnia czas generowania obrazu w stylu imagecache i błędy 404 na plikach byłyby świt powoli, aby powiedzieć, że plik nie istnieje).