Weblabor

Nem értem, hogy miért. Akármelyik ügyféllel is beszélgetek, mindegyiknek ez az igénye, de még nekem is, ha valamilyen programot használok: legyen a lehető leggyorsabb. Ezt mondjuk nem forráskód szinten értem, sok minden befolyásolhatja a sebességet. De miért veszélyes?
Olyan egyszerű dolgok vannak, amelyek ugyan sokaknak nem jelent semmit, nem is tudják, de elméletileg gyorsítanak a futáson. Vegyünk pár példát.Bár nem okoskodni akarok, félre ne érts!!
A leglámaszintűbb példa: nem teszek for ciklus fejébe tömbelem számláló függvényt. Ezt Én inkább egyszer megteszem a cikluson kívül, és aztán ennek eredményét használom.
Vagy soha nem használom például a mysql_num_rows()-t, mysql_fetch_array()-t.Ez utóbbira nincs is szükségem általában, mivel a lekérdezéseimben alias-olom a mezőket. Ezzel is megspórolok valamennyit.Ezenkívül, mint mondottam volt, ami az adatokkal kapcsolatos, azt az adatbáziskezelőre bízom, ezért aztán tőle kérdezem le, hogy hány sort is kaptam vissza lekérdezésem eredményeképpen.

Ellemben azt is el kell ismernem, hogy vannak alkalmazásrészletek, amelyek a fenti képet felborítják, ugyanis nem szükségesek, de mindenképpen hasznosak abban a szellemben, ahogy Te mondod:


Ilyen például egy sql-t összeállító metódus, amely egy kapott tömbdimenziós tömb alapján összeállítja az adott sql-t, mondjuk egy keresésnél, vagy olyan helyen, ahol túl sok időt venne igénybe az előzetes leprogramozása a sok lehetőségnek. Ezzel a megoldással tulajdonképpen megspóroltam egy csomó fejlesztési időt, tökéletesen átlátható, viszont pluszként belekerült a kódba, amely nem kötelezőa futáshoz, de felettébb hasznos és kívánatos. Viszont ezt is úgy, hogy a lehető leggyorsabb legyen. Nem tudoksokat a kódoptimalizásálásról, hiszen ehhez nagyon kéne ismernem a php működését, de amit tudok, azt nem utólag javítom ki, hanem már eleve abban a szellemben végzem a munkámat. Nem hiszem, hogy ez vezsélyes fegyver lenne. Viszont kíváncsian várom, hogy szerinted miért az?


Maximálisan igazad van abban, hogy egy encoder használata is elegendő volna. Viszont egy extension írása mindig is vonzott. Mondjuk úgy, hogy számomra az lehetne a hab a tortán, ha megtudnék vele birkózni. Nem hiszem, hogy annyira rossz eszköz lenne, ha egyszer ugyanazt a célt szolgálja, csak más szinten. A tudás nem fog rosszul jönni, az egyszer biztos :))


Hát ha csak pár tíz darab funckció lenne, akkor nem is adnám ki a modulírási lehetőséget a kezemből. De hát mindegyik funkciót többféleképpen lehet megvalósítani, gondolok itt arra, hogy webszerverként nem egyedül az Apache van a világon. Egy funkciót nem egyetlen program lát el, ezt a felhasználó választja ki. Ha nme választhatja ki, akkor oda függetlenség. Márpedig ez is nagyon fontos szempont: a felhasználó döntsön, ne mi kényszerítsük bizonyos útra. De még ez se elég, hiszen egy funkciót többféleképpen lehet lekezelni, csak gondolj a hagyományos vagy virtuális levelezésre. Szóval sok kis apró részlet van, arról nem is szólva, hogy taníthatónak kell lennie a rendszernek. De ez még mindig nem lassít a futáson, hiszen ez is csak adminfelület. De mint mondtam, vannak olyan terveim (üzleti vonatkozásúak), amelyek erős forgalmat is generálhatnak a keretrendszerben: egyrészt az erős adatbázishasználat, másrészt a sok látogató, akik már nem adminfelületen tevénykedkednének, illetve nem adminfeladatokat látnának el. Erről nem szeretnék bővebben írni, mivel nem teljesen kiforrott, nem is speckóztam le, ráadásul azt sem akarom, hogy valaki ezt elolvassa, aztán a homlokára csapva maga is nekiálljon hasonló dolognak - ergo nem akarom, hogy megelőzzenek.


Az első igény, ami felmerült bennem, az a lámaszintű, biztonságos program, melynek segítségével a haverjaim és Én böngészőn keresztül tudjuk menedzselni a hosztjainkat illetve a szerver legfontosabb funkcióit. Erre nem akartam áldozni havi 20ezret (CPanel), ezért egy rendszergazda barátommal összeültünk, és összeütöttük az első verzsönt. Nekik amúgy egy nagyon komoly szerverhoszting cégük van a BIX-ben. Aztán még merültek fel igények, és tovább fejlesztettük. Meglett a kettes verzsön.
Azóta is ez fut, de mindig gyűltek az igények, a problémák, az ötletek, csak éppen idő nem volt rá. Nekem is voltak ötleteim a jövőre nézve, és úgy döntöttem, hogy egy olyan alkalmazást próbálok megfirkálni, amely nemzetközileg is megállja a helyét. Egyrészt referencia miatt, másrészt mert szükség van rá, sokrétű, és rugalmasan, könnyen bővíthető bárki által. Ezt az ötletet elég jól kidolgoztam, de valljuk be, hogy nem tartottam közvéleménykutatást. Viszont van nagyon sok ismerősöm ebben a szerveres világban, akik pont ilyenekkel foglalkoznak, és azért velük mindig konzultálok keresve újabb ötleteket.
Összegezve: amit elképzeltem, az ugyan kis szegmens fog át, ellenben megvan az esélyem, hogy hiányzó űrt tölt majd be. Arról nem is szólva, hogy ROI számítás szerint a SAJÁT MUNKÁM mindenképpen megfog térülni 100%-osan. Lehet, hogy nem azonnal, és nem azonnal anyagilag, sőt, lehet, hogy soha nem lesz anyagi vonzata, de erkölcsi haszonra mindenképpen számítok. Ha nem túl nagyképűség ilyenre vágyni.


Ez való igaz, de csak poénnak szántam. Annyira messze vagyok attól, hogy egyáltalán csak belekontárkodjak a kernelszintbe, hogy nem is gondolhatok ilyesmire mondjuk 2 éven belül. Viszont tudom, hogy mi lehetne a legjobb megoldás :))
Egyébként már működik a kettes számú webszerver is, rendesen pöcörög, egy csomó munkától kiméltem meg magam és feltételesen leendő modulírókat is.
Nem rootként fut, isten mentsen, de eltud látni root-os feladatokat, és ez a lényeg. Egyébként itt jött elő egy újabb ötlet: mennyire lehet idomítani a szerveroldalt, azaz ki döntse el, hogy a szerveroldal milyen jogokkal fut, mit tehet és mit nem? Ugye az alapkoncepció az volt, hogy root-ként, de hát ez gáz. És ne is Én döntsem el. Ezért aztán ezt rábízom arra, aki majd egyszer ezt ismeretlenü letölti és elkezdi a rendszer konfigurálását. ez legyen az Ő felelősége. Punktum :DD