Een zoekmachine bouwen #6 - Full page cache
13 juli 2018In de afgelopen periode heb ik de crawler een aantal keren opnieuw op moeten starten omdat er zaken fout gingen. Wat dat betekent, is dat er telkens dezelfde requests uitgevoerd moesten worden en er (ten opzichte van eerdere keren) weinig of geen nieuwe data binnenkomt. Daarom heb ik nu een full page cache gemaakt en heb ik de crawler nog één keer opnieuw opgestart.
Wat op zich aardige informatie is, is dat de crawler vastliep op websites die een URL parameter ?gi=xxxxxxxx hadden. Ongetwijfeld een of andere vorm van sessiebeheer in de URL, maar hij bleef telkens een nieuwe sessie genereren. Op zich prima, maar dat doet hij gepaard met een redirect. Daar ging dus even wat mis. Ik denk dat ik de betreffende websites iets meer belast heb dan aanvankelijk de bedoeling was.
Enfin. Inmiddels heb ik een totaal aantal van 556.257 .NL TLD's gevonden. In totaal staan er nu (volgens gegevens van maandag 9 juli) 5.810.726 in de zonefile. Feitelijk heb ik dus maar 9,6% van de .NL domeinnamen gevonden. Helaas heb ik bij de SIDN geen cijfers gevonden over de hoeveelheid domeinnamen die daadwerkelijk in gebruik zijn (dus geen placeholders e.d.), waardoor ik niet echt een goed beeld heb van hoe groot de prestatie nu eigenlijk is die ik geleverd heb.
De indexer
Door naar de belangrijker zaken. De indexer heeft een kleine update gehad. Het opslaan en verwerken van de phrases kostte veel tijd en ik begreep niet zo goed waarom. Later bleek dat hij meerdere malen dezelfde sets in de database probeerde te zetten, dus "laptop kopen" werd 5 keer gepoogd in de database te zetten wanneer dit ook 5 keer voor kwam op de pagina. Dit is natuurlijk onzin, dus dit heb ik uiteindelijk opgelost door in de software te kijken of de elementen in de array uniek waren. In één klap was de indexer 5 keer zo snel.
Uitbreiding zoekgebied
In eerste instantie heb ik geprobeerd om uitsluitend .nl TLD's te crawlen. Bijvoorbeeld voorbeeld.nl, maar niet subdomein.voorbeeld.nl.
Daarbij ben ik begonnen op startpagina.nl, heb ik een uitsluiting gemaakt voor *.startpagina.nl voor de domeinnamen en heb ik rustig afgewacht. In totaal kwamen er iets meer dan 300.000 domeinnamen naar voren, door alleen de homepages te crawlen van de betreffende sites die gevonden werden. Diverse "links" pagina's die je veelal op oudere websites ziet, zijn daarbij nog niet geindexeerd.
Omdat de crawler niets meer te doen had na die oorspronkelijke 300.000 domeinnamen, heb ik besloten de aparte "domain" tabel die ik gebruik voor het registreren van de losse TLD's, alsnog in de links tabel te gooien. Dat gaf hem weer 600.000 links voeding, waarna hij weer vrolijk doorging met crawlen.
Op het moment zijn er 983.995 domeinnamen gecrawld. (Op zich jammer, nét onder de miljoen.) Er moeten er nog 289.911 gecrawld worden, waarbij er als het goed is weer nieuwe links uit moeten komen.
Het aanleggen van de full page cache is belangrijk, omdat dit mij de mogelijkheid geeft om de indexer te tweaken en betere resultaten te laten geven. Als ik de basis voor elkaar heb, ga ik daarna aan de slag met machine learning om de resultaten verder te finetunen. Nog een hoop werk aan de winkel dus.
Maar voor nu. Mijn voorspelling luidt als volgt: al vóór hij de 2.000.000 pagina's bereikt, is de tabel met te indexeren pagina's leeg. En eigenlijk wordt het dan pas echt interessant :-) dan moet ik namelijk de websites "in".
MyISAM vs InnoDB, nog even uitwijden
Ik heb het wel eens eerder gehad over dat ik geen InnoDB wil gebruiken. Voor recht-toe-recht-aan zaken is MyISAM veel sneller en zeker wanneer je gebruik maakt van een SSD. Mijn theorie is dat table locking (zoals MyISAM dat doet) sneller is dan row-locking zoals in InnoDB, wanneer je op een SSD werkt. Ongeacht of dit waar is, InnoDB is zelfs met achterlijk grote caches en optimale instellingen, veel trager dan MyISAM. In ieder geval binnen dit project.
Het enige probleem waar ik (door de table-locking) mee kom te zitten, is dat de tabel af en toe bij heftige bewerkingen een tijdje op slot staat. Dit duurt nooit lang, maar het is zonde van de tijd. Omdat row-locking in verband met de performance in InnoDB geen optie is, is er maar één andere optie die ik nu zie: meer tabellen.
Wait time vanwege table locking is alleen een probleem wanneer er twee processen tegelijk in dezelfde tabel willen. Wanneer je zorgt dat ze niet allebei tegelijkertijd in die ene tabel willen zijn, heb je in feite het probleem opgelost. Met deze logica heb ik het systeem bedacht wat ik in deel 5 heb besproken.
Dat systeem wordt dus binnenkort ook ingebouwd. En dan domain authority en natuurlijk alle problemen die ik tegen ga komen bij het indexeren van hele websites. Gelukkig schrik ik niet zo snel van een uitdaging!
More to come...
Internet Marketing
Een zoekmachine bouwen #8 - PageRank, Zoeken, etc.Geplaatst op 5 december 2019
Een zoekmachine bouwen #7 - Backlinks & Tabellen
Geplaatst op 22 juli 2018
Een zoekmachine bouwen #6 - Full page cache
Geplaatst op 13 juli 2018
Een zoekmachine bouwen #5 - Een stap verder
Geplaatst op 11 juli 2018
Auteur: Edwin Dijk
TimeTick producten
Urenregistratie software
Gratis urenregistratie software