Weboldal optimalizálás, Cache kezelés, Kevesebb HTTP kérés, stb...

Indította NevemSenki, 2012 november 22, 01:12:11 DÉLUTÁN

Előző téma - Következő téma

NevemSenki



Úgy gondolom, hogy a weboldalak optimalizálása ( gyorsítása ) megér egy új témát.
Az interneten barangolva, Magyar nyelvű leírás kevés található, ha van is akkor is csak részleges.
A weboldalunk optimalizálása, gyorsítása akkor válik fontossá, ha


  • Tartozik hozzá adatbázis, sok a lekérdezés, és nagy az adatbázis.
  • Sok felhasználó használja az oldalt.

Ebben az esetben ugye nő az oldal betöltésének ideje, ami elég gyorsan másodpercek fölé ugrik, sőt, több 10 másodperc is lehet.
Én amiket eddig olvastam, és meg is értettem, az leírnám nektek.
Az egyik a képek optimalizálása lenne. Azt olvastam erről, hogy van egy jó eljárás, amivel csökkenthetjük a kéréseket. Mégpedig úgy, ha használatba vesszük a Css által biztosított background-image és background-position tulajdonságokat.
A másik dolog pedig, hogy több kis képet, egy nagy képpé állítunk össze, majd megadjuk hogy nekünk konkrétan melyik része kéne. Ezzel csökkentjük A HTTP kérések számát. Mert igaz, a kép egy kicsit nagyobb lesz, de viszont csak egy alkalommal kell betölteni. És ha mondjuk 10 kép van külön külön az 10 HTTP kérés, ha pedig az a 10 kép 1 képbe van zsúfolva, az már csak 1 HTTP kérés.
Erről itt találtok egy leírást.
Ha pedig a Css-ben még nem vagy nagyon otthon, akkor pedig itt nézz körül előtte.

A másik dolog amit olvastam, az az oldalba épített JavaScript-ekről szólt. Ha megnézzük például a jquery-1.8.3.min.js-t, láthatjuk, hogy az egész kód be van tömörítve. Magyarul nincs tagolva. Ki vannak gyomlálva a szóközök, az új sor karakterek ( \n ).
Ez is gyorsítja a betöltést.
( Ebben a JavaScript-ben pedig tagolva láthatjuk a kódot. Csak hogy lássuk a különbséget. )

Ez szintúgy igaz a fentebb említett Css fájlokra is. Sokat segíthet ha kigyomláljuk belőle a felesleges szóközöket, és a felesleges sorokat. Ezekre található program is, kisebb scriptek, amik elvégzik ezt a beavatkozást helyettünk. Vigyázzunk, mert nem mindig végeznek jó munkát. Erősen ajánlott a biztonsági mentés.

Következő az adatbázishoz kapcsolódna. Több fórumon említették, hogy a mysql kapcsolat folyamatos életben tartása sokat gyorsíthat. Mert így nem kell újra és újra kapcsolódni, ami ugye növelné a betöltési időt. ( Válaszidő. )
Egy példa:
Az oldaladra, a legelső beInclude-olt fájlodban, csatlakozol az adatbázishoz. A többi fájl amit betöltesz, akár Include alapon, tartalmaznak különféle MySql utasításokat, lekérdezéseket, Update-eket, Isert-eket. Nem kell minden alkalommal, mikor az adatbázisból olvasol, vagy módosítasz valamit, újracsatlakozni. Elég csak azt a csatlakozást alkalmazni, és majd a legutolsó beInclude-olt fájlodban lezárni a MySql kapcsolatot.

Van még ez a Cache megoldás is, amit még nem sikerült elsajátítanom, de vannak itt rajtam kívül sokan, aki ebben jártasabbak, esetleg használják, vagy ami még jobb, építettek weboldalt ami ezt is tartalmazta.
TPL sablonok, nagyon kevés információt találtam róla Magyar nyelven, ez segítheti az oldal optimalizást, ha igen akkor miért, és hogyan tudjuk használni? ( Smarty? )
Aki tud erről bővebb információkat, az írja le.
Jöhetnek tapasztalatok, példák a megvalósításra, minden ami ehhez kapcsolódik.

