Jeg er blevet kontaktet af en webhotel ejer, der fortalte at ZookaBot fik en af hans server til at gå ned. Det beklager jeg dybt, og jeg da også smidt alt hvad jeg har i hænderne for at finde årsagen.

Jeg opdagede desværre først beskeden i dag, selv om den var sendt for 6 dage siden. Jeg har optimeret en hel del på koden der kører ZookaBot, således den performer. Men, hvis det betyder at den kan ligge en hel server ned, står det ligesom skrevet i neon at det på ingen måde er acceptabelt. 

Den ZookaBot der bruges til ren crawling, har derfor ”stuearrest” til jeg få analyseret problemstillingen – andet kan jeg ikke tillade mig.

Jeg har valgt at lade ZookaBot til syndikering kører videre, for at udelukke at den del også skaber problemer. Men hvis den gør det, send mig en mail via kontakt formen her på bloggen – den mail ryger direkte i min mail boks.

Udviklingen med at implementerer realtime systemet i Zooka skrider fremad. Om det så gør det i et rimeligt tempo, ville være en overdrivelse. Det går praktisktalt langsomt lige nu. Ikke fordi jeg skyder fra hoften når det gælder nyudvikling og bare prøver mig frem – det kan man også engang i mellem, bare man er klar over konsekvensen - mere fordi jeg går med livrem og seler lige nu.

Dem der har fulgt lidt med på twitter.com/ZookaDK har sikkert bemærket at det gik både op og ned. Faktisk mangler der lidt før trin 1 et helt komplet. Zooka er stort system fordelt på mange maskiner, og det kræver fuldt fokus at opdaterer så meget på én gang.

Og ved i hvad, den klassiske fejl viste sit grimme ansigt. En simpel konfiguration fil manglede at blive opdateret, hvilket resulteret i et systemnedbrud på én time, indtil jeg fik lokaliseret den - Jeg må få bygget noget automatisk deploy snart!

Jeg er kommet frem til at en fuld implementering bliver lidt som en tretrins raket. Først og fremmest skal hele backend delen opdateres, således den kan håndtere syndikations data og ikke bare ekkoer fra Zookabots normale runder.

Det system der kontrollerer Zookabots runder, skal derfor til at opererer med to spor. Det store spor håndterer praktisk talt alle sites som Zooka kender – ligge et site der, tager det lang tid før ændringer ses.

Det lille spor vil være realtime sporet. For at forebygge at et site besøges mere end en gang på en runde, må samme site derfor aldrig eksistere i begge spor samtidig. Men et site der befinder sig i det lille spor kan praktisk talt godt besøges flere gange, selv om det store spor ikke er fuldført.

Hvordan bliver et site så flyttet til realtime sporet?

For at kickstarte realtime systemet vil samtlige sites der ligger i det store spor vil blive løbet igennem, og har et site bare skyggen af et feed bliver det overført med det samme. Bemærk dette sker kun én gang, via en specialbygget applikation til formålet.

Zooka tror på at alle sites med et xml feed opdaterer deres indholdet jævnligt. Derfor simuleres der et globalt system ping 1 gang i døgnet. Dette vil sende Zookabot af sted mod samtlige feeds i systemet – 406.489 lige nu.

For at give Zookabot et beslutnings mandat, har den feed informationer med i bagagen om den pågældende URL. Hvis der er tilføjet nyt indhold som kan aflæses i et eller flere feeds, vil Zookabot på baggrund af historikken omkring opdateringsfrekvensen, anmode om flytning af domænet til realtime sporet, eller tilbage til det sløve spor, hvis der ikke sker øjensynlige ændringer i en periode. Derefter overdrages det nye feed til syndikations systemet.

Et ping er derimod en sikker vinder her, det vil følge samme metodik som et system ping men Zookabot behøver ikke her, at anmode om noget som helst, for den er der allerede i realtime sporet før Zookabot sendes af sted.

Ved en logfil analyse vil dette mønster snart vise sig i en nær fremtid.