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. 
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.