Téma: Dinamikus oldal futtatása környezet nélkül

És velem, helyes megfejtővel mi lesz? Én kapok valamit? Vagy nekem is egyes?

Annyit fűznék hozzá, hogy létezik több javascript-et szerver oldalon használó rendszer is, freeswitch a neve az egyiknek, az más kérdés, hogy ki a franc programozgat szerver oldalon js-ben, mikor vannak rendesebb nyelvek is.

Viszont a terhelés megosztásra azért léteznek ennél praktikusabb és elterjedtebb megoldások is, ha már a szerver terhelés kérdése szóba került.

Azt viszont egyáltalán nem értem, hogy a g miért szeretné a statikus html oldalakat jobban, mint a dinamikusan generáltakat, mikor a dinamikusak folyamatosan bővölő tartalmat adnak nekik, a statikusokkal szemben. Szerintem egy statikus oldalnak igencsak relevánsnak és öregnek kell lennie, hogy jó helyre kerüljön, míg egy dinamikus, naponta bővülő oldalnak szinte issza a szavait a bot.

a fentebb irt peldara igaz amit szg irt. it szo sincs redundanciarol. ugyanazt a feladatot amit egy helyen is meg lehet oldani itt ketton kell.

Nem így van.

Ha a html -t kiszolgáló szerver hal meg, meghalt az oldal userek felőli elérhetőse, ez igaz, viszont az adataid a generátor szerveren megvannak bárhova, könnyen átirányíthatod a domaint, és a tartalmat újra generálod.

Ha a generátor szerver hal meg, akkor a felhasználók ebből nem látnak semmit, max azt, hogy nem frissül az oldal.

Régebben az index.hu kiszolgálása történt hasonló módszerrel, de pár éve a szerkesztőségi rendszer cseréjekor ezt megváltoztatták, hogy több lehetőséget kapjanak az interakcióra a felhasználókkal.

Ugyan akkor az ötlet maga nem egy elvetendő dolog, de a mai világban, amikor a felhasználóknak belépési, testre szabási lehetőséget kínál a legtöbb portál nagyon nehéz alkalmazni.

Amikor a livejasmin fejlesztését csináltam, és hirtelen megnőtt a terhelés a weboldalon ott csináltunk olyat, hogy cronból generáltuk 10 mp-énként a 20 leggyakrabban látogatott oldalt, és a kiszolgálás annyi volt összesen, hogy cookie kezelés, file_get_contenst, echo. ugyan akkor a belépet felhasználókat külön domainre kellett irányítani, hogy a generált lapok helyett már a saját egyedi oldalukat lássák.

Azonban ez a módszer olyan szintű weblap tervezést, és látogatottságot feltételez, ami még közepes méretű site-oknál sem kifizetődő. Ugyanis a szerver relative olcsó a képzett programozó idejéhez mérten. Egy programozó ugyanis mondjuk egy cégnek havonta kerül 500e forintjába. (ne felejdük a cég sokkal többet fizet egy ember után mint amit az ember megkap). Egy 2x quadcore Xeon szerver jelen pillanatban ugyan ennyibe kerül. Tehát ha több mint 1 hónapba kerül lefejleszteni egy programozónak egy egyedi rendszert, hogy az ember spóroljon 1 szervert akkor már határ esetté válik a dolog gazdasági megtérülése. Ezért jelen pillanatban nem látom értelmét egy ilyen rendszer fejlesztésének / üzemeltetésének. Pláne úgy, hogy a legtöbb (90% + ) webhosting cég valamilyen dinamikus nyelv futtatását már lehetővé teszi a tárhelyén. A splash page-ek minél több helyre való szétszórását és azok frissitését pedig sokkal egyszerűbb úgy megcsinálni, hogy az adott oldal egy központi site-ról rss-ből húzza a tartalmat, nem pedig egyessével generálod őket.