Złożyłem witrynę D7 z podtematem Minelli. Po drodze dużo eksperymentowałem z różnymi tematami, różnymi modułami. Gdzieś po drodze opracowałem dziwny problem z wydajnością, a teraz tak naprawdę nie wiem, co to spowodowało theme / module / config.

Problem polega na tym, że kiedy po raz pierwszy odwiedzam witrynę, wyświetlenie pierwszej strony zajmuje około 15 sekund. Następnie mogę poruszać się po witrynie, która jest bardzo responsywna. Jeśli zostawię to na około godzinę, a potem wrócę, pierwsza prośba znów jest bardzo powolna.

Wyczyściłem pamięć podręczną, więc nie powinno to stanowić problemu. Ponadto wyłączyłem motywy i moduły, których nie używam. Przeniosłem witrynę do nowej infrastruktury, ale pojawił się problem!

Gdzie mam teraz iść?

Są trzy rzeczy, które sprawdziłbym.

Po pierwsze, jeśli jesteś na stronie produkcyjnej i nie edytujesz plików PHP, powinieneś upewnić się, że APC jest włączony, ma wystarczającą ilość pamięci i długi TTL (możesz iść z dniem lub nigdy nie wygasać, jeśli chcesz). Możesz także rozważyć ustawienie apc.stat=0. Dokumenty APC zawierają wszystkie informacje potrzebne do ustawienia TTL. Aby wybrać ilość pamięci, powinieneś trzymać plik apc.php gdzieś chroniony i monitorować wykorzystanie pamięci i statystyki rezygnacji. Dostosuj pamięć APC, tak aby wskaźnik braków był bardzo niski. Początkowa spowolnienie może być spowodowane tym, że APC jest pełne i opróżnia się (IIRC, APC zrzuca całą pamięć podręczną, gdy jest pełna, zamiast stosować LRU lub bardziej zaawansowane strategie pamięci podręcznej).

Po drugie, upewnij się, że MySQL jest odpowiednio dostrojony. Możesz użyć mysqltuner do dostosowania rozmiarów buforów. Początkowa spowolnienie może być spowodowane ładowaniem tabel z dysku i / lub brakiem pamięci podręcznej zapytań. Chociaż nie jest idealny, mysqltuner pozwala ci iść we właściwym kierunku.

Po trzecie, upewnij się, że masz prawdziwą strategię cronu Drupal . Osobiście wyłączyłem cron automagic na „admin / config / system / cron” i ustawiłem crontab do uruchamiania co noc. Możesz także wypróbować Elysię Cron, jeśli naprawdę potrzebujesz dokładniejszej kontroli nad rzeczami. W ten sposób możesz uruchamiać niezbędne zadania tak często, jak potrzebujesz, ale normalne uruchamiaj przez noc. Twoja początkowa powolność może wynikać z biegania crona co godzinę. Możesz to potwierdzić, sprawdzając, kiedy cron działa na „admin / raporty / dblog” i próbując dopasować się do twojej powolności.

Ivanhoe123 prawdopodobnie ma rację: Drupal 7 ma domyślnie włączoną opcję „poor mans cron”. Krótko mówiąc, oznacza to, że (raz na jakiś czas) uruchamiany jest cron, zanim Drupal wyświetli stronę, opóźniając wszystko.

Zawsze staraj się używać prawdziwej pracy crona w zakładach produkcyjnych. Aby uzyskać więcej informacji technicznych, zobacz http://drupal.org/cron lub skontaktuj się z firmą hostingową.

Aby go wyłączyć, przejdź do admin / config / system / cron i wybierz „Nigdy”.

Devel rejestrowanie oferty modułów bazy danych, aby sprawdzić, czy masz jakieś długo działających kwerend.

Jeśli to nie pomoże, weź XHProf lub XDebug i znajdź winny kod. XHProf (profiler) rysuje ładną mapę wszystkich funkcji wykonywanych na serwerze i mówi, które z nich zużywają najwięcej czasu wykonania. Z drugiej strony, gdy XDebug (debugger) jest skonfigurowany z IDE, takim jak Eclipse ( patrz wideo ), pozwala na drążenie w dół każdej wykonywanej funkcji NA ŻYWO. Profiler da ci wyobrażenie o tym, co jest wykonywane; podczas gdy debugger pokaże ci, dlaczego jest wykonywany.

