Zrychlení nette (potrebuji co nejrychlejsi obslouzeni signalu)

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Coura
Člen | 18
+
0
-

Zdravím,
snažím se zrychlit provedení signálu, provádí se přes AJAX každou vteřinu, takže potřebuju opravdu co nejkratší čas. Zatím mám cca 100ms, pokud použiju čistý php bez nette jsem na 25ms. Zjistil jsem že nejvíce času trvá načtení nette konkrétně
require LIBS_DIR . '/Nette/loader.php'; a to 35ms

používám minified verzy, nejde to ještě nějak urychlit? Nechci používat skripty mimo nette, je z toho prasečina, ale pokud se mi to nepodari zrychlit, asi mic nic jinyho nezbyde…

diky za rady

Lopata
Člen | 139
+
0
-

Jsi si jistý, že potřebuješ takhle časté requesty, jaká je situace?
Nechceš-li používat skripty mimo Nette, jak jsi sám napsal, je třeba se podívat co ještě konzumuje čas.
Jsou to například databázové dotazy,… Co se přesně děje?

P.S. Minified verzy z vlastních zkušeností nemohu doporučit.

Patrik Votoček
Člen | 2221
+
0
-

pokud potřebuješ doopravdy rychlé zpracování scriptů nepoužívej PHP. Pokud potřebuješ rychlé zpracování scriptů v PHP nepoužívej Framework ani žádné jiné knihovny ale nativní PHP. 100ms je hodně dobrý čas (o moc lepší už to nebude).

Btw na serveru bývají scripty díky accelerátorům většinou ještě rychlejší.

Coura
Člen | 18
+
0
-

Jedná se o aukce viz třeba licituj.cz, takže bohužel jsou nutné.
Db botazy zaberou: 5–10ms

Nacteni configu: 4ms

Routy: 5ms

$application->run();: 35ms

Z toho vychází že největším žroutem je právě to načtení knihoven…

Zkoušel jsem tam vrátit normální verzy nette a sice se čas načtení knihoven zlepšil o cca 20ms, ale celkovej čas se zhoršil o 10ms… Všechny hodnoty jsou ze serveru…

iguana007
Člen | 970
+
0
-

No a co pouzit toto: http://www.ape-project.org/ ?

blacksun
Člen | 177
+
0
-

iguana007 napsal(a):

No a co pouzit toto: http://www.ape-project.org/ ?

To vypadá hodně zajímavě, díky za tip, na to se určitě někdy mrknu. Poslední dobou mám ale dost silný pocit, že nestíhám sledovat ani to, co bych chtěl, natož objevovat něco nového…

odin
Člen | 50
+
0
-

Coura napsal(a):
Db botazy zaberou: 5–10ms
Nacteni configu: 4ms
Routy: 5ms
$application->run();: 35ms
Z toho vychází že největším žroutem je právě to načtení knihoven…

Vrele doporucuju merit celkovy cas pozadavku (tj vcetne DNS, HTTP connect, HTTP transfer, render) a merit to na vzdalenem a zatizenem serveru. Vyrizeni HTTP pozadavku na obycejnem serverhostingu Apache+PHP+Mysql zarucene za min jak 1s je naprosta utopie (nerikam, ze se to obcas nepovede, ale pri zatezi to rozhodne nejde zarucit). V tomto kontextu je optimalizace 35ms vcelku nezajimava. Realita pri zatezi bude takova, ze pokud posle na server nekolik desitek klientu pozadavky s odstupem 1s, tak se system (coz je vse od weboveho klienta az po webovy server vcetne vsech veci mezi tim) lehounce zahlti a vyridi je v uplne jinem poradi v case 0–20s. Cili chce to uplne jinou technologii, jiny pristup, nepouzivat framework, nepouzivat Apache, nepouzivat PHP, atd…

PS. verze bez verze jako ruze bez ruze → minified VERZI (sorry, ale fakt me z toho boli oci, kdyz to vidim ;)

Coura
Člen | 18
+
0
-

iguana007: diky, podivam se na to

odin: je mi jasny, ze pri zatezi to bude uplne jinak… sorry za chyby, zmatl me prispevek od Lopaty, sem myslel ze to mam dobre :)

Editoval Coura (8. 7. 2010 12:02)

danik
Člen | 56
+
0
-

:o) uplne to same jsem resil taky, stejny use case. Pokud na to nemas nekolik dedikovanych serveru, zapomen na to. Zalezi samozrejme na navstevnosti a aktivite uzivatelu na tom serveru, ale muzes se uz s malym poctem uzivatelu dostat na silene casy a snadno vytvoris velky average load na serveru. K tomu musis pocitat s tim, ze ten server bude dostavat pri velke navstevnosti kapky i bez toho, pokud jde o pocet requestu, protoze kazdy request na stranku ti vyusti v X dalsich requestu na staticka data (css, obrazky, ..), takze pokud to nemas rozmistene na nejakem cdn (mimochodem – doporucuji zkusit – http://www.coralcdn.org ), realne mas na Xkrat vic requestu na server za sekundu nez navstev.

Zkousel jsem jit cestou server-side pushingu (ble, to zni hrozne) – myslim ze to je neco podobneho tomu Ape Projectu o kterem psal Iguana – konkretne misto abys posilal request kazdou vterinu (a 99% requestu ti pouze vratilo „zadna zmena“), posles si request jeden a na serveru v PHP si ho „podrzis“ – budes v cyklu kontrolovat v modelu zmenu ktera te zajima a chvilku spat, a az kdyz ta zmena prijde, vytvoris JSON odpoved a posles ji zpatky klientovi. Ten s ni neco udela a posle si novej request. Tady zase vznikne pri urcity navstevnosti toho webu problem s tim, ze na serveru bud dojdou apache handlery (prilis mnoho otevrenejch http requestu) nebo dojdou filedeskriptory (prilis mnoho otevrenejch souboru – pocitaj se uplne vsechny, ty co naincludujes, configy, logy, cache etc – nebo prilis mnoho spojeni do db atp). Uz se to ale da resit docela hezcejc – treba si potrebny data pri jejich zmene ulozis primo v JSON do nejakyho souboru a serverova strana tvoji javascriptovy kontroly uz pak bude volat jenom malinkej php skriptik, kterej dostane jako parametr v GETu timestamp posledni klientem evidovany zmeny dat a bude v cyklu kontrolovat mtime toho souboru proti tomu timestampu a chvilku spat a kdyz zjisti, ze byl soubor upravenej, umre a vypise jeho obsah nebo tak.. tam ti odpadne zpracovavani celyho frameworku, odpadne ti pripojeni do db, hafo otevrenejch souboru etc – ale porad se muze stat ze nebudes mit dost apache handleru… pak by bylo mozny ten php kontrolni skript mit umistenej na vic ruznejch serverech etc..
:o)