Üdv.: Senki
http://www.tutorial.hu/?s=Smarty+sablonkezel%C5%91+rendszer
Csak a Puffin ad neked erőt, és mindent lebíró akaratot!

NevemSenki

Gondoltam kicsit utánanézek a Smarty rendszernek, meg is tettem, de nem jutottam eredményre.
Zerus is ajánlotta a Smatry-t, de a baj ott van hogy sok dolgot olvastam róla.
Elsősorban azt, hogy nem sok értelme van. Több ember, aki weboldalakkal foglalkozik, azt vallja, hogy nem sok értelme van.
Azzal kontráznak rá erre, hogy a Smarty által külön lehet választani magát a sablont, és a php és egyéb kódokat.
Kicsit bepróbáltam a Smarty-t, igaz, frankón kezeli a sablonokat, a cache rendszer is benne van a sablonkezelő részben. Ez eddig jó.
Összefutottam egy ismerősömmel, aki egyetemi tanár. Ő nem foglalt állást, de viszont mondott még egy jó dolgot. Mégpedig azt, hogy ha a Smarty segítségével építem fel az egészet, akkor lényegesen kevesebb karakterből fog állni ugyan azon funkció. Mondjuk ami PHP-ben 40 karakter, az Smarty által lecsökken 17-re.... ez csak egy példa.
Ez megint egy + pont, de akkor most minden egyes részt írjak át más syntaxok szerint, konkrétabban a Smarty által megkövetelt syntaxok szerint? Akkor a + mellé itt van a - is.

Valaki aki már programozott vele, és nélküle is, az valószínűleg jobban látja a különbséget.
Írhatna pár szót.

Vagy akinek van erről véleménye, mondjuk az is írjon, mert lehet hogy tök jó meg minden... csak én nem látom nagyon értelmét..

Üdv.: Senki
Csak a Puffin ad neked erőt, és mindent lebíró akaratot!

zerus

Idézetet írta: NevemSenki Dátum 2012 december 18, 10:46:11 DÉLUTÁN
Elsősorban azt, hogy nem sok értelme van. Több ember, aki weboldalakkal foglalkozik, azt vallja, hogy nem sok értelme van.
Azzal kontráznak rá erre, hogy a Smarty által külön lehet választani magát a sablont, és a php és egyéb kódokat.

Pont ez a lényege, célja. Így szebb kódot kapunk, mert a html nem kavarodik a php-vel, ebből adódóan átláthatóbb a rendszer.

Idézetet írta: NevemSenki Dátum 2012 december 18, 10:46:11 DÉLUTÁN
Mondjuk ami PHP-ben 40 karakter, az Smarty által lecsökken 17-re.... ez csak egy példa.

Ennek nem hiszem hogy lenne bármi valóság alapja. Egyébként egyetemi tanárokkal kapcsolatos tapasztalatom, hogy a php-n kívül mást nem ismernek. (tehát fingjuk sincs hogy milyen keretrendszerek léteznek php-hez)

Idézetet írta: NevemSenki Dátum 2012 december 18, 10:46:11 DÉLUTÁN
de akkor most minden egyes részt írjak át más syntaxok szerint, konkrétabban a Smarty által megkövetelt syntaxok szerint? Akkor a + mellé itt van a - is.

Nem hiszem hogy ezért mínuszt érdemelne. Hiszen nem a Smarty hibája hogy te egy már meglévő rendszert átírsz.

NevemSenki

Idézetet írta: zerus Dátum 2012 december 19, 12:39:25 DÉLUTÁN


Idézetet írta: NevemSenki Dátum 2012 december 18, 10:46:11 DÉLUTÁN
de akkor most minden egyes részt írjak át más syntaxok szerint, konkrétabban a Smarty által megkövetelt syntaxok szerint? Akkor a + mellé itt van a - is.