Właśnie ze smaku pytania od razu myślę o trzech (3) rzeczach

• Silnik / procesor pamięci MySQL
• Buforowanie bazy danych
• Blokowanie stołu

Silnik pamięci MySQL

Jeśli nie korzystasz z wyszukiwania / indeksowania FULLTEXT, zdecydowanie zalecamy przekonwertowanie wszystkich danych MyISAM na InnoDB. MyISAM nie został zaprojektowany do korzystania z wielu procesorów i wielu rdzeni. InnoDB został znacznie ulepszony pod kątem wykorzystania wielu procesorów, a także hipertekstu odczytu / zapisu.

Oto kilka postów, które napisałem na ten temat w DBA StackExchange i na tej stronie w odniesieniu do strojenia MySQL pod kątem wydajności InnoDB

• Sep 20, 2011: Wiele rdzeni i wydajność MySQL
• Sep 12, 2011: Możliwe, aby MySQL używał więcej niż jednego rdzenia
• Jun 07, 2011: Jak przekonwertować bazę danych z MyISAM na InnoDB?
• May 26, 2011: O wydajności baz danych jednowątkowych i wielowątkowych
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Buforowanie bazy danych

Kolejnym mocnym argumentem przemawiającym za konwersją wszystkich danych MyISAM do InnoDB jest sposób buforowania danych / indeksów przez MySQL. Silnik pamięci masowej MyISAM buforuje tylko indeksy. InnoDB buforuje dane i indeksy . W związku z tym możesz przydzielić wystarczającą ilość pamięci dla puli buforów InnoDB, aby pomieścić jedną z następujących opcji (zależnie od tego, która wartość jest mniejsza)

• Wszystkie dane i indeksy InnoDB (idealne, jeśli masz wystarczająco dużo pamięci RAM dla systemu operacyjnego; eliminuje to kolejne opóźnienia)
• 75% zainstalowanej pamięci RAM (w przypadku, gdy masz więcej danych / indeksów InnoDB niż pamięci RAM; minimalizuje opóźnienia)

Jeśli używasz MySQL 5.1, możesz ustawić innodb_max_dirty_pages_pct = 0. To nieznacznie zwiększy I / O dysku, ale pula buforów InnoDB zostanie wyczyszczona na tyle, aby umożliwić rotację starych danych i stron indeksu bez skoków I / O dysku. Wtyczka MySQL 5.5 i InnoDB MySQL 5.1 nie wymagają tej regulacji, ponieważ ma lepszy domyślny mechanizm opróżniania puli buforów.

Jeśli korzystanie z InnoDB nie wchodzi w rachubę, może być konieczne użycie memcached lub lakieru. Pozwala to programistom na określenie, jak długo buforowane dane będą przechowywane w pamięci RAM serwera. Oczywiście będzie to wymagało ulepszenia programistycznego, aby aplikacja mogła zapamiętać / lakierować.

Blokowanie stołu

• InnoDB wykonuje blokowanie na poziomie wiersza, co pozwala na transakcje i odczyty nieblokujące .
• MyISAM blokuje pełne tabele tylko dla każdego INSERT, UPDATE i DELETE .

Epilog

Nie można uniknąć początkowego opóźnienia po ponownym uruchomieniu MySQL. Jednak po ulepszeniu MySQL przy użyciu wyżej wymienionych sugestii / informacji nie powinieneś już doświadczać kolejnych opóźnień.

Użyłbym narzędzi takich jak YSlow lub Firebug itp., Aby dokładnie określić, co się dzieje, gdy ładujesz tę stronę i kiedy ładujesz tę stronę natychmiast po niej. Sprawdź, czy jest to problem z pamięcią podręczną, a ponadto sprawdź, jak działa, gdy uzyskujesz dostęp do strony jako użytkownik anonimowy, a następnie jako użytkownik uwierzytelniony. Porównaj to z ustawieniami wydajności w Drupal.

