Performance index Lucene

Al lange tijd is de performance van onze index (Lucene) een hot item bij Seecr. De standaard performance van Lucene voor normale query’s en drilldown is prima. Maar over de performance van de join-functionaliteit zijn wij niet tevreden. Daarom zijn we al over gestapt op onze eigen manier van joinen, om de snelheid te kunnen garanderen. (Lees meer hierover in ons eerder verschenen artikel)

Het resultaat van onze eigen code werd vanaf het begin al gecached om het snel en acceptabel te maken. Zodra een gebruiker dezelfde zoekvraag opnieuw stelde stond het resultaat meteen klaar in de cache.

Naarmate we steeds meer records en gebruikers kregen, begonnen er wat problemen te ontstaan. De servers gebruikten meer geheugen en de query’s werden trager.  Een automatische refresh van al onze records instellen, zodat er elke vijf minuten nieuwe records geïndexeerd worden, zou het systeem nog trager maken. Dat kunnen we ons niet permitteren. Ik ben in de code gedoken om te achterhalen waarom het systeem op deze manier reageerde.

Compacter opslaan
Al snel ontdekte ik dat de caches die gemaakt worden voor onze eigen join-code veel geheugen gebruiken. Een goede oplossing hiervoor dacht ik te hebben gevonden in de vorm van compacter opslaan. Het gebruik ging voor één query van 300Mb naar 2Mb; een enorme verbetering. Maar helaas was de oplossing niet zo simpel. Sterker nog, de query’s leken hierdoor om de zoveel tijd nog trager dan dat ze al waren.

Wat bleek nu, het maken van de cache was erg veel duurder geworden. Vandaar dus dat de query’s soms nog trager waren. Tijdens een brainstorm met mijn collega’s werd het idee geopperd om het eens te testen zonder enige vorm van caching. Misschien was het verzamelen van alle gegevens wel zo snel dat het maken van een cache niet opweegt tegen die snelheid.

Dat vond ik het proberen waard. De code heb ik opnieuw geschreven en inderdaad, het verzamelen van alle gegevens was ook erg snel zonder caching. Toch was het niet voldoende om volledig zonder te kunnen.

Minder committen
Tot dit moment werd Lucene eens in de 1000 records of om de 10 seconden gecommit. Binnen maximaal zoveel seconden waren wijzigingen daardoor zichtbaar. Was dit misschien iets te veel van het goede? Zo belangrijk was het niet dat wijzigingen zichtbaar moesten worden. Records worden zelfs maar een paar keer in de zoveel tijd toegevoegd en zeker niet elke 10 seconden.

Daarom hebben we hier verandering in gebracht. We committen nog maar elke 5 minuten of elke 100.000 records. Dit had een positief resultaat; de query’s waren nog maar maximaal eens in de 5 minuten trager. De gebruiker merkte hier dus behoorlijk minder van.

Maar na een tijdje kwamen er klachten dat het systeem vaak traag reageerde. Eens in de 5 minuten committen is toch niet voldoende. Hier moest toch een goede oplossing voor zijn te vinden. Ik heb besloten om over te gaan om een andere vorm van caching. Eén waarin we simpelweg het eindresultaat van de join-query wordt bewaard. Deze vorm gebruikte weinig geheugen, maar moest wel elke keer alles opnieuw berekenen; dit tegenover de oude vorm die alleen het gewijzigde deel opnieuw berekende. Deze nieuwe caches konden dan ook na elke commit opnieuw gemaakt worden.

Nog steeds waren wie hiermee niet waar we wilden zijn. Doordat we zo weinig committen werden de commits uiteraard wat duurder. Tot onze verbazing gebeurde het dat dit tot wel 8 seconden kon duren. Veel te lang als de query daarop moet wachten. En als we onze automatische refresh aanzetten werden er elke vijf minuten records toegevoegd en bereikten we hier dus helemaal niets mee. Nog steeds was het om de 5 minuten veel te traag, ondanks dat we al zoveel geoptimaliseerd hadden. Een behoorlijke tegenvaller.

Multi threading
Het was lastig om ook dit nog op te lossen. We konden geen goede optimalisaties voor Lucene bedenken. Totdat ik ineens bedacht dat Lucene multi-threaded is. Dat ik daar niet eerder aan heb gedacht. Want zolang een record geïndexeerd wordt, kan er niet gezocht worden. Dit merk je uiteraard meteen als een commit 8 seconden duurt. Als ik dat nou eens kon veranderen.