Nem hiszem hogy ezért mínuszt érdemelne. Hiszen nem a Smarty hibája hogy te egy már meglévő rendszert átírsz.

Oké, tegyük fel, hogy az egészet Smarty-ban kezdem el írni. Mivel már úgy nagy vonalakban tudom hogy mit hogy kéne megcsinálni, és ezt PHP syntaxok szerint meg is tudom valósítani, de mindez nem elég, mert nem PHP syntaxok szerint kell, hanem Smarty syntaxok szerint. Igazából az egész PHP nyelvből, csak a logika marad meg, a kivitelezés ( maga a kódírás ) teljesen megváltozik.

Mivel a programozási nyelvek logikája eléggé hasonló, csak más syntaxok szerint kell írni ( ez egy erős példa ), ezért ez most majdnem úgy jön ki, mintha egy másik nyelvet kezdenék alkalmazni, amit újra meg kell tanulnom egy bizonyos szintig, hogy haladni is tudjak a dologgal.

Ezért kapta a [ - ]-t, nem másért. 

Például én sokszor használom a [ while ] ciklust. Nem tudom, de ha ez a ciklus létezik ( de lehet csak a for ciklus van Smarty-ban ) akkor most vagy nem tudom használni a jól megszokott [ while ] parancsot, és helyette [ for ] kell, vagy marad a [ while ] csak éppen egész másként néz ki.

Nem tudom hogy érthetően írtam-e le a gondolataimat, úgy nagyjából érthető hogy mi a problémám vele?

Üdv.: Senki
Csak a Puffin ad neked erőt, és mindent lebíró akaratot!

Shyro

Nem tudom aktuális e még, de a az adatbázis kapcsolatok terén nem igazán értek egyet azzal amit leírtál. PHP/MySQL - t elsősorban webfejlesztésnél tessék elfelejteni, függetlenül attól, hogy mennyien azt használják. PHP - ban ha jól tudom (5.5 ide vagy oda) minden egyes beérkező kérésre újra lefordul a kód, így amit mondok, az PHP - ban nem is kivitelezhető.
Tranzakciókezelés. Ennek a fogalomnak érdemes utána járni. Úgy szokás, hogy megírnak egy programot, ami ül a szerver memóriában és elvégzi a trancakciókezelést. Bejön egy kérés, ami tartalmaz egy INSERT utasítást, avagy bejön egy kérés, ami alapján a szerver oldal elkészíti az INSERT utasítást. Megnyit az előzőleg említett programunk egy adatbáziskapcsolatot, generálódik egy azonosító, amivel az adatbázisunk elfogadja az INSERTünket. Mi a helyzet, ha egyszerre 10, 100, 1000 kérés jön be? Ezekkel mind foglalkoznunk kell. Ez a tranzakciókezelés.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

NevemSenki

IdézÚgy szokás, hogy megírnak egy programot, ami ül a szerver memóriában és elvégzi a trancakciókezelést.

Érdekesnek találtam amit írtál. Ezen dolgokban nem én vagyok a legjobb, sőt...
Ha megkérlek írnál egy kicsit többet a fentebb idézett mechanizmusról?

Üdv.: Senki
Csak a Puffin ad neked erőt, és mindent lebíró akaratot!

Shyro

Persze.

Az adatbázis kapcsolatot nem úgy érdemes elképzelni, hogyha az nyitva van, akkor folyik a csap. Általános esetben, amikor nyílik egy adatbázis kapcsolat, egy azonosító generálódik, amivel már lehet szólni az adatbázisnak.

