ugrás a tartalomhoz

PHP kód optimalizálás

gtoma · 2007. Okt. 14. (V), 10.09
Sziasztok.

Rákerestem a neten erre a témára, de nem nagyon találtam "összesítő" leírást.

Van egy nagyobb rendszerem, és kicsit gyorsítani akarok a futásán. Amit eddig találtam az az, hogy a modulokat az ember olyan csoportokba gyüjtse, melyeket működnek úgy is, ha magukban egyedül includolják. Merthogy a sok include sajnos lassít.

Ezt meg is teszem.

Azonban lenne még egy kérdésem:
Jelenleg az sql lekérdezések nálam egy funkción keresztül futnak. Minden lekérdezés elött felépítem a kapcsolatot, és a végén lezárom a kapcsolatot.

De ugye 1 oldal megjelenítésénel lehet akár 10 lekérdezés is (vagy több).

Kérdésem: lehetséges, hogy a rendszert úgy kellene felépítenem, hogy a kód futása elött megnyitom a kapcsolatot, majd a legvégén zárom le csak?

Lenne ebből látható gyorsulás?

Előre is köszönöm a segítséget.

ui: bármilyen"gyoirsításra" vonatkozó tanácsot szívesen veszek!
 
1

Overkill

janoszen · 2007. Okt. 14. (V), 10.23
Miért nem építed föl az első lekérdezésnél a kapcsolatot és zárod le az utolsó után? Mármint még mindig kisebb az overhead ha egy pér tizedmásodpercig tovább marad nyitva a kapcsolat a kelleténél. Max addig van egy aktív kapcsolatot ami foglalja a lehetséges x kapcsolatból az egyiket, de ez nem szokott problémát jelenteni.

A mai gépeknél már akár több száz kapcsolat is lehet nyitva egyszerre, nem probléma. A kapcsolódás viszont konstans idővel jár, mert jelszót kell ellenőrizni, stb. Ergo érdemesebb az egy kapcsolat módszerét választani.

Ami az optimalizálást illeti, emberi erőforrásra optimalizálj első sorban. Ha mondjuk 0.1 másodperc helyett 0.3 másodperc alatt fut le a kód, viszont ettől 50%-kal hatékonyabb leszel, akkor ne gondolkozz. Egy új vas töredékrészébe kerül a fejlesztői munkaerőnek. (Nyilván nem lehet hogy 10 másodperc alatt fut le a kód, de nem kell ész nélkül optimalizálni.)
2

Köszi!

gtoma · 2007. Okt. 14. (V), 12.39
Köszönöm.

Egyébként azért áltam át az alkalmankénti kapcsolat nyitásra, mert tapasztaltam néha furcsa hibaüzenetet.

A következő történt: Felépítettem a mysql kapcsolatot, és nem zártam mondván: a kód lefutása után magától zár.
De megtörtént olyan, hogy mondjuk 100 esetból egyszer hibaüzenetet írt ki: nem tud kapcsolodni az adtbázishoz. frissítettél és jó volt. aztán 100 oldaletöltésig semmi, majd megint 1x...

Én ezt annak tudtam be, hogy talán a háttérben fut még a kód, nem zárta a kapcsolatot, és "összeakadt". persze lehet, hogy ez hülyeség. Így aztán átáltam arra, hogy mindig zárom, aztán ha megint kell sql, akkor nyitom.

szerk.: Najó, ha nagyon tényszerű akarok lenni: fogalmam nem volt miért írja ki, így valamire megpróbáltam ráfogni :D
3

Kapcsolatok

janoszen · 2007. Okt. 14. (V), 15.18
Amit érdemes megnézni, kapcsolatok száma (van-e elég), phpmyadminból a kapcsolódott kliensek (pl ha pconnectet használsz, akkor ott fog figyelni a háttérben egy csomó idle kapcsolat), tárolt eljárások (ha ilyeneket használsz, MySQLi a barátod), stb.

Millió oka lehet, érdemes loggoltatni a mysql hibákat és a queryket aztán majd kiderül.
4

Pár optimalizálási tipp

Dualon · 2007. Okt. 14. (V), 15.57
A kódoptimalizálás helyett egy picit tágabb értelemben pár tipp:

  • DB connect: lehetőleg futásonként egyszer
  • DB query-k összeolvasztása (klasszikus eset, amikor 10 sor insertje helyett egyetlen insertként is benyomható valami)
  • Kimenet tömörítése (PHP 4.0.4 felett ob_get_level()==0 esetén ob_start('ob_gzhandler')), ha sávszélre optimalizálsz
  • Állományműveletek számának minimalizálása (lehető legkevesebbszer nyisd pl.). Itt utalnék proclub megközelítésére: ha átláthatóbb, kényelmesebb lesz az állománystruktúrád, kisebb állományokat kapsz, stb., akkor inkább include-olj többször...
  • Célspecificitás: elnagyolva, általánosságban igaz, hogy a mindentudó lassú, a specifikus gyors. Érdemes úgy kialakítani az általános, újrahasznosítható kódrészleteid is, hogy ne rögtön mindent akarj bele, hanem szépen kiegészítsd a felmerülő igények szerint (a monstre objektumszörnyek pl. nyilván lassabbak lesznek az adott célra kialakítottaknál). Az előrelátó tervezést azért ne dobd el. :)
  • Többször használt, de ugyanazon részletek gyűjtése. Például ha egy ciklusban többször is lefutna ugyanaz a függvény ugyanazzal a paraméterezéssel, akkor érdemes a cikluson kívül egyszer változóba gyűjteni a kimenetét.


