Printable View
Sziasztok!
Arra lennék kiváncsi ti tapasztaltatok e már hasonlót vagy esetleg valamiféle megoldást is találtatok a problémára.
Szóval a problémám.
Osztott tárhelyen üzemeltetek egy zend keretrendszerben fejlesztett oldalt.
Minden kérés az index php re van irányítva raktunk vele időmérést általában 0,2 másodpercig fut az index php.
De amikor este elindul a napi mentés 5-10 másodpercig is fut az index php.
Sőtt néha napközben is előfordul a lassulás.
Előre is köszönöm a segítségeket!
Meg is válaszoltad: osztott tárhely - napi mentés : Belassulás.
Nem egyedi eset.
Nem véletlenül, hogy például este lassul be az oldal. Akkor neteznek a legtöbben, így a tárhelyen levő oldalakat egyszerre sokan böngészik. Ez pedig belassítja a te lapodat is.
Szerintem inkább a napi mentés lesz a gáz. Az este tippre nem 20 órát jelent most, hanem mondjuk éjfél vagy hajnali 1-2, akkor esedékesebb a mentés. De lehet, hogy rosszul tippelem, akkor meg ügyetlenül csinálja a szolgáltató.Idézet:
Botond eredeti hozzászólása
Sziasztok!
Köszönöm a válaszokat.
Ti is ilyen mértékű lassulásokat tapasztaltok? (10/0,2 = 50x)
Tudtok olyan tárhely szolgáltatót ahol később (hajnali 2-3) indítják a napi mentést vagy alacsonyabb prioritással fut (nem vagyok szakértő;)?
(Eddig 2 szolgáltató 3 szerverén teszteltem az oldalt ez a legjobb eset amit megírtam a másik két szerveren sokkal rosszabbak voltak az eredmények)
A legtöbb szolgáltató éjjel futtatja vagy hajnalban. Én pl. a Viacomnál vagyok, és olyan reggel 6-8 órakor futnak ezek a mentések. Még soha nem éreztem lassulást emiatt a reggeli órákban.
A másik eshetőség, hogy külön megkéred a szolgáltatót, hogy időzítse máskorra, szerintem nem nagy kaland. És ők is jól járnak vele.
Igen, sajnos meg is válaszoltad....
Érdemes olyan tárhelyet bérelni, ahol biztosítva vann garantáltan az erőforrás, tehát VPS-t
Engedd meg, hogy picit pontosítsak: nem minden VPS esetén garantált az erőforrás!
Osztott kerneles megoldások esetén inkább felső korlátokról beszélhetünk, mint inkább garantált erőforrásról, a hardware virtualizációs technológiáknál esetén sem minden megoldás támogatja a poolok ilyen jellegű finomhangolását, illetve a garantált erőforrások megadását.
A szóban forgó oldal esetén egyébként jellemzően sok fileművelet történik, ami például a mi esetünkben, ahol terheléseloszott webkiszolgálókkal és központi tárolással dolgozunk igen nagy hátrányt tud okozni; oldalbetöltésenként átlagosan 300-350ms. Ez a késedelem abból adódik, hogy az alkalmazott keretrendszer gyakorlatilag úgy csipegeti össze magát sok létező és nemlétező fileból, így a végeredmény az, hogy körülbelül 80-100ezer lstat műveletet hajt végre, ami nem okoz gondot, ha a filerendszer a memóriában, a gyorsítótárban van, de jóval több műveletet igényel ha meg kell arról győződni, hogy adott erőforrás időközben nem-e változott meg egy másik node miatt. Átlagos oldalak esetén ez egyébként nem okoz problémát, viszont jelenesetben kikötés az, hogy minden oldalletöltés ha jól emlélszem 800ms alatt legyen. Az eredeti probléma alapján pedig, a jelenlegi szolgáltatója esetén, amikor elindul a backup, a memória gyorsítótárban a régi inode bejegyzések helyét átveszik az éppen frissen bekerülők, ami szintén az lstat lassulását okozza. Meglepő, de nem biztos, hogy ezt a problémát egy SSD háttértár alapvetően képes megoldani, mert a késedelem jó része kernel szinten jelentkezik.
A biztos megoldás egyébként valóban a VPS lehet, egy nem közös kerneles megoldással, ahol a futó kernel a szükséges inode cachet az idők végezetéig a memóriában tarthatja, illetve jóval könnyebben optimalizálható az oldalra. Költséghatékonyabb megoldásként pedig érdemes körbenézni, tesztelni, mert előfordulhat olyan szolgáltató, ahol a kritiréumok teljesülnek, de nem szabad arra építeni, hogy ez így is marad! ;)
Idézet:
alberthangert eredeti hozzászólása