Ons indexeer- en zoekproces heb ik gesplitst naar twee verschillende threads. Eén thread om te indexeren en de andere om te zoeken. Tijdens het indexeren is het nu ook mogelijk om te kunnen zoeken. Ook als de writer-thread 8 seconden staat te committen. Eindelijk leek het erop dat we weer een goede performance hebben behaald.

Dé oplossing
De processen gebruiken weer een normale hoeveelheid geheugen en door middel van ons monitoringsysteem kunnen we zien dat de responsetijden weer acceptabel zijn. In onderstaande grafiek is te zien wat het effect van de laatste verbetering was op onze productieomgeving. Deze grafiek toont de gemiddelde responsetijd. Duidelijk is te zien dat we 22 januari gereleased hebben. Alle hogere pieken, die veroorzaakt werden door die 8 seconden commit tijd, zijn verdwenen. Grafiek

Voor nu ben ik heel tevreden met deze oplossing. Al ben ik wel met een nieuw experiment gestart om te kijken of we hier nog meer uit kunnen halen dan nu al mogelijk is. Je kunt maar beter goed voorbereid zijn op eventuele veranderingen in gebruik.

WaaS 2.0 aansluiting op NBC+

Stichting Bibliotheek berichtte recent dat in de komende maanden de landelijke diensten volledig worden geïntegreerd in WaaS 2.0. Het gaat hierbij onder andere om de content en functionaliteiten op www.bibliotheek.nl: de pagina’s over e-books, jeugd, literatuur en WelkBoek. Ook wordt landelijk zoeken op basis van de NBC+ opgeleverd.

Hiermee wordt de door Seecr ontwikkelde zoekmachine de motor achter deze functies.

Voordelen aansluiting NBC+
De aansluiting van WaaS 2.0 op het Zoekplatform biedt tal van nieuwe mogelijkheden en functies. Naast bronnen zoals kranten, e-books en de consumentengids, worden ook alle lokale bronnen van bibliotheken opgenomen in het landelijk Zoekplatform en zullen er in de toekomst nog meer volgen, zoals bijvoorbeeld de Digitale Collectie.

Tegelijk komen ook centrale functies voor iedereen beschikbaar. Wat lokaal vaak niet mogelijk is, kan centraal wel worden geregeld. Denk bijvoorbeeld aan deduplicatie en het uniformeren van metadata. Het mooie is dat het dan over al deze bronnen heen gebeurt in plaats van binnen één collectie.

Uniformeren van auteurs
Een voorbeeld van een nieuwe functie is het uniformeren van auteurs en onderwerpen. Verschillende bronnen hebben vaak een eigen manier om te refereren aan auteurs. Op basis van de verzamelde gegevens, gaan wij de identifiers over dezelfde auteurs op elkaar afbeelden. We werken hierbij onder meer met Wikipedia, GTAA, NTA en Viaf. Al deze data is/wordt als Linked Open Data gepubliceerd.

Een analoog verhaal geldt voor onderwerpen of trefwoorden. Iedereen heeft zo zijn eigen classificatiesysteem, vaak meerdere binnen dezelfde collectie. Het verzamelen van de gegevens en het bij elkaar zoeken van de overeenkomsten is in volle gang. De planning is om in 2015 grote stappen te kunnen zetten.

Vooruitblik
Wij zijn enthousiast over de aansluiting van WaaS 2.0 op het NBC+. Een goed startpunt van een mooie doorontwikkeling van het Zoekplatform die het voor elke bibliotheek mogelijk maakt om het hele Nederlandse Erfgoed te relateren aan haar eigen collectie.

Meten is weten

Hoe snel is het systeem? Hoeveel bezoekers kunnen tegelijkertijd het systeem benaderen? Bij nieuwe systemen, maar ook bij systemen waar we veel veranderingen in aan hebben gebracht, voeren we een performance test uit. Een test om vast te stellen wat het prestatieniveau van het systeem is. En om inzicht te krijgen in het verschil tussen de actuele en vereiste responsetijden.

Verschillende manieren van testen
Het aantal queries per seconde en de responsetijd van de query zijn de belangrijkste gegevens voor ons. Om hiervan een realistisch beeld te krijgen, testen we dit bij een gemiddelde belasting, een piekbelasting en een overbelasting van het systeem. Hoeveel kan het systeem daadwerkelijk aan?

Een test doen we op de tiende seconde nauwkeurig. Hiervoor hebben wij een eigen programma ontwikkeld, zodat we er 100% zeker van zijn dat we betrouwbare resultaten kunnen presenteren.

