Időzített futtatás cronból (sokszor)
Sziasztok,
Egy ideje fejlesztek php/mysql-ben egy rss olvasót, mert böngészőst szeretnék, de nem találtam olyat ami tetszene. Mindegy :)
A kód saját szerverről fut, hozzáférek mindenhez, tehát nem a környezet hátráltat.
Ez elképzelésem az volt (és ez is valósult meg), hogy a megadott rss fájlokat lementem lokális cachebe (sima filecachebe), majd onnan kiparseolom ami kell, azt mentem db-be.
Egyrészt lesz keresés, másrészt szerintem gyorsabb, mint mindig előszedni és kiparseolni, harmadrészt pedig a folytatólagosság is szempont.
Az rss fájlok ugye limittel vannak, ha egy hétig nem töltöm le, akkor kiesnek a régi bejegyzések. Mivel nem szeretnék ilyen lyukat, ezért fut a cron, ami letölti az rss fájlokat, és átrakja a db-be, amire szükségem van. Az utolsó 200 bejegyzést tartom meg, így lyuk sincs, és visszamenőlegesen is jó időre megvan minden.
A db-ben mentem, hogy mikor volt utoljára lekérve, a cron csak akkor tölti le, ha régebben mint 5 perc. Az oldal betöltéskor csak a db tartalmát jeleníti meg, nincs ilyenkor letöltés, mert erősen lassít, ha sok feedet kell feldolgozni. Az oldalak cachelve vannak, 5 perc után nyúl a db-hez.
A problémát ott látom, hogy több mint 100 feedet követek, és 5 perces a késleltetés. A cronos script úgy fut (percenként), hogy megnézi mennyi feed van összesen, ezt elosztja 5-el (esetünkben 100/5=20) és abban a percben 20 feedet kér le, és dolgoz fel (a lekérés random megy, tehát elméletben 5 perc alatt mind a 100 feed frissülni fog). Ez 100 feednél meg elmegy, de mondjuk 20 embernél fejenként 100 feeddel: 2000 feednél már percenként 400 lesz, ami gond. Persze ez a véglet, hogy mindenkinél más feed van.
Remélem nagyjából érthető.
5 perc szerintem még kibírható késleltetés. Hogy oldható meg, hogy nagyobb számú feednél is le tudjam kérni úgy hogy a szerver se dől össze? Vagy egyéb ötlet a megvalósításra? Nem mondom hogy ez a tökéletes megoldás, de jobb nem jutott eszembe.
A több vas alárakása egyelőre nem opció. A ráfutás kivédése meg van oldva. Ha nem fut le 1 perc alatt, nem indul rá a következő, van rá lockfile.
A lekérés file_get_contents-el lett megoldva 5 mp-es timeouttal.
Köszi.
■ Egy ideje fejlesztek php/mysql-ben egy rss olvasót, mert böngészőst szeretnék, de nem találtam olyat ami tetszene. Mindegy :)
A kód saját szerverről fut, hozzáférek mindenhez, tehát nem a környezet hátráltat.
Ez elképzelésem az volt (és ez is valósult meg), hogy a megadott rss fájlokat lementem lokális cachebe (sima filecachebe), majd onnan kiparseolom ami kell, azt mentem db-be.
Egyrészt lesz keresés, másrészt szerintem gyorsabb, mint mindig előszedni és kiparseolni, harmadrészt pedig a folytatólagosság is szempont.
Az rss fájlok ugye limittel vannak, ha egy hétig nem töltöm le, akkor kiesnek a régi bejegyzések. Mivel nem szeretnék ilyen lyukat, ezért fut a cron, ami letölti az rss fájlokat, és átrakja a db-be, amire szükségem van. Az utolsó 200 bejegyzést tartom meg, így lyuk sincs, és visszamenőlegesen is jó időre megvan minden.
A db-ben mentem, hogy mikor volt utoljára lekérve, a cron csak akkor tölti le, ha régebben mint 5 perc. Az oldal betöltéskor csak a db tartalmát jeleníti meg, nincs ilyenkor letöltés, mert erősen lassít, ha sok feedet kell feldolgozni. Az oldalak cachelve vannak, 5 perc után nyúl a db-hez.
A problémát ott látom, hogy több mint 100 feedet követek, és 5 perces a késleltetés. A cronos script úgy fut (percenként), hogy megnézi mennyi feed van összesen, ezt elosztja 5-el (esetünkben 100/5=20) és abban a percben 20 feedet kér le, és dolgoz fel (a lekérés random megy, tehát elméletben 5 perc alatt mind a 100 feed frissülni fog). Ez 100 feednél meg elmegy, de mondjuk 20 embernél fejenként 100 feeddel: 2000 feednél már percenként 400 lesz, ami gond. Persze ez a véglet, hogy mindenkinél más feed van.
Remélem nagyjából érthető.
5 perc szerintem még kibírható késleltetés. Hogy oldható meg, hogy nagyobb számú feednél is le tudjam kérni úgy hogy a szerver se dől össze? Vagy egyéb ötlet a megvalósításra? Nem mondom hogy ez a tökéletes megoldás, de jobb nem jutott eszembe.
A több vas alárakása egyelőre nem opció. A ráfutás kivédése meg van oldva. Ha nem fut le 1 perc alatt, nem indul rá a következő, van rá lockfile.
A lekérés file_get_contents-el lett megoldva 5 mp-es timeouttal.
Köszi.
Több szál :)
A db tábla ahol tárolja InnoDB, ami soronként lockol (gondolom írásnál is), ez elég lehet?
Nem egészen
ez lett
ttl
Minden feed-nek olvasd be a <ttl> értékét, amelyikben - ha szabványos (rss 2.0) a feed - megadják az ajánlott frissítési időt (sec.). Előfordulnak 1-2 órás ttl-ek is, ezeket felesleges 5 percenként frissíteni. Ha ez nem jó (sokszor rossz a ttl), akkor a legfrissebb <item> pubDate-jéből is megtudhatod, hogy kell-e db-be tenni, csinálhatsz saját frissítési statisztikát, hogy mit-milyen-sűrűn kell frissíteni.
Nem egészen értem az online rss-feldolgozást (ebben a formában), a Júzerek miért nem maguk iratkoznak fel a csatornákra?
A hírcsatornák más site-on való megjelenítése olyan, mint másik honlap tartalmának megjelenítése. Én nem bíznám a Júzerekre, hogy melyik rss jelenjen meg a honlapomon, mert némelyik "rss gazda" feltételekhez (pénzhez) köti az ilyen felhasználást.
Remélem hamarosan bővebben is olvashatsz itt rss feldolgozásról.
ttl legtöbbször nincs
Nem kell, csak kéne valami olyan intervallum, ami még nem megy a "minőség" kárára.
A ttl-re gondoltam én is, és szép hogy a szabványban benne van, csak éppen a fejlesztők felejtik el belerakni, meg amúgy is csak ajánlás, akárhogy frissülhet.
Megnéztem most pár rss-t amiket követek (blog.hu-s, tumblr-es) egyikben sincs ttl.
Nem a db-be rakással van a gond, hanem az rss lekérésével. Ha már lehúztam lokálra, akkor fel is dolgozom egyúttal.
Lehet hogy rosszul magyaráztam, ők iratkoznak fel természetesen.
Képzelj el egy netvibest vagy google readert, csak máshogy néz ki. Nem hírgyűjtő oldal, a saját csatornáidat látod.
Köszi a meglátásokat mindenesetre.
Óvatosan
Hú, lehet elkavartam! Bocs, de a netvibest vagy google readert én nem ismerem, mit tudnak többet, mint egy FF, vagy bármi böngésző?
Frissítés:
- Pl. ha lastBuildDate meg van adva, akkor két feed-ből pontos értéked lesz, a 10. után meg pláne.
- Ha nincs, akkor channel/pubDate-el u.ez, csak itt ellenőrizd, hogy ne a lekérés ideje legyen (ill. előbbinél is).
- Ha ez sem jó, akkor nézd meg az összes item idejét, és azokból (1 rss-en belül) számolj átlagot, az lesz a "te ttl-ed".
Mindenképp érdemes vmi ilyesmi stat-ot csinálnod, simán cron-nal be fog halni a szerver; mindegyik feed-nek más-más frissítési igénye van, de a túl sokat nem fogod tudni 5 percenként frissíteni. Érdemes a stat alapján a feed-eket leíró táblában tárolni a kövi frissítési időt, és a percenkénti(?) cron azokat kérdezze csak le, amelyiket már kell. A stat felügyeletével szerintem több erőforrást spórolsz, mint amibe kerül (az adatokat úgyis beolvasod, csak pár plussz feltétel).
Lehet, hogy te tudod, de előfordul olyan (magyar) feed is, aminek 900(!) bejegyzése van, és fél mega. Ezt is ellenőrizd, ilyen feed-et inkább ne is parse-olj.
hát
a netvibest vagy google readert én nem ismerem, mit tudnak többet, mint egy FF, vagy bármi böngésző
Az említett két oldal arról szól, hogy vannak feedjeid (az rss-ek linkje, ami publikus, már ahol van), azt a júzerek megadják ezeken az oldalakon, amik bizonyos időközönként (ami itt a dilemmám) leszedik a feedeket, a tartalmukat rendezik, és megjelenítik a júzernek emészthető formában.
Hogy mivel tudnak többet mint az FF? Az FF-ben az rss feed max. azért látszik, hogy ne egy odahányt xml-t láss (IE8 és alatta még ezt sem tudta, ott xmlként láttad).
Gondolom akkor nem használsz feed olvasókat, ha ezeket nem ismered.
Ezt az átlag számolást meggondolom, mert jobb ötletem perpill nekem sincs, de valami kéne. Ha van ttl belekötöm azt is. Ez még tarthatónak is tűnik.
Csak itt akkor lesz gond, ha egy feed nem frissül csak hetente 1x, kikalkulálok rá egy átlagot 1 hétre, aztán egyszercsak elkezd naponta frissülni :D Habár akkor az első új elemnél változik a generált ttl számom. Szerintem a max. napi 1 lekérés még így is tartható.
A 900 elemes feed durva, de le kell szednem, fél mega nem akkora méret, hogy ne bírná el a szerver.
Köszi az ötletelést, a ttl átlagot megrágom.
Igen is, nem is
Nemrég írtam egy Rss_reader-t, ami feldolgozza az RSS 2.0, RDF és Atom hírcsatornákat is, de még nem jelent meg a cikk. Nem mondom, hogy neked jó - nem feed-köteg feldolgozására találtam ki -, de ötletet talán adhat (majd).
Szerintem lehet
Ha a megjelentetőt érdekli az rss felől érkező forgalom, akkor a linkekre tesz mérőkódot (pl. analytics). Hírlevelekben is gyakran látom ezt a megoldást.
Az odahányt xml-t félreértettem, azt hittem az amit megjelenít ha direktbe betöltöd, de közben rájöttem, hogy a könyvjelzőkhöz is felvehető. De ez szerintem nagyon fapados. :|
Az RDF és Atom formátumot még nem kötöttem be, rss2 és rss0.92-el jól megy. A cikket majd megnézem ha megjelenik.
Mediabirodalom
offtopic - idő
nyári
úgyis mindjárt vissza kellene
hogy értelmesen is
lock-ot feed-enként csinálnám.
frissítő szkript meg úgy futna, hogy lekéri adatbázisból, hogy miknek kellene frissülnie, majd ezekre külön külön (másik szálban) elindítja a frissítő szkriptet.
ez az indítószkript akár terhelést is nézhetne és adott terhelés felett nem indítana több folyamatot.
szóval így szépen két kezelhető részre bontod a probléma megoldását.
egyelőre
Ha eljut a ráfutásig, akkor majd szétosztom több részre, és egyszerre fog több curl multithread feldolgozás elindulni. Ennek elvileg csak a szerver teljesítménye szab határt. Még egy ttl átlagot kéne számolni, és penge lenne.
Köszi az ötletelést.