Jeśli nie jest to problem z pamięcią podręczną, użyj dziennika zapytań Devel, a także dzienników MySQL, aby zobaczyć, co się dzieje z bazą danych. Ponadto, jeśli masz na serwerze pamięć podręczną lub podobną pamięć podręczną zwiększającą wydajność, spróbuj wyłączyć niektóre numery, a następnie włączyć je ponownie.

Wygląda na to, że cron jest uruchomiony.

Sprawdź swoje ustawienia tutaj: admin / config / system / cron

Z tego powodu prawie rzuciłem Drupala na mój ostatni projekt.

Musi mi być więcej niż jedna przyczyna. Muszę jeszcze znaleźć rozwiązanie „napraw wszystko”, które działa za każdym razem, gdy pojawia się ten problem.

Syslog i Ubuntu / Debain

Pierwszy raz natknąłem się na przerywany 15 sekundowy czas ładowania, kiedy działałem Drupal na (dedykowanych, nieudostępnionych) systemach opartych na Debianie / Ubuntu. Wyłączenie modułu Syslog było dla mnie rozwiązaniem.

Jak powiedział @BetaRide, korzystanie z xDebug lub innego profilera PHP jest niezwykle pouczające.

Nadal problem - obejście

Jeśli chodzi o moje inne instalacje, nadal jestem zagubiony.

Ten problem jest bardziej zauważalny na moim serwerze programistycznym i moich instalacjach Drupal o niskim natężeniu ruchu.

Aby obejść ten problem, skonfigurowałem zadanie CRON, aby ładować stronę główną witryn co 60 sekund, a także skrypt CRON Drupala co 300 sekund. Nie jest to oczywiście optymalne, ale wolałbym raczej oglądać lub skręcać czas ładowania 15 sekund zamiast ludzkiego gościa.

Wiele osób sugeruje, że ten problem może być związany z blokowaniem synchronicznych procesów w tle , szczególnie związanych z dużymi zadaniami cron .

Jeśli to prawda, istnieje duża para modułów będących w trakcie aktywnego opracowywania przez gielfeldt *, które mogą całkowicie wyeliminować ten problem, a przynajmniej mogą dostarczyć wskazówek i pomóc twórcom stron w diagnozowaniu i leczeniu konkretnych sprawców w ich przypadkach. Oba zamieniają blokujące procesy synchroniczne na nieblokujące asynchroniczne HTTP lub komendy i oba oferują odpowiednie raporty, które mogą zidentyfikować kłopotliwe procesy:

• Proces w tle i dołączone do niego moduły umożliwiają asynchroniczne przetwarzanie kolejki procesów w tle Drupala, więc nie blokują się. To może zatrzymać problem. Ponadto dzięki dołączonemu modułowi Serwer procesów Apache w tle w najnowszym urządzeniu opracowano podstawowy, ale ulepszony raport interfejsu użytkownika z funkcjami nadzorowania, odblokowywania i sprawdzania czasów rozpoczęcia i postępu tych procesów. Może to zidentyfikować problem.
• Ultimate Cron opiera się na procesie w tle, aby umożliwić wyzwalanym przez cron zadaniom posiadanie osobnych asynchronicznych schematów, z których każde może być monitorowane i zatrzymywane w interfejsie użytkownika. Oprócz tego, że doskonale nadaje się do oddzielania ciężkich zadań zmniejszania wydajności od zwykłego czyszczenia o niskim koszcie, daje również raport z wygodnymi informacjami, takimi jak czas trwania każdego pojedynczego zadania uruchamianego przez cron, kiedy ostatnio uruchomiono, aktualny stan, itp. Może to również usunąć blokowanie i / lub zidentyfikować problematyczne procesy.

