3.3. Teljesítmény- és erőforráskérdések

A rendszert a következő működési elvek alapján tervezem: a kiszolgálón futó program időnként beszerzi a figyelendő oldalakat; detektálja a változást (vagy annak hiányát); szükség esetén elkészíti az RSS csatorna bejegyzéseit. Ezen bejegyzéseket erre vonatkozó kérés esetén RSS formájában kiszolgálja a kliens aggregátora felé. Új hírek esetén az aggregátor értesíti a felhasználót.

Az algoritmus látszólag egyszerű, viszont figyelni kell arra, hogy hatékony is legyen, hiszen szélsőséges esetben nem csak a tartalomfigyelő rendszer terhelhető túl, hanem a figyelt weblapokat kiszolgáló szerverek is. Válaszként a megfigyelt rendszerek gazdái ki is tilthatják a változásfigyelő rendszert DoS (Denial of Service) támadásra hivatkozva, ezzel lehetetlenné téve az oldal további figyelését. Emiatt mindenképp szükséges egy egészséges minimális periódusidő meghatározása, amelynél nagyobb gyakorisággal egy URL biztosan nem lesz kétszer letöltve, akárhány felhasználó figyeli is azt. Az egyszerű egész értéket tartalmazó beállítás helyett egy szabálylista létrehozását is érdemes megfontolni, amellyel tetszés szerinti URL-re, vagy azok egy csoportjára egyedi periódusidőket állíthat be a rendszer adminisztrátora.

Az előbbiekkel szemben állnak a felhasználók igényei, akik minél hamarabb szeretnének értesülni a változásokról. Számukra másodpercenkénti, vagy mindenképp másodpercekben mért ellenőrzés lenne az ideális. A kis frissítési időköz a figyelt szervernek sávszélesség- és erőforrásproblémákat okozhat, ami kliensoldali megoldás esetén hatványozottan jelentkezik.

Szerveroldali megoldást választva, és a felhasználók számára ilyen szolgáltatást nyújtva gondolhatunk arra, hogy ha több felhasználó is ugyanazt az oldalt figyeli akkor is csak egy kérést indítsunk a célszerverre, majd ebből generáljuk minden felhasználó számára a csatorna bejegyzéseit. Lehetőséget adhatunk arra is, hogy a felhasználók megosszák egymással a figyelt weboldalakról készült csatornákat, ezzel még inkább növelve a gyorsítótárként viselkedő alkalmazás hatékonyságát.

Megjegyzendő, hogy utóbbi esetekben a tartalomfigyelő rendszer is lehet a szűk keresztmetszet, ha a felhasználók túl gyakran érdeklődnek az esetleges frissítések felől. Ez azonban kezelhető (skálázással, minimális frissítési időköz előírásával stb.), ellentétben a figyelt rendszerekkel, melyekre várhatóan nem lesz ilyen hatásunk.

Optimalizáció szempontjából még két dolgot szükséges megjegyezni: Az első a hibák kezelése. A hibát adó URL-ek figyelésekor hasznos az Ethernet hálózatoknál már jól bevált exponenciális visszalépéses algoritmusoz hasonló eljárás használata ([4]). Az egymás után fellépő hibák esetén mindig növelünk egy n számlálót, a következő oldallekérést pedig xn-nel arányos idővel későbbre időzítjük, ahol x∈ℝ, x>1.

A második, a beágyazott objektumok (képek, flash animációk, külső stíluslapok és JavaScript fájlok) kezelése. Ezeket indokolatlanul ne kérjük el a szervertől, az érdemi változás valószínűleg a HTML kódban fog megjelenni.

Tartalom átvétel