Refaktoryzacja Wordpress w celu poprawy wydajności pamięci [zamknięte]

Przyjrzałem się uważnie zużyciu pamięci Wordpress. Na mojej stronie wydaje się, że dla każdej trafionej strony przydzielane jest 20 MB pamięci RAM, aby przygotować wygodne środowisko dla wszystkich wtyczek do działania. Zrobiłem to w ten sposób:

Nie ma jednego miejsca do optymalizacji, ani jednego złego faceta, który zjada większość pamięci. Zużycie jest rozłożone na wiele wielu modułów php.

Jak sprawić, by Wordpress zainicjował środowisko w pamięci tylko raz, a następnie używał go wiele razy dla każdego trafienia? Nie chcę, aby powolny PHP zjadał 20 MB przy każdym kliknięciu użytkownika - nawet na serwerze z dużą ilością pamięci, wykonanie całej pracy zajmuje kilka sekund. Zasadniczo potrzebujesz fragmentów pamięci tylko do odczytu, które można ponownie wykorzystać.

Także ... dlaczego 20 MB? Czy ktoś może wgląd w to?

Edycja: Oto dane wyjściowe WinCacheGrind na Wordpress uruchomionym na mojej maszynie programistycznej (znacznie szybsze niż hosting współdzielony). Jak widać, zajmuje więcej czasu, niż samo wygenerowanie kodu HTML strony głównej. Zwolnij to, udostępniając hosting, a masz przepis na kłopoty. Wybrałem metodę, która zajmuje większość czasu. Jak poszedłbyś na optymalizację tego?

Edycja: Oto statystyki zapytań z tego fantastycznego narzędzia do profilowania funkcji.php .

Obciążenie: 12 zapytań - 532 ms - 19,1 MB - 43 trafień w pamięci podręcznej / 53
Zapytanie: 15 zapytań - 563 ms - 19,0 MB - 72 trafień w pamięci podręcznej / 86
Wyświetlanie: 21 zapytań - 705 ms - 19,2 MB - 234 trafień w pamięci podręcznej / 257

Edycja: Czy chcesz zobaczyć coś, co cię przerazi? Wstaw te linie na końcu index.php:

echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

Próbowałem policzyć, ile razy ciało aktualnego postu jest przechowywane w pamięci. Naliczyłem 20 wystąpień. Potem zdałem sobie sprawę, że PHP ma liczenie referencji, więc liczba kopii zredukowana do zaledwie trzech: dwie wydają się być w WP_Query, jedna w pamięci podręcznej obiektów. Badam dalej.

Dlatego myślę, że WordPress potrzebuje refaktoryzacji w celu rozwiązania problemów z pamięcią. Nie można już obwiniać o zużycie pamięci samej złożoności tego, co robi. Po prostu robi to źle .

Edycja: Po dniu prób zrobienia tego, oto moje ustalenia:

1) 88% całej pamięci pochodzi z wywołań typu wymagającego lub dołączającego lub obejmującego:

2) Plik php zawiera się głównie podczas pierwszej części obsługi żądania (co nie jest zaskakujące), czyli tam, gdzie pochłania się całą pamięć:

3) Interesujące jest wykreślenie wszystkich funkcji, które są wykonywane podczas wysyłania żądania. Łącznie jest ponad 12000 połączeń. Drgałem je, aby było bardziej widoczne (oś Pozioma to zasadniczo głębokość stosu):

4) Jedynym sposobem, jaki mogę wymyślić, jest zminimalizowanie liczby zawartych plików .php. Jeśli podzielę funkcje na pliki, z których pochodzą, możesz zobaczyć, że wiele plików zostało trafionych raz lub dwa razy. Potrzebujemy sposobu, aby pominąć te, które nie są potrzebne. Na przykład moja wtyczka do zdalnej kopii zapasowej bazy danych jest ładowana i rejestrowana, tak aby nigdy nie była używana. Oto powyższy wykres podzielony według nazwy pliku:

Oferuję nagrodę wartą całej mojej reputacji :) za refaktoryzacje, które doprowadziłyby do zmniejszenia śladu pamięci moich blogów o 30% lub więcej.

Edycja: Zainstalowałem WP 3.1, oto porównanie ze starą wersją.

Niebieski to WP 3.1, czerwony to 3.0.4. Nowa WP jest szybsza, ale zużywa także więcej pamięci.

Oto lista plików dołączanych.

Pozwoliło mi to uświadomić sobie, ile pamięci zużywa „pakiet All In One SEO” - jedną z możliwości byłoby użycie tylko ułamka funkcjonalności wtyczki, aby uzyskać to, czego chcę. Poza tym moje własne wtyczki wydają się całkiem złe.

Chciałbym spróbować załadowania warunkowego np. Comment.php (nie zezwalam na komentarze na moim blogu) i kilku innych. Usunąłem cały przestarzały kod. Zmniejszyłem plik kses.php, aby ładował tylko jego globalne tabele na żądanie. Uprościłem l10n (nie dokonuję lokalizacji), dzięki czemu jego funkcje od razu zwracają ciągi, bez wyszukiwania. Nadal jestem daleki od 30% oceny, którą sam ustaliłem.

Edycja: Pobrałem i włączyłem APC z ustawieniami domyślnymi (32 MB pamięci podręcznej opcode). Oto porównanie:

Widać, że ładowanie kodu znacznie przyspieszyło, a także zajmuje mniej miejsca w pamięci (prawdopodobnie dlatego, że mamy do czynienia tylko z kodami, a nie oryginalnym źródłem). Zużycie pamięci jest jednak nadal dość wysokie.

