Problem z wydajnością: opóźnienie na pierwsze żądanie

36

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ść?

Kim Prince
źródło
2
Nie mogę powiedzieć, jak bardzo chciałbym to rozwiązać. Moja robocza teoria jest taka, że ​​po około godzinie cron uruchomił się (opróżnia pamięć podręczną) i pierwsze żądanie zajmuje trochę czasu ze względu na potrzebę wszystkich tych zapytań do bazy danych niebuforowanych. Ale zgaduję
Clive
Mam ten sam problem. włączenie buforowania dla anonimowych użytkowników rozwiązało problem, ale wiem, że nie jest to dobre rozwiązanie
znat
@Kim: Zastanawiałem się, czy znalazłeś źródło problemu i / lub dobre rozwiązanie
znat
2
Kilka odpowiedzi wspomina o cronie biednego człowieka: czy ktoś, kto ma problem, może potwierdzić, czy uruchamia crona za pomocą crontab, czy też polega na cronie biednego człowieka?
Andy,
6
Właściwie, jeśli jest to cron, to prawdopodobnie nie tylko cron, ale update_cron () szuka nowych wydań, co może zająć sporo czasu. spróbuj wyłączyć update.module, aby zobaczyć, czy to jest problem.
Berdir,

Odpowiedzi:

16

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.

mpdonadio
źródło
Znalazłem prawie wszystkie stosy deweloperów AMP (M / L / W), nawet te specjalnie dla Drupala, takie jak Bitnami, są źle dostrojone lub wcale nie dostrojone (myślę, że stos deweloperów Acquii jest wyjątkiem). Oczywiście nie jest to domyślna instalacja mySQL dla maszyny produkcyjnej. Pliki dziennika InnoDB są domyślnie takie jak 5M, a przydzielona pamięć jest niewielka. Często odpowiednie dostrojenie jest wszystkim, czego potrzeba, aby strona była niezadowolona - wystarczy nawet wpuszczenie my-medium.cnf lub my-large.cnf.
Renee,
Było tak wiele dobrych odpowiedzi na to pytanie, dzięki wszystkim, którzy widzą ten komentarz i wnieśli swój wkład w post. Pomyślałem, że ta konkretna odpowiedź podsumowała główne kwestie ładnie i zwięźle; dokładne sprawdzenie tych 3 punktów pomogło ładnie przyspieszyć strony Drupala na różnych maszynach. Dzięki @MPD
Clive
9

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”.

Attiks
źródło
Nie sądzę, że wyłączenie crona rozwiązuje problem, bardziej prawdopodobne jest ukrycie go na później. Ale przynajmniej myślę, że można nieco zawęzić problem z wydajnością;)
wiifm
1
Attiks nie mówi o wyłączaniu crona; mówi, aby zmienić opcję wywoływania zadań cron, gdy dowolny użytkownik odwiedza stronę w witrynie. Jest to konkretna opcja, którą jest Drupal 6, która została zaimplementowana w module Poormanscron . Zmiana tej opcji nie oznacza wyłączenia zadań CRON.
kiamlaluno
8

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.

BetaRide
źródło
2
Tak, istnieje wiele możliwych przyczyn czegoś takiego, uxing XhProf jest zwykle najlepszym sposobem na znalezienie rzeczywistego problemu.
Berdir,
6

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

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

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ń.

RolandoMySQLDBA
źródło
Naprawdę przydatne informacje, dzięki. Czy problemy te byłyby w stanie wyjaśnić, że problem występuje tak regularnie / konsekwentnie? Większość raportów, które widziałem, szacuje, że brak aktywności w witrynie przez 30–60 minut powoduje opóźnienie powrotu do początkowego ładowania strony
Clive
2
@Clive W przypadku całej bazy danych MyISAM nastąpi to, jeśli strony indeksu MyISAM załadowane do pamięci podręcznej kluczy MyISAM kilka godzin temu i nieużywane przez długi czas zostaną wyparte. Wywołanie tych wyrejestrowanych danych będzie wymagało odczytu dysku dla MyISAM. To samo zachowanie może wystąpić również w przypadku InnoDB, szczególnie jeśli bufor InnoDB jest zbyt mały. Ponieważ InnoDB buforuje dane i strony indeksowe, konwersja wszystkich MyISAM do InnoDB i użycie dużej puli buforów InnoDB może zminimalizować lub nawet wyeliminować takie problemy z ładowaniem strony.
RolandoMySQLDBA,
Świetnie, zrobię wtedy profilowanie na podstawie tego, brzmi obiecująco. Jeszcze raz dziękuję
Clive
2
@Clive Chciałbym polecić użycie mk-query-digest lub pt-query-digest do przeprowadzenia profilowania. Napisałem ładny skrypt w DBA StackExchange, aby profilować każdy ustalony interwał z pliku crontab: dba.stackexchange.com/a/8382/877
RolandoMySQLDBA
5

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.


źródło
4

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

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

Aram Boyajyan
źródło
3

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.

Citricguy
źródło
3

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

user56reinstatemonica8
źródło
2

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ę.

BetaRide
źródło
1

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.

Emil Orol
źródło
1
Właśnie ponownie zainstalowałem pustego drupala i bez opóźnień. Więc następnym krokiem jest pchnięcie mojego tematu. Jednak zajmie to dużo czasu, ponieważ muszę poczekać pół godziny, aby problem się powtórzył
znat
1
Cieszę się, że to nie jest problem ze sprzętem lub konfiguracją serwera. Prześlij ponownie swoje ustalenia.
Emil Orol,
1

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ą.

oko kota
źródło
1

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.

beth
źródło
1

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.

paul-m
źródło
To dobra informacja, ale problem nadal występuje w witrynach na moim komputerze lokalnym, zużywając tylko zasoby lokalne
Clive
0

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.
Minty
źródło
1
Czy możesz wyjaśnić # 2?
Johnathan Elmore,
0

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

znat
źródło
0

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.

jmarkel
źródło