it-swarm-eu.dev

Jak dobře WordPress měřítko?

S novým WordPress a je to nové funkce, zdá se, že WordPress je schopen mnohem více než jednoduchý blog engine. Ale jak dobře WordPress měřítko používá říkat 10k -> 100k uživatelů za den?

S tím, že mnoho uživatelů velkou část bude mít dobrou cache strategie, ale jak dobře je WordPress vyvinut, aby pomohla, takže to snadné a dát vám kontrolu, kterou potřebujete. Fx je schopen ukládat do vyrovnávací paměti část stránky a pouze vykreslovat uživatelské části, podporovat master/slave db nastavení a tak podobně?

34
googletorp

Jasně nic měřítka, stejně jako statické soubory obsluhované rychlým webovým serverem a jakýkoli CMS, který musí zjistit, co načíst a pak načíst nebude fungovat stejně, WordPress nebo jinak. Jedním z problémů je počet databázových dotazů požadovaných na žádost o URL a mé 2 předchozí zkušenosti s prací výhradně s Drupal a nyní 2+ let s WordPress je, že WordPress je mnohem lepší v tomto oddělení.

To říkalo, téměř nic s jakoukoli mocí bude v měřítku "mimo krabici"; je to všechno co můžete dělat, když vaše potřeby rozšiřitelnosti rostou?

Na nízkém konci "spousta provozu" existují velké pluginy pro ukládání do mezipaměti a integrace s levnými CDN můžete udělat docela dobrou práci na ne-IT rozpočtu a nízkém hostingu rozpočet. Zde naleznete několik dalších otázek a odpovědí k recenzi:

Existují možnosti pro profilování k identifikaci překážek výkonnosti:

Jakmile jsou identifikována úzká místa, můžete to udělat lokalizovaná optimalizace s věcmi jako Transients API. Tento dotaz poskytuje příklady, které lze optimalizovat pomocí rozhraní API Transients a ukazuje, jak:

Pokud se opravdu chcete dostat vytáhněte velké zbraně můžete nakonfigurovat Memcached, HyperDB, Nginx a/nebo více, abyste věci zrychlili (zdá se, že to je druhé opravdu se vyvíjející do způsobu, jak dostat úžasnou škálovatelnost z WordPressu):

A konečně tam jsou objevující se WordPress-zaměřené webhosts specializující se na výkon jako WP Engine , ZippyKid a další:

Takže dobrá zpráva je velmi pěkná; od velmi nízkého konce volného a snadného s technickou složitostí a náklady jen rostou, jak provoz výrazně roste. Začněte malý s WordPress a bude to skvělé. Pokud váš provoz roste a vy zpeněžíte to i rozumně dobře, zjistíte, že je to velmi cenově efektivní měřítko, jak ho potřebujete.

Alespoň IMO. :} _

37
MikeSchinkel
  1. Neočekávejte mnoho ze sdílených hostingu - nevinte WordPress za pomalost, pokud jste na sdíleném Host. Sdílené hostitelé mohou na jeden server napěchovat 1000s účtů. Takže můžete strávit celý den optimalizací účtu $ 10/month a nezáleží na tom. Také dávejte si pozor na marketing buzzwords - jen proto, že říká, že "cloud" neznamená, že nesdílíte jeden server se 100s nebo 1000s lidí.

  2. Nemyslím si, že v tomto okamžiku jsou nutné mezipaměti. Když se podíváte na zdrojový kód WP, je již do jádra zapuštěno pokročilé ukládání do mezipaměti. Mezipaměť cache mezipaměti mezipaměti - pozor, to může být kontraproduktivní.

  3. Hlavní věc, která vás zpomaluje je pomalé MySQL dotazy a WordPress out-of-the-box by vám neměli dávat potíže. Musel jsem však "LIMIT" své komentáře dotazy, protože jsem měl 50.000 + komentáře. (Je to ještě pevné?) Také, pokud děláte něco atypického (jako 1000s kategorií?), Který by mohl být také problém.

  4. Používám Linode 512 s NginX a "top" ukazuje PHP a NginX dělá svou práci za méně než 1/100 sekundy na požadavek. Téměř všechny CPU čas je svázaný s MySQL. Mohli byste sloužit 1 milion stránek za měsíc s $ 20 Linode, ale jakmile začnete přidávat pluginy a fotografie, myslím, že budete potřebovat "1GB" Linode. Z mého pohledu je to skoro lineární: Pokud se zobrazení stránek zdvojnásobí, stačí dvojnásobek velikosti vašeho Linode.

Disclaimer: Nepracuji pro Linode.


Aktualizace (~ 2 roky později), protože chcete ukládat části stránky do PHP, zde je jednoduché řešení, které používám a je to překvapivě rychlé. Ukládám několik samostatných částí/částí na stránku během 1/100 sekundy. Vypadá to jako ramdisk by to mohlo být ještě rychlejší, ale je to dost rychlé pro mé potřeby:

$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file);  // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {

    // heavy lifting starts
    $output = 'Heavy!';
    // heavy lifting ends

    if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache    
    echo $output;

} else { 

    // load from cache
    $output = file_get_contents($cache_file); 
    echo $output;        
} 
4
PJ Brunet

Tam jsou nakonec 3 věci, které zpomalují WordPress v měřítku, a oni se sníží na toto:\t

  • Hosting stack - potřebujete dobrý host s nejnovějším softwarem - PHP 7, Nginx, Varnish, Redis, fail2ban a PerconaDB jsou všechny dobré volby
  • Žádné tabulky skenování - mnoho pluginů jsou napsány amatérskými kodéry, kteří ani nevědí, co je tabulka scan. K vyhnutí se prohledávání tabulek jsou potřeba dvě věci - použitelný index a dotaz napsaný takovým způsobem, aby mohl index používat
  • Žádné nebo jen málo SQL dotazů uvnitř PHP smyček - některý zásuvný kód byl jednoznačně testován pouze na maličkých stránkách a z nějakého důvodu se bude procházet každým produktem ve vaší databázi a provede se nový SQL hovor pro každý produkt /pošta. V ideálním případě chcete méně než 100 SQL dotazů na stránku - zní to jako hodně, ale není to opravdu a s <100 dostanete TTFB cca 200ms neuzavřený.

Jakmile budete mít výše uvedené místo, můžete přidat mezipaměť - např. Lak, CDN, ukládání do mezipaměti stránek atd.

Pokud potřebujete zmenšit, můžete vytvořit klastr pomocí PerconaDB XtraDB pro databázi a Unison pro soubory. Tímto způsobem můžete mít 1 uzel jako běžec wp-admin a cron a další uzly sloužící pro webový provoz za balancerem.

0
Dave Hilditch