Nie warte kłopotów. WordPress nie zjada dużo pamięci tylko dlatego. Zjada dużo pamięci, ponieważ działa pod wieloma funkcjami.

O wiele łatwiej i wydajniej jest buforować wyniki (generowane strony) za pomocą statycznej wtyczki pamięci podręcznej i obsługiwać ją. W ten sposób większość odwiedzających nawet nie trafi w WP.

I dlatego uważam, że WordPress naprawdę potrzebuje przepisania. Nie można już obwiniać o zużycie pamięci samej złożoności tego, co robi. Po prostu robi to źle.

Co za naiwny wniosek. Czytaj Co należy nigdy nie robić, część I .

Dzięki za wykresy wykorzystania pamięci.

Znacznie późniejsza edycja: Autommatic wydało bibliotekę o nazwie prefork, która wydaje się robić to, o co prosisz: ładowanie kodu WordPress do pamięci RAM tylko raz.

Począwszy od WordPress 3.2, PHP 5.2 będzie minimalnym wymaganiem. Myślę, że dzięki naszym paskom fragmenty rdzenia można zacząć restrukturyzować i używać klas z automatycznym ładowaniem. Pozwoliłoby to uniknąć ładowania niektórych fragmentów kodu, o ile nie były one faktycznie potrzebne. Na przykład, jeśli w widoku strony nie było osadzania ani galerii, moglibyśmy uniknąć załadowania dużej części kodu multimediów.

Jednak nawet jeśli zdecydują się pójść tą drogą, oczekiwałbym, że będzie to powolna ewolucja (podobnie jak wiele innych ukrytych zmian, które miały miejsce). Wymagałoby to przetasowania wokół lokalizacji wielu plików i kodu, co może spowodować uszkodzenie kompatybilności wstecznej dla niektórych wtyczek.

Część problemu (jeśli można to tak naprawdę nazwać) polega na tym, że bez tego rodzaju ładowania warunkowego, podstawowa struktura nie może z góry wiedzieć, jakiej funkcjonalności będzie potrzebować, czy nie, aby wygenerować widok zawartości. Wiele funkcji musi zostać załadowanych na wypadek , gdyby były potrzebne.

Jak sprawić, by Wordpress zainicjował środowisko w pamięci tylko raz, a następnie używał go wiele razy dla każdego trafienia?

Nazywa się to buforowaniem opcode.

http://en.wikipedia.org/wiki/PHP_accelerator

prawdopodobnie nie uda ci się tak bardzo ograniczyć użycia pamięci RAM. Ale jeśli używasz mod_php, możesz mod_fcgidzamiast tego przejść na .

podczas gdy mod_php jest nieco wolniejszy, ładuje php, nawet gdy nie jest to konieczne, takie jak wyświetlanie obrazów, plików statycznych, a nawet buforowanie. Jeśli masz dużo próśb, to dużo pamięci RAM.

użycie fcgid znacznie to zmniejszy.

także użycie statycznej pamięci podręcznej (takiej jak w3total cache) pozwoli w ogóle uniknąć wywoływania php, co jest naprawdę wielką zaletą: mniejsze zużycie pamięci RAM, mniej połączeń db.

Ha. Pracuję teraz nad aplikacją internetową, która w pełni zamierzam przeciążać danymi i użytkowaniem wykraczającym poza to, co może obsłużyć moje konto hostingu współdzielonego, więc zdecydowałem - choć byłoby to bardzo łatwe do zbudowania w WP - spróbować pracy z BackPress jako ramy i buduj tylko to, czego potrzebowałem dla moich konkretnych przypadków użycia.

Więc byłem w stanie zredukować moje podstawowe środowisko z setek plików PHP w WP do zaledwie dwudziestu, których tak naprawdę potrzebuję, a jednocześnie nadal jestem w stanie wykorzystać wszystkie db, HTTP, zarządzanie użytkownikami, formatowanie i cron funkcje, które kocham w WordPress.

Problem polega na tym, że to dużo pracy i nigdy nie zaufałbym mojej hackjobowi do niczego poza własnym użytkiem. Jeśli chcesz korzystać z pełnego środowiska WP, weź go takim, jakim jest. Jest tak dobry, jak to jest, ponieważ setki programistów dostosowuje go przez kilka lat. Jak wszyscy tutaj mówili, znajdziesz się znacznie dalej, znajdując lepszy plan hostingu i badając techniki buforowania, niż prawdopodobnie zhakujesz rdzeń.

Tak, WordPress najpierw ładuje wszystko, a następnie robi to, o co prosimy. Pamiętam gdzieś, że możemy stworzyć wirtualną pulę w pamięci RAM, w której możemy umieścić pliki. Wpadłem na pomysł, aby umieścić cały WordPress w pamięci (<10 MB), a następnie możemy zaoszczędzić dużo I / O, które same powinny dać przyspieszenie. Ale nigdy nie miałem okazji tego spróbować, a ponadto nie jestem zbyt biegły w dążeniu do czegoś takiego. Ale wygląda na to, że warto spróbować.

kilka podstawowych sugestii:

1. w3 całkowita pamięć podręczna wtyczki do buforowania ..
2. zainstaluj i włącz memcache, włącz także z ustawień całkowitej pamięci podręcznej w3 (pamięć podręczna opcodu jest również dobrą opcją, ale nie idzie dobrze z wtyczką całkowitej pamięci podręcznej w3)
3. zminimalizuj zapytania kierujące bezpośrednie linki w plikach motywów.
4. Wyłącz wszystkie dodatkowe nieużywane wtyczki i usuń.
5. optymalizuj bazę danych.

prowadzę dobrze znaną witrynę Wordpress z ogromnym ruchem codziennie .. nie jestem nawet poświęcony, świetnie się dla mnie :)