Általában érdemes arra gondolni, hogy mi az a minimális szükséglet, amit épp használsz.

Én azt szoktam csinálni, hogy a rendszerbe afféle checkpointokat építek, ezek rögzítése (pl. sessionbe) egyetlen központi változóval kapcsolható. DB connect, core init, modulok indítása, modulok fontosabb lépései, lezárások, template-ek feldolgozása, kimenet, stb. Fejlesztésnél időnként átkapcsolom az egész rendszert ilyen "diagnosztikus módba", és minden oldallekérés után kapok egy mikroszekundumos időkkel, valamint futási paraméterekkel jellemzett listát. Döbbenetes élmény volt, mikor először láttam magam előtt a rendszer minden porcikájának működését ms-ra lebontva... komplexebb cuccnál ráadásul így redundás működésekre, a kelleténél többször járatott utakra is egy pillanat alatt fény derül.

Szóval az ultimate tanács: gondolkodj elegáns kódban! :) Egy idő után úgyis ösztönössé válnak az apró trükkök... pont ezért hirtelen "csak" a fentiek jutottak eszembe. :)
5

Debugger

janoszen · 2007. Okt. 14. (V), 16.06
Nagyon hasznos lehet egy debugger berendezése is, mert akkor látod magad előtt a kód futását, lépésről lépésre. Az oldalamon ott a leírás hozzá.
7

inkább profiler

Hodicska Gergely · 2007. Okt. 14. (V), 16.23
Erre a célra inkább egy profilerre van szükség.


Üdv,
Felhő
6

profiling

Hodicska Gergely · 2007. Okt. 14. (V), 16.18
Mielőtt nekiállnál optimalizálni előbb vizsgáld meg az alkalmazásod. Pl. XDebug segítségével tudsz profile-t készíteni. Ha átnézed ennek az eredményét, akkor már tudni fogod, hogy melyek azok a pontok az alkalmazásodban, ahol túl sok időt tölt el, ezeken a helyeken érdemes optimalizálnod.

Include téma: nem egyértelmű amit írsz. Ha nincsen opcode cache a rendszerben, akkor pont a lazy loading, amivel spórolni tudsz (tehát csak akkor töltöd be a fálokat, amikor ténzlegesen szükség van rájuk). Ha van opcode cahce, akkor már érdemes azt csinálnod, hogy a gyakran használt fájlokat beteszed egy fájlba, és azt include-olod. Persze opcode cache nélkül is igaz az, hogy ha több fájl tartalmára mindig együtt van szükséged, akkor érdemes őket egy fájlban tárolni. (Megteheted azt is, hogy csinálsz egy build fájlt, ami deploy előtt elkészíti ezeket a gyűjtő fájlokat).

Kapcsolódás: ez így biztosan elég rossz megoldás. Kapcsolódj az első parancs kiadásakor, majd az utolsónál bezárhatod.


Üdv,
Felhő
8

Huha!

gtoma · 2007. Okt. 16. (K), 16.20
Sziasztok! sok dolgot írtatok. Pár dolgot nem is értek, de akkor most "elrágódom" a témán.

Megnézem azokat a dolgokat amiket nem tudok, és átnézem amit ajánlottatok.

Köszönöm szépen.
Sokat segítettetek!
9

Nekem az a gondom, hogy nem

atomjani · 2014. Jan. 30. (Cs), 17.59
Nekem az a gondom, hogy nem férek hozzá az ssh-hoz. Csak perl nyelven van ilyen profile vagy php script formájában is van? CPanelem van.
10

???

Poetro · 2014. Jan. 30. (Cs), 18.41
Ezt most milyen célból és kinek írtad? A kérdező valószínűleg az utóbbi 6-7 éveben már túllendült ezen a problémán (ugyanis a kérdés 2007-es) ráadásul sehol sem volt szó SSH-ról.
11

Attól még aktuális lehet. Az

atomjani · 2014. Jan. 31. (P), 11.17
Attól még aktuális lehet.
Az ilyen profiler cuccról volt szó, ami segítht optimalizálni. Na itt olyanokat ajánlottak, amit csak ssh-án keresztül lehet telepíteni és használni.
Minek nyissak új témát, ha erősen kötödik az én problémám is a témához? Itt merültek fel a dolgok, így magától értetődő volt, hogy ide írjak.
12

Saját gépen

Poetro · 2014. Jan. 31. (P), 11.20
A profilert futtathatod saját gépen is, és akkor nem kell SSH sem. Vagy egy olyan szolgáltatóhoz mész, ami vagy a neked elérhető profilert vagy pedig SSH hozzáférést.