it-swarm.dev

Proč je domov (hodně) pomalejší než jiné stránky?

Snažím se naladit wordpress webovou stránku, která trpí pomalým načítáním časů, a zjistil jsem, že domovská stránka vypadá, že trvá mnohem déle, než se načte. Není to kvůli obsahu, protože jsem jen zvažuje dobu potřebnou k ukončení základního požadavku (lze ho zobrazit prostřednictvím firebugu v firefoxu).

Také jsem se pokusil kopírovat kód index.php na vlastní stránku a stejný přesný kód načte během přibližně 1 sekundy, zatímco hlavní domov načte asi 7. Zjistil jsem, že jednotlivé stránky se načítají rychleji a zpočátku jsem si myslel, že je to kvůli rozdíl v obsahu, ale po tomto testu si nejsem jistý, co to způsobuje.

Existuje mnoho věcí, které wordpress dělá v zákulisí pouze pro hlavní index? Existuje nějaká jiná cesta, jak tuto situaci vysvětlit a co je důležitější, opravit ji tak, aby se domovská stránka načítala rychleji?

AKTUALIZACE - DIRTY SOLUTION

Po spoustě slepých pokusů jsem vytvořil novou stránku nazvanou home, která používá index.php jako vlastní šablonu (ne kopii, stejný soubor). Přesměroval jsem všechny hovory na základní cestu k němu (přes wordpress 'interní přepsání) a mám stejnou domovskou stránku jako dříve, právě načten v 1/6 času. I když jsem s výsledkem spokojený, rád bych pochopil, co se děje.

ANOTHER UPDATE

Zdá se tedy, že nemůžu použít stránku s dynamickým (ve smyslu wordpress) s touto stránkou, funguje to jen dobře s vlastní "statickou" stránkou, kde vkládám obsah prostřednictvím různých funkcí, takže normální smyčka dělá doma buď velmi pomalé (s vysokým limitem paměti) nebo jen prázdné (limit nízké paměti, skript se nezdaří).

Jak bylo navrženo v této otázce , vytvořil jsem statický domov propojený s vlastní stránkou a funguje to dobře. Vytvořil jsem také stránku blogu (opět s vlastní šablonou), která také funguje dobře (kde „v pořádku“ znamená, že zobrazuje prázdnou testovací stránku obsahující pouze jedno slovo a žádný kód)pokudspecifikuji to jako "Příspěvky" v admin -> Nastavení čtení. Jinými slovy to vypadá, jakmile wordpress vidí dynamickou stránku (ta, která má držet hlavní smyčku) to dělá něco velmi těžkého, který jí až hodně berana.

Stále hledám příčinu tohoto problému, ale můžu s tím pracovat, ale rád bych pochopil, jaký je problém.

Upravit: přidána odměna

Více informací: Snažil jsem se vypnout všechny pluginy, wordpress je aktualizován na nejnovější verzi.

DALŠÍ ÚPRAVA: TABULKA INDEXES

wp_posts:

PRIMARY KEY  (`ID`),
KEY `type_status_date` (`post_type`,`post_status`(1),`post_date`,`ID`),
KEY `post_status_date_gmt` (`post_status`(1),`post_date_gmt`),
KEY `post_date` (`post_date`),
KEY `post_date_gmt` (`post_date_gmt`),
KEY `post_parent` (`post_parent`),
KEY `post_name` (`post_name`),
KEY `post_status` (`post_status`),
KEY `post_author` (`post_author`),
FULLTEXT KEY `post_related` (`post_name`,`post_content`),
FULLTEXT KEY `post_content` (`post_content`,`post_title`),

wp_term_relationships:

PRIMARY KEY  (`object_id`,`term_taxonomy_id`),
KEY `term_taxonomy_id` (`term_taxonomy_id`)

wp_term_taxonomy:

PRIMARY KEY  (`term_taxonomy_id`),
UNIQUE KEY `term_id_taxonomy` (`term_id`,`taxonomy`),
KEY `taxonomy` (`taxonomy`)
6
Matteo Riva

Po téměř čtyřech letech jsem se k tomu vrátil a konečně našel problém. Ukázalo se, že stránka měla spoustu článků označených jako lepkavé. Vzhledem k neuvěřitelně hloupý způsob, jak wordpress používá k označení lepkavé příspěvky (serializované pole v wp_options), hlavní smyčka dynamické domovské stránky trvalo neuvěřitelně dlouhou dobu. Odstranění pole sticky_posts v tabulce problém vyřešilo.

2
Matteo Riva

Chtěl bych se lišit od předchozích dvou poznámek.

Výsledkem použití statické domovské stránky je WP pomocí indexového skenování na primárním klíči tabulky příspěvků, vs (oh tak občas) indexového skenování na stránce post_date, stavu nebo post_parent v tabulce příspěvků.

V podstatě je domovská stránka pomalá kvůli špatnému návrhu databáze ve WP. Schéma má v tabulkách taxonomie směšné multicolumnové indexy, které MySQL jednoduše ignoruje, jakmile budete mít významný počet příspěvků. Ani skutečnost, že používáme příliš mnoho tabulek pro taxonomie, nepomůže.

V databázi bezpečně přidávejte indexy na adrese:

CREATE INDEX extra_posts ON posts (post_type,post_status,post_date DESC)
CREATE INDEX extra_term_rel ON term_relationships(term_taxonomy_id,object_id)
CREATE INDEX extra_term_tax ON term_taxonomy(taxonomy,term_taxonomy_id,term_id)

Nebude to dokonalé, ale alespoň WP bude moci na vaší titulní stránce používat plány vnořených smyček založené na indexu ...

A pokud používáte jakýkoli typ vlastního příspěvku na své titulní stránce, musíte také přidat:

posts(post_status,post_date DESC)

Jinak se pro hlavní dotaz nepoužije žádný index z důvodu klauzulí OR.

7
Denis de Bernardy

Ve výchozím nastavení není rozdíl pro výkon domovské stránky. Existuje však možnost, že některý plugin na této stránce udělá něco pomalého.

K dispozici je spousta pluginů pro profil WP výkon. Obvykle používám WP Tuner ale zdá se, že je rozbitý pro nejnovější verzi WP, takže nemám žádnou okamžitou náhradu, abych to navrhl.

Nejjednodušším způsobem je balení šablony plné značek času/paměti.

printf(  '%d queries in %.3f seconds, using %.2fMB memory', get_num_queries(), timer_stop( 0, 3 ), memory_get_peak_usage() / 1024 / 1024 );

Je to hrubé, ale často umožňuje určit polohu, kde dochází ke zpomalení.

5
Rarst

Nejprve zkontrolujte quereis WOrdPress a zahrnuté obrázky, skripty a styly. Dotazy můžete zkontrolovat pomocí pluginu Debug Queries a získáte více informací o instalaci a chybách pomocí pluginu Debug Objects .

0
bueltge

Pokud domovská stránka trvá tak dlouho, aby se načítala, pravděpodobně máte plugin nebo funkci v motivu, který dělá vzdálený požadavek nějaký čas, když je domovská stránka vykreslována.

Udělal bych rekurzivní vyhledávání v adresáři wp-content pro volání na 'wp_remote_', abych vyhledal všechny funkce, které by to mohly způsobit.

0
prettyboymp