Úgy kell megoldani a történetet, hogy első sorban van egy BROKER programod, fut a szerveren, benn ül a memóriában. Ez fogja lekezelni az adatbázis műveleteket. Beérkezik a klienshez egy kérés, azt a szerver oldali program feldolgozza. Ha a kérés tartalmaz adatbázis műveletet, fordulunk a BROKER - hez, ami egy szabad adatbázis kapcsolaton kereszül lekezeli a kérést. Mondjuk 10 adatbázis kapcsolatra van beállítva, de lehetne 1000 - re is állítva! Ha egyszerre 10 adatbázis műveletet végrehajtó kérés érkezik, a BROKER kiossza nekik a 10 adatbázis kapcsolatot. Ha 11, akkor 10 darabot kioszt, és amíg azok szüttyögnek 1 adatbázis művelet várakozik, míg fel nem szabadul egy adatbázis kapcsolat. Mikor szabadul fel? Commit után, miután megtörtént az adatbázisban történt módosítás, és mindenki látja. Megkapja az a +1 kérés az elsőnek felszabadult adatbázis kapcsolatot és végrehajtja. Mindezt a BROKER kezeli le.

Elméleti szinten ezt így érdemes megoldani.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

NevemSenki

Elkezdte ez az egész elég erőteljesen foglalkoztatni a gondolataimat.
Én még nem láttam ilyen rendszert.
Esetlegesen valahol az interneten találhatóak példák egy ilyen agy hasonló dolog kivitelezésére?
Hogyan próbáljak meg rákeresni?
Szeretném megérteni, és átlátni egy ilyen rendszer működését.

Üdv.: Senki
Csak a Puffin ad neked erőt, és mindent lebíró akaratot!

Shyro

#8
Rendben. A másik topic - ban írtam, hogy "szinte már minden van mindenhez". Ezt itt is el lehetne sütni. A BROKER elnevezést azért írtam, mert nekem is ezzel prezentálták a dolgot. Említettem, hogy PHP - ban ezt nem lehet megírni, ezért én ragaszkodnék most a Java - hoz.

Java - hoz van egy JDBC nevű API, amivel lelehet bonyolítani az adatbázis kapcsolatokat. Ez egy általános API, drivereket használ. Ennél jobb leírást nem hiszem, hogy találsz, ezt tudom javasolni.

Erre az API - ra kellene épülnie alapvetően annak a programodnak, ami lekezeli mindazt, amit fentebb leírtam. Itt jön képbe a BROKER. (Nem fog működni az oldalon található link, viszont itt megtalálod.)
Ez a DBConnectionBroker a JDBC - re épül, OracleDriver - t használ, azaz Oracle Database - hez lesz jó. Meg van írba benne az a fajta tranzakciókezelés amit fentebb leírtam, csak használni kell. Ha mondjuk Java - ban akarsz MySQL - hez csatlakozni, akkor ugyanúgy használhatsz JDBC - t, persze valami MySQL - hez írt driverrel, és ahhoz is valószínüleg fogsz találni egy hasonló osztályt, mint a BROKER.

Néhány, egymástól független gondolat:
(1) Amint látod, bonyolult dolog ez, főként, mert sok, nagy témát érint. Adatbázisok működésétől kezdve egészen a programtervezésen át a hálózatokig. Mindegyikre sok-sok időt rá lehetne szánni, míg kellőképpen átlátja az ember, és használható tudássá érik. Sajnos, az informatika pontosan az a szakma, ahol mindent nem lehet tudni. Így, én azt javaslom, hogy egy általános, biztos tudást kell felépíteni a szoftverfejlesztés tudományából (én is ezt csinálom) és amikor találkozol egy technológiával, megoldással, stb. csak annyit mondasz: "Ja, hogy ezt így is meg lehet oldani!". Ez lenne a járható út.
(2) Az egészben a csúnya az, hogy a weboldalak sok helyen még mindig közvetlen mezei *.php fájlba írt adatbázis kapcsolatokkal akarnak operálni, amikor pl. a Brokert már 2002 - ben megírták a Stanford - on.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

NevemSenki

Köszönöm a választ.
Egyetértek a lentebb írt utolsó két ponttal.
Kicsit tanulmányozom a dolgokat.
Még egyszer köszönöm.

Üdv.: Senki
Csak a Puffin ad neked erőt, és mindent lebíró akaratot!

Powered by EzPortal