Náročnost wordpressu na databázi

Zdravím, právě operuji s wordpressem a narážím na problém nedostatečného výkonu. Na čem si Wordpress potrpí co se výkonu týče? Uvažoval jsem nad VPS na kterém bych toto měl, ale jaké by to mělo mít parametry? Právě u VPS mě děsí že by mi spadla databáze a znefunkčnila by mi všechno co by na serveru běželo. Na závěr doplním že ve wordpressu se nachází přes 25 tisíc příspěvků které to dost dobře zabíjejí.. Díky za pomoc a případné nabídky

Doplnil bych WP o nějakou objektovou cache (Xcache, APCu, Redis,...) to rapidně sníží počet potřebných dotazů do DB (pokud tam není nějaký špatný plugin). Pokud je to málojádrové VPS, tak z hlediska DB často pomůže QueryCache na straně SQL serveru (to je třeba otestovat, pro velké množství různých dotazů to naopak výkon může snížit).O výkonu WP jsem měl přednášku: http://lynt.cz/blog/optimalizace-vykonu-webovych-aplikaci-na-co-se-zamerit

Napsal smitka;1299922

Doplnil bych WP o nějakou objektovou cache (Xcache, APCu, Redis,...) to rapidně sníží počet potřebných dotazů do DB (pokud tam není nějaký špatný plugin). Pokud je to málojádrové VPS, tak z hlediska DB často pomůže QueryCache na straně SQL serveru (to je třeba otestovat, pro velké množství různých dotazů to naopak výkon může snížit).

O výkonu WP jsem měl přednášku: http://lynt.cz/blog/optimalizace-vykonu-webovych-aplikaci-na-co-se-zamerit

Dobrý den,momentálně jsem u WEDOSu a zvažuji nad VPS, nicméně mě opravdu děsí to že mi spadne databáze a ostatní projekty tak nebudou dostupné... Dá se toto nějak ošetřit? Cache optimalizaci používáme - WP Super Cache (jako plugin ve wordpressu)

záleží co na tom WP máš, pokud statický web, strašně moc pomůže cachující proxy a dobře posílané http hlavičky, jen to buď musíš vyřešit nějakým pluginem nebo si raději pravidla napsat sám na proxy.Databáze může spadnou "pouze" pokud jí máš nastavenou (výchozí stav), aby si vzala více paměti než máš na serveru, což je typický případ vps s 1 gb ram. Každý projekt má svého uživatele, ten limit na spojení a max. čas dotazu, admin a cron mají svého uživatele, tímhle jednoduše eliminuješ většinu problémů.u WP redis cache dělá strašně moc, WP Super Cache většinou spíše zpomalí než zrychlí, cache proxy a pár pravidel poslouží lépe, ale je s tím práce. Dobrý zdroj informací je dokumentace na stránkách WP, pro řadu projektů stačí pouze čerpat tam.Query cache u MySQL/Mariadb je zákeřná, často u WP vídám jí nastavenou na stovky MB či GB, což je kontraproduktivní a režie spojená s cache je obrovská a celé to je stejně pomalé, důležité je měřit a navyšovat postupně. Spíš dotazy do databáze šetřit a stránky cachovat, tím získáš nejvíce. Statický obsah hodit do CDN či na rychlý webserver (nginx, varnish), přidat třeba přes htaccess správné http hlavičky na cachování, podrobné info opět na stránkách WP. Http/2 s https opět udělá strašně moc a ušetříš tím ty tuny http požadavků, které WP generuje a obrovsky se zrychlí načítání stránek.

Databáze může spadnou "pouze" pokud jí máš nastavenou (výchozí stav), aby si vzala více paměti než máš na serveru, což je typický případ vps s 1 gb ram.

Ano, to je nejčastější příčina pádu DB. A proto je dobré rozdělit si hosting na 2 stroje, kdy bude databáze na samostatném serveru a bude nastavená tak, aby optimálně využívala dostupnou paměť a nemusela se bát, že jí ji nějaký PHP skript sežere.

WP Super Cache většinou spíše zpomalí než zrychlí

S tím jsem se ještě nesetkal, z mého pohledu je WP Super Cache nejlepších stránková cache - především proto, že je poměrně primitivní a lze tak predikovat její chování.Cache je několik druhů na různých úrovních, WP SuperCache dělá to, že celou stánku uloží ve statické formě a načítání je pak vlastně čtení statického souboru. Aby dobře fungovala, tak je potřeba tyto statické soubory nejdříve vygenerovat, což typicky udělá první návštěvník pro stránku kterou zrovna prohlíží. V případě 25000 příspěvků v kombinaci s levným hostingem si neumím moc dobře přestavit, že by zde byla dostatečná návštěvnost, aby byla nějaká rozumná šance, že návštěvník přijde na již zacachovanou stránku (v tomto případě SuperCache web zpomalí, protože navíc musí obstarat vytvoření cache). Tomu lze bránit předgenerováním cache dopředu nějakým skriptem, nebo alespoň částečně nastavením doby platnosti cache na velmi vysokou hodnotu v řádu týdnů/měsíců, pokud to obsahu nevadí.Do objektové cache se oproti tomu ukládají výsledky mnoha operací ve WP, které se v základu ukládají (pokud se ukládají) jako transientní proměnné do DB. Objektová cache proto dokáže dost zredukovat počet dotazů do DB. Další vrstva je OPcode Cache, která ukládá již "zkompilované" PHP, aby se skript nemusel překládat stále dokola. PHP7 dosahuje skvělých výkonů, z velké části díky tomu, že umí lépe pracovat s tímto typem cache (a také díky tomu přidělenou RAM pro tento účel mnohem rychleji vyplýtvá).

To je samozřejmě problém, hosting ti to už nejspíše neutáhne a at ho vezmeš od kohokoliv. Jistě jsou výkonější řešení než má Wedos, ale určitě i tam narazíš na strop. 25k je prostě moc. Je otázka jak máš nastavenou ekonomiku. Zda se ti to vyplatí přejít na výkonný server nebo zda máš "virální" web tj. hodně postů za málo muziky. To je pak téměř neřešitelné. Určitě pomůže WP Cache a jestliže máš hodně obrázků tak i CDN. Nicméně jak psal výše Smitka tak u WP Cache musíš nasimulovat otevření každého postu který ti vytvoří cache. Jestliže neumíš programovat, tak nejlevněji se dopracuješ nějakého scriptu co to udělá za tebe na Freelance.com. Měj také na paměti že 25K postu v cache bude něco zabírat tak si hlídej případně místo.