it-swarm-eu.dev

K čemu všichni přispívají drupal doba provedení stránky?

Mám web, který zkoumám a který má velké problémy s výkonem. Pomocí memcache jsem byl schopen snížit počet dotazů jak v počtu, tak v celkové době exekuce (od 3 s do 230 ms), ale doba provedení stránky mi uniká (já jsem při pohledu na hodnoty, které poskytuje devel), chápu, že doba spuštění stránky = čas potřebný k provedení php, proto jsem nainstaloval APC a vidím, že php opcode je v mezipaměti a statistiky zobrazující přístupy v ovládacím panelu APC (apc.php dodávané s APC), ale doba provedení mé stránky neklesá. Takže si myslím, že moje otázka je dvojí:

  • K čemu všichni přispívají (lépe zpomalují) dobu provádění stránky? Je to jen čas potřebný k provedení php?
  • Jaké přístupy bych měl použít ke zkrácení doby provedení stránky. Vyzkoušel jsem APC, ale moc mi nepomohl

P.S počet modulů použitých na tomto webu je prostě obrovský (168), ale právě teď nejsem v pozici, aby bylo možné toto doporučení, je to spíše jako oheň v situaci díry.

Edit: Výstup spuštění xhprof na lokální instanci (doporučeno mikeytown), zdá se to být šílené Myslím, že pozdější výsledky jsou způsobeny mlátením? diff běží pro stejnou adresu URL má drastický rozdíl a jeho příliš velké využití zdrojů. Také si nejste jisti, proč ukazuje hodnoty, které nejsou od dnešního dne: (Právě jsem do tohoto notebooku nainstaloval xhprof)

Output of running xhprof on local instance

17
Dipen

Získejte cachegrind vašeho webu. xdebug nebo xhprof může vygenerovat jeden. To vám řekne, jaké funkce jsou nejdelší na spuštění. Dokud to neuděláte, je to špatná hra.

4
mikeytown2

ÚPRAVA: Původní příspěvek jsem špatně přečetl. 168 modulů je hodně a 300 až 700ms dotazů SQL je obrovský. Čím více modulů použijete, tím více dotazů budou, jakmile moduly některé provedou.

Použijte agresivní ukládání do mezipaměti, zatímco můžete, mezipaměť vše, pokud to nestačí, zkuste reverzní proxy mezipaměť. Použití CDN pro soubory může celou věc výrazně zlepšit. Zpětná vyrovnávací paměť proxy vám také může pomoci tím, že odstraní některé soubory cookie Auth, když narazí na stránky, které to nepotřebují (jádro bude považovat uživatele za anonymního a maximalizovat mezipaměť).


Díky dynamice jádra Drupal) se celý úsvit zpomalí, jakmile budete mít současně příliš mnoho modulů.

Řekl bych například, že pokud používáte mnoho modulů, které načítají data v době hook_node_load () namísto použití polí, vytvoří se mnoho dotazů, zatímco využití pole by zajistilo účinnost ukládání do mezipaměti.

Vykreslování může také trvat hodně času, drupal_render () (někdy se nazývá vykreslovací API) je pěkný kousek API (opravdu užitečný), ale také trochu pomalý. Přepnutí na PDO (D7) a úplnou DBTNG (což je mimochodem skvělé) také přidá nezanedbatelnou latenci.

To znamená, že jádro samo o sobě je poměrně rychlé (ale dělá příliš mnoho dotazů SQL, i když není nainstalováno téměř nic), špatně kódované moduly jsou často překážkou.

APC může rozdělit dobu provádění na 2 nebo 3 v závislosti na spuštěném kódu. pokud ji nakonfigurujete dobře (povolte všechny optimalizace APC, je oficiální příručka APC dobře napsaná a povede vás).

Pokud jste v krabici s pomalým systémem souborů (síťový systém souborů nebo pomalý pevný disk), může to znamenat viditelný dopad na dobu provedení. Drupal je vyroben z hodně malých souborů, což nutí PHP dělat I/O na FS pokaždé, když načte jednu z nich (APC k tomu také hodně pomáhá).

Chybně nakonfigurovaná DBMS může být také docela ošklivá překážka, pokud používáte MySQL, přemýšlejte o tom, jak doladit. Pokud jste na sdíleném hostingu, pokud to není Drupal konkrétní (nebo připraven) DBMS a PHP stack bude pravděpodobně nesprávně nakonfigurován nebo nevyladěn, což může vést k opravdu pomalým webům.

Nezapomeňte aktivovat všechny mezipaměti. Pokud váš web není ověřený na uživatele, pak aktivujte agresivní ukládání stránek do mezipaměti (je to opravdu úžasné).

Čím více budete mít bloky, tím více stránek bude pomalých. Bloky modulů Pohledů budou úzkým profilem úsvitu (v závislosti na zásuvných modulech Pohledy, které můžete použít, blok OG může být skutečnou bolestí), pokud nebudete omezovat jejich viditelnost na základě jednotlivých stránek nebo s uživatelským kódem PHP= (jakýkoli jiný blok také vždy nastavuje viditelnost bloku ručně), což značně pomáhá rámci tím, že se vyhne pokusu o vykreslení prázdných bloků).

Vyhněte se modulům, které používají hook_init (), hook_init (), které jsou spuštěny na každé stránce, i když dostanete 403 nebo 404, což vše zpomalí (dokonce zpomalí generování času stylu imagecache | a 404 chyb v souborech by bylo svítí pomalu, abych vám řekl, že soubor neexistuje).

1
Pierre