Oba są i tak bardzo przydatnymi modułami; w przypadku tego problemu można je wykorzystać do przetestowania (bardzo prawdopodobnego brzmienia) teorii, że blokady są spowodowane synchronicznymi procesami blokowania lub uruchomieniami cron. Potencjalnie mogliby rozwiązać problem, uruchamiając je asynchronicznie zamiast synchronicznie, a także potencjalnie oferowali wskazówki, które konkretne procesy powodowały wstrzymanie. (ostrzegam, że ich dokumentacja jest w dużej mierze w toku ...

Jeśli jednak nie można ich skonfigurować tak, aby w ogóle pomagały, sugeruje to, że problem jest czymś więcej niż tylko synchroniczne procesy w tle. FWIW, nigdy nie miałem tego konkretnego problemu na stronie od czasu, gdy moduły te działały poprawnie (jeszcze - dotykaj drewna) - ale widziałem to wcześniej na moich stronach, a także na żywo w witrynach Drupal na wolności.

Należy także pamiętać o innych powiązanych modułach wtyczek, które są obecnie opracowywane - np. W skomplikowanych przypadkach o wysokiej intensywności, Ultimate Cron Queue Scaler , który umożliwia ograniczanie oparte na progach, może pomóc zmniejszyć problemy związane z wydajnością cron.

* brak przynależności, jestem pod dużym wrażeniem użytkownika ich pracy

Ponieważ uderza mnie to jeszcze raz, zaczynam badać problem. Zdecydowanie mogę to potwierdzić

1. wywołanie drupal_cron_run()uruchamiane przez cron rdzenia poormana dodaje ~ 5s do czasu żądania na mojej maszynie deweloperskiej. To może być testowany przez odkomentowanie testy na całym wywołanie drupal_cron_run()w modules/system/system.modulewsystem_run_automated_cron()
2. wyczyszczenie wszystkich pamięci podręcznych dodaje ~ 2s do czasu żądania na mojej maszynie programistycznej. Można to przetestować, wykonując drush cc alli ponownie ładując stronę.

Oznacza to, że ustawienie crona na nigdy i dodanie wywołania do crona przez crontab znacznie poprawia sytuację. Późniejsze trafienie na często używane strony w celu uzupełnienia pamięci podręcznej poprawiłoby wrażenia użytkownika.

Nie jestem jednak pewien co do buforowania. Nie zmieniłem domyślnych ustawień pamięci podręcznej dla tej witryny. Myślę, że Drupal od czasu do czasu odbudowuje wszystkie pamięci podręczne, być może uruchamiane przez crona, ale nie jestem pewien, jak to się robi. Ale opóźnienie 7 s jest prawie tym, co widzę, gdy po kilku godzinach trafiam na stronę.

Takie problemy mogą doprowadzić cię do szału, a gdy byłem w podobnych sytuacjach, pomaga dowiedzieć się, co powoduje, że problem przechodzi krok po kroku, a następnie przetestować go jako anonimowego i zalogowanego użytkownika. (metoda warstwy cebuli)

Wspominasz, że zaczynasz zauważać problem po graniu z kilkoma motywami i niestandardowym kodowaniem własnego. Nie wiem, jak skomplikowana jest Twoja witryna ani jaka jest jej logika, ale następujące kroki pomogą Ci znaleźć problem:

1. Na swoim serwerze utwórz folder lub inne konto (może być lepiej), na którym zamierzasz przeprowadzić czystą instalację Drupal z tą samą wersją, której używasz na swojej stronie. Następnie bez dodawania żadnego modułu lub testu motywu czas potrzebny na odpowiedź witryny na pierwsze i następne żądanie. Jeśli wszystko działa dobrze, możesz zignorować problemy z konfiguracją serwera, jeśli zachowuje się tak samo jak bieżący, masz błąd konfiguracji albo z serwerem WWW, albo z bazą danych.

2. Jeśli wyniki z kroku 1 są dobre, a serwer szybko reaguje, a kolejne żądania są tak szybkie, zainstaluj tylko motyw z bieżącej witryny w witrynie czystej instalacji i przetestuj go ponownie. Jeśli wszystko nadal reaguje szybko, Twój motyw nie stanowi problemu i powinieneś przejść do kroku 3, w przeciwnym razie musisz rozpocząć debugowanie motywu * 1.

3. Jeśli po testach w kroku 2 witryna nadal szybko zaczyna przenosić moduły w bieżącej witrynie i sprawdź czas odpowiedzi po dodaniu i włączeniu każdego modułu * 2.

4. Jeśli po dodaniu motywu i modułów strona nadal odpowiada szybko zacznij dodawać konfigurację, twórz typy zawartości, importuj widoki, menu konfiguracji itp. Nie zapomnij przetestować odpowiedzi witryny po dodaniu każdego z nich.

5. Instalacja i konfiguracja gotowe, a strona wciąż szybka, więc teraz przenieś dane. Importuj węzły, warunki taksonomii, komentarze itp. Wiem, że muszę brzmieć jak zepsuty rekord, ale zawsze wykonuj test po zakończeniu każdego kroku.

* 1 Testowanie motywów: ten proces może być trudny w bardzo rozbudowanym motywie, oto kilka wskazówek:

1. Jeśli łączysz się z dowolną zewnętrzną biblioteką js lub css, spróbuj użyć jej lokalnej kopii.

2. W pliku template.php sprawdź, czy funkcja może mieć dłuższe lub niekończące się pętle, a także funkcje przetwarzania wstępnego i / lub funkcje motywu przechwytującego.

3. Sprawdź inny plik szablonu (page.tpl.php itp.) I poszukaj surowego przetwarzania PHP tablic i obiektów.

4. Jeśli używasz „Widoków” i plików szablonów widoków, sprawdź również.

5. Zawsze dokładnie sprawdzaj ścieżki, optymalizuj obrazy, pliki js i css. Czasami pliki js mogą mieć dużą wysokość, gdy używają wielu fragmentów kodu w jednym pliku.

* 2 Testowanie modułów: testowanie modułów jest nieco inne, ponieważ dozwolone jest stosowanie ciężkich manipulacji przy pomocy PHP. Oto kilka wskazówek:

1. Moduły obsługiwane przez społeczność (CCK, widoki itp.) Mają kolejkę problemów na drupal.org, sprawdź je, aby sprawdzić, czy istnieje jakiś problem dotyczący twojego problemu i czy istnieje szansa, że ​​może istnieć łatka do jego rozwiązania.

2. Własny kodowany moduł, więc jeśli kodujesz, musisz go naprawić, prawda ?. Dokładnie sprawdź kodowanie i sprawdź użycie funkcji w api.drupal.org, być może używasz funkcji przepełnienia zamiast haka.

3. Udostępniany przez Internet niestandardowy moduł kodu, wykonaj czynności jak w kroku 2, ale tym razem możesz również skontaktować się z oryginalnym modułem, który go napisał, i poinformować go o problemie.

4. Jeśli witryna jest aktualizacją (D5 -> D6 -> D7), sprawdź skrypty migracji lub aktualizacji (zwykle w pliku module.install), może być potrzebny dodatkowy „indeks” w nowej konfiguracji tabeli, aby przyspieszyć wolne zapytanie SQL X .

5. Jeśli uważasz, że masz wizję tunelu dotyczącą problemu, wyjdź na chwilę i wykonaj inne czynności całkowicie niezwiązane, a następnie wróć później, aby wrócić do problemu.

6. Jeśli pingujesz, wskazując problem na odcinku kodu, ale nie możesz zrobić żadnych głów i ogonów na temat tego, jak to naprawić, spróbuj wyjaśnić, co ta sekcja jest dla osoby, która nie ma pojęcia, jak programować lub jak działa Drupal gotowy na niespodziankę.

Uwaga: nie przejmuj się, jeśli po przebudowaniu witryny zaczną działać jak urok, który jest jedną z najlepszych funkcji komputerów.

Sprawdź dokładnie, czy nie usunąłeś żadnych modułów bez ich odinstalowania. Powoduje to opóźnienie, ponieważ Drupal próbuje znaleźć pliki, ale już ich nie ma.

Usuń odniesienia w tabeli zmiennych, jeśli moduły już nie istnieją.

Web APM, taki jak newrelic, jest najlepszym narzędziem do śledzenia problemów z wydajnością. Miałem witryny wywołujące jeden lub dwa wiersze kodu, które robiły dziwne rzeczy, ładowały niepotrzebne tablice w dziwnych czasach i robiły inne rzeczy, które były dość niewidoczne, dopóki nie wyśledziliśmy ich za pomocą APM.

Ktoś wspomniał, że GoDaddy będzie wolny. Wiele firm hostingowych działających w chmurze również będzie miało to początkowe opóźnienie, ponieważ mają go takie usługi, jak AWS. Tańsze jest automatyczne zmienianie priorytetów serwerów, a te serwery będą potrzebowały sekundy lub dwóch, aby się „obudzić”.

Na przykład Pagodabox ma 3-4 sekundy na pierwszy bajt, dopóki serwer się nie obudzi. Pagodabox w rzeczywistości zarabia na utrzymywaniu serwera w stanie uśpienia, więc możesz zapłacić dodatkowo za „caffienate” swojej witryny.

Ponadto CDN może ci pomóc. Twój serwer WWW / db nie zostanie załadowany z udostępnianiem stron lub obrazów z pamięci podręcznej. Dobry tutorial tutaj: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

I ... WebPageTest mnie uszczęśliwia. http://www.webpagetest.org/ Porównaj czasy ładowania na całej planecie i za pomocą różnych przeglądarek internetowych za darmo. Użyj tego, aby uzyskać rzeczywiste wyniki dla wszelkich wprowadzanych zmian.

problem może być wszędzie.

1. Upewnij się, że nie włączyłeś trybu debugowania w żadnym motywie lub module. Na przykład w wielu motywach istnieje możliwość ponownego wygenerowania rejestru motywów.
2. Jeśli korzystasz z hostingu współdzielonego, takiego jak Godaddy, 15 sekund po raz pierwszy jest normalne.
3. Konwertuj swoją stronę lub stronę główną do bazy kodu za pomocą modułu eksportu Drush CTools . To wyeliminuje wszelkie wywołania bazy danych, a twoja strona będzie działać w całości z php.
4. Jeśli nadal występują problemy, skorzystaj z ustawień Devel, włączając opcję query logi page timeropcje w admin/config/development/devel. Sprawdź, który z nich zajmuje więcej czasu, aby wygenerować całą stronę.
5. Uruchom ponownie serwer, jeśli nic nie działa.
6. W najgorszym przypadku zainstaluj XHProf, aby zobaczyć, co się dzieje.

W ten sposób naprawiłem problem z moją instalacją. To nie jest prawdziwe rozwiązanie, ponieważ nie mogłem ustalić dokładnego źródła problemu (jeśli istnieje), ale jest to dobra poprawka

1) Agreguj CSS (ustawienia pamięci podręcznej). Zmniejszyło to opóźnienie o połowę