Coura
Člen | 18
+
0
-

danik: To není špatnej nápad, ale jde poslat na server více požadavků ve stejný čas? Pokud se nemýlím, tak když zadržím request v nějakým cyklu a uživatel bude např. chtít na jinou stránku nebo třeba hlasovat v anketě, tak musí počkat až se dokončí první požadavek, tím se vlastně vše zablokuje a nebude fungovat ani přihazování…

Nebo existuje nějaká metoda pro neblokující request?

na1k
Člen | 288
+
0
-

Taky jsem dělal naprosto stejný web (založený na stejném systému) a skončil jsem u holého php bez knihoven nebo frameworku. Když to celé dobře navrhneš, tak to je dost použitelné.

LuKo
Člen | 113
+
0
-

Řeším podobný typ úlohy – zobrazení pohybu vozidla na mapě podle GPS. První nápad bylo udělat skript, který každou vteřinu generuje statický soubor. Tam jsem to ale udělal nějak blbě a server vracel 206 – partial content. Než abych to nějak řešil, udělal jsem jednoduchoučká skriptík mimo Nette. Ostatně na echo json_encode(dibi::query('SELECT ...')->fetchAll()); nepotřebuji načítat celé Nette. Nyní FireBug hlásí 20–30 ms na celý požadavek (GET+generování+stažení). Pokud to nebude postačovat, udělám to bez dibi nebo rovnou v Pythonu. App pro práci nad databází samozřejmě tvořím v Nette.

Coura
Člen | 18
+
0
-

Tady je to horsi ze ja prave potrebuju kontrolovat jestli je uzivatel prihlasenej… predavat si to jako parametr nepripada v uvahu a do session z nete se asi jinak nez nactenim knihoven nedostanu… Podarilo se mi to stahnout na 70ms… A bude to mit pro sebe celej server, tak to snad utahne ;)

LuKo
Člen | 113
+
0
-

Zkoušel jsi zobrazit obsah proměnné $_SESSION? Nedá se tam vykoukat, jak z toho vyčíst přihlášení uživatele?

Zkoušel jsi nějakou cache, např. eAccelerator nebo APC?

Editoval LuKo (11. 7. 2010 22:12)

newPOPE
Člen | 648
+
0
-

Coura napsal(a):

Tady je to horsi ze ja prave potrebuju kontrolovat jestli je uzivatel prihlasenej… predavat si to jako parametr nepripada v uvahu a do session z nete se asi jinak nez nactenim knihoven nedostanu… Podarilo se mi to stahnout na 70ms… A bude to mit pro sebe celej server, tak to snad utahne ;)

cez $_SESSION to urcite ide, uz som to pred casom riesil. Nette tam ma len nejaky zvlastny prefix nieco ako __N, ked si to dumpnes urcite to v $_SESSION najdes

danik
Člen | 56
+
0
-

Coura: no jde to, ale prave ze to prestane jit v momente kdy mas na ten server tech pozadavku moc.. presny cislo je zavisly na konfiguraci a je vysoky, ale na tohle nestacilo…

Mimochodem APC je fakt dobra vec, na rychlost frameworku o mnoha souborech k nezaplaceni…

… da se pouzit i jako uber rychla kes pro php promenne… :o)

Coura
Člen | 18
+
0
-

LuKo: jop, eAccelerator… o par desetinek se to zlepsilo…

marek.dusek
Člen | 99
+
0
-

Mozna OT, ale pouziva nekdo eAccelerator v produkci na necem realnem? At to zkusim kdykoli (jakoze parkrat do roka s nejakou dalsi verzi), po par hodinach az dnech server lehne (resp. child proces, ktery se sam restartne). Pokud ano, zajimala by me konfigurace (os, server, php, …)

odin
Člen | 50
+
0
-

marek.dusek napsal(a):

Mozna OT, ale pouziva nekdo eAccelerator v produkci na necem realnem? At to zkusim kdykoli (jakoze parkrat do roka s nejakou dalsi verzi), po par hodinach az dnech server lehne (resp. child proces, ktery se sam restartne). Pokud ano, zajimala by me konfigurace (os, server, php, …)

My to mame vyresene graceful restartem apache asi kazdych 5hodin. Puvodne to vzniklo kuvli nejakemu memleaku v PHP 5.0.x, ale fakt, ze toto „preventivni opatreni“ resi spoustu problemu ;)