Vertekend beeld
Een veel gemaakte fout is de performance test thuis uitvoeren of vanaf een plek met een snelle internetverbinding. Die test geeft vaak een vertekend beeld. Daarom testen wij altijd via onze server, om zo een netwerkverbinding uit te sluiten. Voor één van onze klanten bijvoorbeeld staat het systeem in Engeland. Zou je dit via een internetverbinding testen, dan kan het verlies  wel tot 300 ms per query zijn.

Gebruikerservaring
Een applicatie of website staat of valt met een goede performance. De grote datastromen, waar we vaak mee te maken hebben voor onze opdrachtgevers, mogen geen reden zijn voor een te traag systeem. Vaak voelen we wel aan of een systeem nog optimaal werkt. Maar voor de echte cijfers is het van belang om regelmatig een performance test uit te voeren. Wil je tevreden gebruikers, dan is het van belang dat de performance van het desbetreffende systeem optimaal is.

Agile – een manier van werken

Wij kiezen er bewust voor om agile te werken. Naast dat het uitdagend en leuk is, houdt het ons ook scherp en helpt het ons om continue te werken aan verbetering. Wij zien agile als een gedachtegoed, een verzameling van waardes die wij belangrijk vinden. We blijven continue nadenken of een bepaalde methode werkt.

De essentie van agile is dat je ervoor zorgt dat zaken relevant blijven. Concepten worden snel omgezet in resultaten. Het proces van ideevorming gaat gelijk op met software ontwikkeling. De focus komt hiermee te liggen op de resultaten.

Iteraties
Wij werken voornamelijk aan langlopende en grote projecten. Om ons te kunnen blijven focussen op resultaten delen we een project op in korte overzichtelijke periodes; ook wel iteraties genoemd. Elke iteratie is een miniatuurproject op zichzelf. Aan het einde van elke iteratie wordt er bruikbare software opgeleverd. Een groot voordeel van deze manier van werken is dat de klant direct feedback kan geven op de uitwerking van zijn ideeën.

Daarbij is bij langlopende en complexe projecten de kans groot dat gedurende het proces prioriteiten wijzigen door nieuwe inzichten en/of verschuivende doelstellingen. Doordat we nauw samenwerken met de klant, kunnen we hier eenvoudig op inspelen.

Pair programming
Naast nauwe samenwerking met de klant, werken we intern ook nauw samen. Om goedwerkende software op te kunnen leveren, vormen we bij elke stap een pair om samen te sparren én om te voorkomen dat er fouten worden gemaakt in de code. Door de goede synergie ontstaan er creatievere oplossingen en zijn we ook beter in staat om alternatieven te ontwikkelen.

Een manier van werken
Zolang Seecr bestaat werken we al agile. Voor ons is agile een prettige manier van werken omdat het veel flexibiliteit en snelle resultaten oplevert.

Wanneer je agile werkt loop je ook tegen uitdagingen aan. Daarom nemen we regelmatig deel aan agile-activiteiten om met andere agile-experts van gedachten te wisselen en elkaar te inspireren. Wil je meer weten over agile? Neem gerust contact met ons op. Wij raken over agile niet uitgepraat!

 

 

Deelname Hack-a-LOD

Afgelopen zaterdag vond in het Brabantse Veghel de Hack-a-LOD plaats. Een hackaton waar het allemaal draaide om het maken van toepassingen met Linked Open Data van onder andere de openbare bibliotheken. Deze Hack-a-LOD is onderdeel van het project Brabantse Collecties en Content. Voor meer informatie http://www.hackalod.com/.

De Nederlanse Bibliotheek Catalogus NBC+
De Nederlandse Bibliotheek Catalogus (NBC+) was hiervoor beschikbaar via de API en als ruwe data in RDF-vorm (en via sparql).  Beide technisch beschikbaar gemaakt door Seecr.  Tevens waren er verrijkingen toegevoegd door Roland Cornelissen van Metamatter.

Impressie op YouTube
Voor een korte impressie van de Hack-a-LOD, zie dit filmpje.

De catalogus en beschikbaarheid
Erik was als ‘kijker’ aanwezig en zag hoe veelal jonge mensen met de data aan de slag gingen.  De catalogus is daadwerkelijk door een team gebruikt om relevante informatie te vinden terwijl je onderweg bent.  Ze waren enigszins teleurgesteld.  Op de vraag waarom was het antwoord: “het is maar een catalogus”.  Ze bedoelden hiermee: “we vonden wel wat, maar we konden niet doorlinken, er staat alleen dat het er is”.

Het was te laat om ze te wijzen op het  NBC+ /available end-point helaas; dat had misschien in een deel van hun wensen voorzien. Het toont maar weer eens aan hoe belangrijk het is om daadwerkelijk links te geven, ook naar de inhoud zelf!