Razmišljao sam nešto, postoji li framework koji includa (“učitava”) samo klase/funkcije koje su potrebne za izvršavanje koda, a ne kompletni code sa svim klasama i funkcijama?
Recimo, sjećam se da je Visual basic svojedobno prilikom kompajliranja uzimao (tražio od tebe) koje komponente uključiti u aplikaciju kako bi aplikacija (.exe) bila što manja i brža za izvođenje.
Postoji li tako nešto i za php?
Zašto: evo kod live searcha ako koristim Larvel, prilikom searcha kompletni framework se mora pokrenuti da bi mi izbacilo riječ od (primjerice) 5 slova. Ako bih koristio samo neophodno (npr spajanje na bazu i jednu klasu za query koja bi vraćala json ili direktno iz nje ispisivao rezultat) bilo bi daleko brže.
Ako nema takvog frameworka, bogme bi ga trebalo počet radit
Već sam davao taj primjer, evo baci oko: http://dragutinmitrecic.from.hr
(to mi je testni server, nije site koji se koristi)
Gornje polje je live search koristeći Laravel
Donje polje je core (čisti) php
Baza je ista (i Laravel i core koriste istu bazu, ne repliciranu, već istu)
Pokušaj unijeti neki grad u Hr (recimo Zagreb) i gledaj (timeout za ajax request je složen u JS da se ne radi upit za svako uneseno slovo, iako i bez timeouta core php radi brzo i besprijekorno)
Eloquent je težak i najviše se osjeća benifit u brzini developmenta odnosno kad se očekuje da bi realno bilo par desetinki za rezultat u odnosu na pretragu baze.
Možeš probati sa DB klasom umjesto modela:
$users = DB::select('select * from users where active = ?', [1]);
return view('user.index', ['users' => $users]);
ORM jer sam htio izbjeći query builder (da budem “in”).
Mogao bih pokušati s db klasom (kao što @tpojka savjetuje) i query builderom.
Međutim pustimo sad taj live search, pitanje je bilo u svezi fw-a u kojem bih uključivao samo klase potrebne za neki zadatak gdje nije potreban cijeli fw da se load-a. Ok, možda je baš taj live search trenutno jedini primjer (gdje primjerice uopće nema potrebe da se, npr, loada kompletni view i blade templating engine)…
Ne osjeti se sada jer je taj timeout u JS-u riješio stvar da se ne osjeti toliko razlika, međutim vjeruj mi, osjetno je sporije prilikom izbacivanja rezultata. Prodiskutirali smo to na drugom topicu i došli do zaključka da je upravo zbog toga što se cijeli fw mora loadad da bi izbacio rezultat (što je i logično), za razliku od core-a koji ima jednu funkciju i jedan file za include-ad (db settings).
Zato bi bilo zgodno (zbog održavanja i zadržavanja iste logike kodiranja i sintakse) da se u takvim situacijama može loadad fw ali samo sa neophodnim klasama/funkcijama/logikom.
Ali samo neophodne stvari i jesu loadane, npr nije includan controller koji se ne koristi u runtimeu ili nesto sedmo iz frameworka sto se takodjer ne koristi.
Autoloadanje funkcionira na nacin da prvi put kad krenes koristiti klasu koja trenutno nije poznata engineu, PHP pogleda ima li registriran autoloader. Autoloader je zapravo samo skup definiranih pravila gdje PHP treba potraziti klasu u slucaju da mu vec nije poznata.
Dakle ako pokusas instancirati new Foo\Bar\Baz, a nisi ju rucno nigdje includao (sto ni ne bi trebao raditi), PHP ce prije nego eksplodira i baci ti gresku jos samo baciti oko ima li registriran autoloader (koji je samo skup pravila gdje potraziti klasu), i onda ce potraziti ju koristeci ta pravila.
Ako ju ne nadje, tad ce eksplodirati i vidjet ces tu gresku jasno.
Ako ju nadje, includa ju i skripta ide dalje. Ako jos negdje zatim pokusas instancirati new Foo\Bar\Baz, vise ju ne mora autoloadati jer ju je vec loadao za vrijeme tog requesta.
Tako radi manje-vise svaki framework (tipa Symfony ili Yii, koji su industry standardi), tako da se nikad ni ne includa sve nego samo ono sto se i zove tijekom runtimea.
Ako tako funkcionira Fw tada je to dobro promišljeno - ali sporo. Ok, možda je orm (u slučaju gore spomenutog searcha) neadekvatno rješenje, pokušat ću db klasom i query builderom, možda je tu “problem”.
Ovo mozes potkrijepiti nekim benchmarkom ili samo po osjecaju govoris?
Rucno pisani SQL ce uvijek biti najbrzi jer ne zahtijeva niti jedan izvrseni statement vise kako bi se generirao SQL query (s obzirom da ga developer rucno napise), ali query builder ili Eloquent su takodjer poprilicno brzi i tocni u generiranju querya i pravilo bi trebalo biti da koristis Eloquent gdje god mozes (dev happiness i maintenance), a query builder ili pisanje sirovog SQLa tek kad su ti potrebne fakat one SQL optimizacije koje ne mozes postici kroz Eloquent.
S obzirom da je tvoj site u dev environmentu i nema uopce posjeta, tebe brzina ne bi trebala toliko muciti.
Ako ti je sve sporo a uopce nemas posjeta, tvoj problem lezi negdje drugdje a ne u frameworku. Zamisli tek kako bi ti bilo da imas puno posjeta?
Problem moze biti tvoj/aplikacijski kod, file I/O (primjerice ako si na shared serveru koji nema ni ssd niti koristis opcache, pa za ocekivati je da Laravelu u dev modu treba puno vise da loada sve potrebno sa filesystema i boota se), pa zatim i PHP verzija koju koristis kao i postavke (tipa ako imas xdebug ukljucen na serveru ili gro ekstenzija koje uopce ni ne koristis).
Uglavnom Laravel je brz i Eloquent je sasvim sigurno dovoljan da se jako brzo odvrti to sto pokusavas postici.
Poprilicno sam siguran da problem lezi drugdje, mozda cak i u ovim stvarima koje sam ranije naveo, samo se potrudi da istrazis to i nadjes bottleneck.
Brzina me muči upravo iz ovog drugog razloga “Zamisli tek kako bi ti bilo da imas puno posjeta”. Zamisli kako bi bilo tek sporo kada bi bilo posjeta.
Uglavnom, stavio sam 4 live searcha i maknuo JS timeout za upite prema aplikaciji (sada se request šalje za svako uneseno slovo) http://dragutinmitrecic.from.hr/
Prvi je ORM, drugi je DB::Query builder, treći je DB::Raw, četvrti je core.
Na početku svakog rezultata (u listi) je vrijeme u mikrosekundama, od početka izvođenja metode do isporuke JSON-a
Primjer postavljanja mjerenja:
public function search(Request $request)
{
$start = microtime(true);
$this->keyword=$request->query('find');
$this->searchCity();
$this->searchApartman();
$gradovi=$this->foundgrad;
$apartmani=$this->foundapartman;
return (response()->json(["gradovi"=>$gradovi,"apartmani"=>$apartmani, "time"=>(microtime(true) - $start)]));
}
sve metode su iste, samo je razlika u query-u.
Na core php file-u početak vremena je u samom početku datoteke (prva linija).
I lijepo se vidi da je ORM zaista i najsporiji.
Generalno, kompromisno rješenje bi bilo upravo kako je @tpojka izjavio -> DB::Raw (gledajući na brzinu izvođenja).
Nema bottlencka - sve je jednostavno i čisto. Jednostavan query, baza nevelika, čisti i jednostavan code (u principu ima samo taj jedan SearchController sa par čistih metoda za pretragu baze)
Mislim da bi bilo poprilično slično (ukol’ko se ne bi radilo o milionskoj pretrazi sa prometom od 100k/day, ali to su onda neke druge stvari).
Činjenica je da Eloquent treba tih par desetinki da inicijalizuje funkcije.
Ako želiš, možeš napraviti package ili helpers direktorijum i tamo postaviti vlastiti PDO (ili drugi) servis koji možeš pozivati iz controller-a (nisi osudjen na Eloquent) pa ga korisiti kad ti treba neko ekstra brzo rješenje poput tog AJAX-a. Onda samo importuj tu klasu u kontroler kad se ima potreba korisititi.
Isto postavi isLoading flag true sa interesantnim gif-om preko z-index-a pa ga skloni kad rezultati stignu. Manje bi smetalo očima - više smeta očima nego što ti je dugo za čekati.
Edit: pogled’o sam ponovo - razlika je manja od desetinke u najgorem slučaju. Ostavi tu mikrooptimizaciju za poslije. Jer je to nešto što treba sistemski odraditi ako se locira k’o takvo.
