Zrychlení nette (potrebuji co nejrychlejsi obslouzeni signalu)

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ší.

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

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 ;)

: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)

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é.

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 ;)

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

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

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 ;)