2) Ustaw cron na nigdy (i uruchamiaj go zewnętrznie) - Uwaga: Miałem błędy „próby uruchomienia crona, gdy już działa”. Myślę, że próbował uruchomić crona przy każdym uruchomieniu, ale ponieważ się nie udał, strona cron nie wspominała o ostatniej próbie, ale raczej o ostatnim sukcesie.

3) Skonfiguruj zadanie crona, które wywołuje stronę główną z Lynx co 30 minut

Wszystko to na wspólnym serwerze hostingowym. To nie jest optymalne, ale działa

Sugeruję użycie pamięci podręcznej frontonu zgodnie z modułem Boost (zakładając, że korzystasz z hostingu współdzielonego) lub Varnish. Będzie to działać najlepiej, jeśli dostęp do witryny jest przede wszystkim anonimowy, a zawartość strony w przeważającej części nie jest dynamiczna (tzn. Strony niewiele się zmieniają).

Rozwiązania te zapisują renderowane strony przy pierwszym dostępie, a następnie obsługują wstępnie renderowany HTML zamiast przechodzenia przez pełny bootstrap Drupal, tworzenie stron i procesy tematyczne, oszczędzając dużo czasu, szczególnie na ruchliwych stronach, ale także na stronach takich jak ty opisz, które „idź spać” i zbyt długo się budzić.

Jedyną wadą jest to, że (przynajmniej w przypadku Boost) musisz wyczyścić pamięć podręczną, gdy zmienia się zawartość witryny. Jeśli chcesz się upewnić, że witryna jest w pełni buforowana przy użyciu bieżącej zawartości, możesz uruchomić drush cc all, a następnie okresowo za pomocą crona zawijać lub wget na całej stronie.