Dotaz: Návrh systému v php

[Evik]

Ahoj, mám třídu která vrací nadpis a obsah stránky, problém je v tom, že potřebuji ten nadpis i pro title v head, jenže ten se generuje dřív než ten obsah stránky. Můžu sice vygenerovat obsah stránky dřív, ale to budu zase vláčet tuny textu po celém systému, což bude zabírat více paměti delší čas. Jak to řešíte vy, poradí prosím někdo?

Odpovědi

[Josef Kufner]

Obvykle to řeším tak, že to neřeším a nechám to v té paměti. Stejně se to do ní načte, pokud to jde z databáze, a že to tam bude ležet o pár milisekund déle nevadí.

Alternativní přístup je, že si to připravíš předem, ale načteš to, až když je to potřeba. Klíčové slovo je "lazy". Ale pokud to z databáze budeš načítat zvlášť, budeš dělat o SQL dotaz víc a to je ještě horší.

[AraxoN]

Normálne - "vláčím tuny textu po celém systému". Bežná stránka má od 5 do 50 kB zdrojového HTML, čo nie je žiadna tona. Ak by to náhodou malo prestať stíhať, tak to určite nebude z dôvodu toho, že sa niekde zduplikuje 50kB string.

[Kit]

Nejprve si do stromu DOM nasázím všechna potřebná data a pak to všechno předhodím výstupní šabloně. Časy jsou v jednotkách milisekund, víc to už asi zrychlit nejde.

[Evik]

Zkoušel jsem spočítat čas, dělá to 0.0009sec - 0.0013sec.. a max využitá paměť je 512 - 768 kilobytes, což se mi teda zdá sakra moc nebo ne?

[AraxoN]

Ak to plánuješ prevádzkovať na Commodore 64, tak to naozaj je príliš veľa... Ale teraz vážne - chválim, že Ti nie je ľahostajná vyžratá pamäť a rýchlosť requestu, ale bez ďalších informácií by som povedal, že ide o predčasnú optimalizáciu.

S takýmito číslami môžeš mať stránku so stovkami miliónov pagehits mesačne aj na virtuálnom serveri. A keď už dosiahneš toľko pagehits, tak už by si mal mať plán ako na tom vygenerovať príjmy a z toho zaplatiť prenájom HW a linky.

[Evik]

No to si právě nemyslím, nevím teda jak s rychlostí ale ta paměť mi nedá spát. Když vezmu server se 1GB RAM, tak to znamená, že může načís stránku pouze < 2000 uživatelů, pak následuje asi pád hardware, nebo se pletu?

[Kit]

Pleteš. Běžně se na takový server nepouští víc než 50 uživatelů. Ostatní čekají ve frontě, až se vyřídí předchozí požadavky. Čím rychleji je server obslouží, tím dřív přijde řada na klienty ve frontě.

[Josef Kufner]

Ono to nakonec stejne škončí na tom, že server má jen několik málo jader, takže to moc uživatelů současně neodbaví. Nakonec je to o co nejrychlejším naplnění výstupního bufferu, aby script mohl skončit a nechal odeslání dat na http serveru, neboť tady už se čeká na klienta.

[Josef Kufner]

Nezapomeň započítat čas. Těch 2000 uživatelů musíš stihnout do těch 0.0009sec, neboť pak první script skončí a může se připojit další.

Pokud máš návštěvnost 1000 lidí denně při 50 zobrazených stránkách za návštěvu, je to v průměru 0.5 požadavků za sekundu. Při 1000 požadavcích za sekundu bys odbavil celou Evropu ještě před obědem.

Tady se dostává ke slovu pocit plynulosti a živosti webu, kdy je potřeba, aby uživatel měl novou stránku do cca 100ms od kliknutí na odkaz. Přičemž do cca 300ms je to v toleranci a neobtěžuje to. (zdroj)

[j]

Srv te odbavi za 0,00prd sekundy, a pak necha klienta, aby si postahoval 20MB js, a dalsich 50MB medii ... vysledek je ten, ze pak minutu cekas, nez vytimeoutuje nejaka smirovaci tecka, aby js milostive vygeneroval neco k zobrazeni, a kdyz js vypnes, nedockas se ani hlasky, ze to bez nej nefunguje.

[Kit]

Stačí vypnout JS třetích stran.

[Josef Kufner]

Např. Adblockem.

[Kit]

To je hezký čas i množství paměti.

Dva dotazy do databáze by čas zpracování zbytečně prodloužily a tím by zatížily paměť nejen PHP serveru, ale i databázového serveru.

[lertimir]

K tomu je dobré si uvědomit, že pokud donutíš v programu cokoliv k požadaveku na zatočení s diskem, tak jsi minimálně na čase 0,01-0,015sec tedy přibližně 10 více. Za to cca 1MB, který za cca 1ms zase z paměti vypadne nestojí.

[lertimir]

... přibližně 10 krát více.

[Evik]

pokud donutíš v programu cokoliv k požadaveku na zatočení s diskem, tak jsi minimálně na čase 0,01-0,015sec tedy přibližně 10 více.

To není pravda, pokud jsem tedy pochopil jak to myslíš...

[Josef Kufner]

Seek disku je přibližně 5 až 15ms. Pokud ukládáš soubor, vyžaduje to jeden seek na zápis dat a druhý na update inodu. Uzavření souboru čekná na potvrzení obojího.

Čtení je v pohodě, to zvládne VFS cache a disk se neroztáčí.

[Josef Kufner]

Jinak v podstatě jsou dva způsoby, jak aplikaci postavit.

"Push" je tak, že data jsou napřed připravena a potom je teprve jimi nakrmena šablona. Výhodou je, že před zahájením renderování máš vše nachystáno. Nevýhodou, že musíš vědět, co bude v šabloně potřeba, což lze častečně obejít tím, že šablony budeš konfigurovat spolu s připravou dat.

"Pull" je naopak, kdy šablona se spustí jako první a říká si, jaká data potřebuje. Tedy tahá si je ze zbytku aplikace sama. Výhodou je jednodušší návrh takové aplikace, kdy vlastě jdeš po stránkách vkládáš komponenty a ono už se to nějak vyrobí. Nevýhodou je, že data nejsou předem připravena, což komplikuje netriviální situace, kdy je potřeba reagovat, ale stránka je už z půlky vykreslena.

Většina framworků je typu "pull", neboť je tento koncept jednodušší na uchopení pro začátečníky. Oproti tomu bývá "push" komplikovanější, ale dá se s tím více kouzlit bez ošklivých hacků. Komplikovanost zde nespočívá v samotné aplikaci, tam to vyjde nastejno, ale ve vnitřnostech frameworku, neboť je potřeba to udělat správně a chyby v návrhu zde dokážou být velmi kruté.

[Evik]

Díky moc za objasnění, jsem asi nejblíže k typu "Push"

[Kit]

Nevím, kam bys zařadil můj způsob: Připravím si data a předhodím je šabloně. Šablona je řízena strukturou těchto dat. Podle tvé definice to asi bude "push".

[Josef Kufner]

Jo, to je typický push. Ta šablona musí být pružná či dynamicky skládaná z více částí, jinak by se to nedalo používat.

[Kit]

Ta šablona je řízená tokem a strukturou dat. Data mám ve stromu, pořadí sourozenců může a nemusí být významné. U seznamů typicky významné jsou, ale šablona si je může seřadit či jinak přeskládat.