MEMO. De database server zit op piekmomenten aan een heel hoog CPU gebruik:

Transcriptie

1 From Didier Adriaensen To VVV Date CC 17/6/2014 Ref Subject Performantie SearchAPI en database. (deel 2) 1. Vaststellingen De database server zit op piekmomenten aan een heel hoog CPU gebruik: De pieken zijn in de grafiek afgevlakt omdat deze over langere periode bekenen wordt. Het is dus geen continu hoog cpu gebruik maar hoog bij zware belastingen. Deze zware belastingen kan zowel aantal queries zijn als complexiteit van de queries. 1/5 Performantie SearchAPI en database: deel 2

2 datum sec0_1 sec1_2 sec2_3 sec3_4 sec4_5 sec5_10 plus10sec totaal Analyse de verdeling van het cpu gebruik overdag op de database server is als volgt (voor het uitvoeren van queries) 64%: searchapi 23%: findcommonproperties 8%: fillcaches daarnaast is er een groot stuk van het cpu gebruik te wijten het parsen en compileren van de queries door sql server, het gedeelte dus voor het uitvoeren van de query. Voor het uitvoeren van sommige queries duurt het langer om de query te parsen en compileren dan om het resultaat te bepalen. Ik zag bv al parse en compilatie tijden van 2 seconden waarbij het effectief uitvoeren van de query dan nog 1 seconden duurde. Ik stel voor om in eerste instantie vooral op de searchapi en op het parsen en compileren van queries in te zetten. Daarnaast kunnen we nog een beperkte tijd steken in het opvullen van de caches. Naast cpu gebruik zien we ook een een groot gebruik van de tempdb. Dit is bv van belang voor sorteringen in queries. Dit heeft op zich minder directe impact op cpu usage maar als dit meer in geheugen kan gebeuren zijn de queries sneller uit het systeem en verbetert de overal response tijd. 2/5 Performantie SearchAPI en database: deel 2

3 3. Oplossingen 3.1. SearchAPI queries Reeds uitgevoerd Op release is reeds een hotfix opgeleverd welke momenteel op de Productie omgeving staat met een aantal verbeteringen aan de opbouw van de searchapi queries. Instelbaarheid van de query timeout (staat nu op 15 seconden ipv 30) Instelbaarheid van hoeveel % van de requests doorgelaten worden (heeft geen invloed op de performantie maar is eerder een noodprocedure om ervoor te kunnen zorgen dan het systeem er niet volledig doorgaat onder de load) Verbetering van de listview queries, deze halen nu enkel de id s van de events op en halen de data voor de listview xml uit de blobs. Dit omdat SQL Server soms voor tussenresultaten al alle data ging ophalen hoewel er misschien maar 10 records uiteindelijk uit de query zouden komen. Ik heb tevens een hint toegevoegd die de freetext queries versnelt Nog uit te voeren Door de trage queries eruit te filteren en daar steeksproef gewijze manuele optimalisaties en analyses op te doen kom ik tot volgende verbeterpunten: Toevoegen extra tabel met betrekking tot types We zien vaak in de logging volgende queries: [trcitemtype(includechildren(catid)):2] (Alle items die onder de boom Zien,Doen&Beleven vallen). Wanneer we dit moeten omzetten naar een SQL query levert dit een opsomming op van alle typeid s die onder die Zien,Doen&Beleven : where catid in (48,49,50,51,52,...) ( in totaal geef dit een oplijsting van 130 typeid s). Dit willen we vermijden door een nieuwe tabel toe te voegen aan de databank. Deze we kan dan gebruikt worden om items aan de hand van types sneller op te zoeken. 3/5 Performantie SearchAPI en database: deel 2

4 De bedoeling is dat we in de nieuwe tabel alle types van het item gaan bewaren. Met alle types bedoelen we alle niveau s van het type. Bv: Wanneer een item van het type: hotel is, bewaren we voor het item de tabel een record voor: Hotel, Logies en Overnachten. De tabel zal steeds geupdate worden bij het syncen van een item. Een extra aanpassing is ook vereist bij het type scherm. Zodat de items ook geupdate worden, wanneer een type op een andere plaats in de boomstructuur wordt verhangen. Er zal een update script voorzien worden dat deze tabel opvult net na de release. We zullen deze performantie optimalisatie ook configureerbaar maken, zodat we deze kunnen aanzetten wanneer de tabel volledig is opgevult. Inschatting: 5 D Nieuwe views voor gebruik van search API We hebben gekeken naar de search API calls van 16/06/2014. Hierbij merkten we volgende zaken op: o Totaal aantal queries: o Slechts 11(!) aanvragen waren voor een andere taal dan het Nederlands o 50% van de aanvragen kwamen van kanalen waarbij de basisquery bestond uit: Workflow=approved + published=true +![createdby:vvvcadeaubonnen@vvvnederland.nl] o 30% van de aanvragen kwamen van kanalen waarbij de basisquery bestond uit: Workflow=approved + published=true 19,95% van de aanvragen kwamen van kanalen waarbij de basisquery bestond uit: published=true +![createdby:vvvcadeaubonnen@vvvnederland.nl] Ons voorstel is om 2 nieuwe views aan te maken: o Een view die enkel items bevat met als criteria: - workflowstatus= approved - published = true - taal= NL - deleted = false - createdby!= vvvcadeaubonnen@vvvnederland.nl o Een view die enkel items bevat met criteria: - workflowstatus= approved - published = true - taal= NL - deleted = false Vervolgens zal je, door middel van een dropdownlijstje, per kanaal kunnen instellen welke view het kanaal moet gebruiken. Door het gebruik van de dropdownlijst, is het mogelijk om in de toekomst nog views toe te voegen wanneer hiervoor noodzaak is. (We gaan geen views toevoegen per kanaal of voor werkgebieden! Het gebruik van de views heeft namelijk ook impact op de snelheid van het bewaren van een item) Let op! Het is niet zo dat je geen deleted items of anderstalige items meer kan opvragen wanneer je kanaal gebruikt maakt van deze views! Er zal een fallback mechanisme worden ingebouwd zo dat dit toch nog mogelijk blijft. 4/5 Performantie SearchAPI en database: deel 2

5 Nadat we dit geïmplementeerd hebben is het gewenst dat de basisqueries voor de bestaande kanalen gewijzigd worden. (Indien dit niet wordt gedaan, zal niet de volledige benefit van deze optimalisatie worden bereikt) Bv: kanaal: Basisquery: [workarea: VVV Assen] [published: 1] [workflow: approved] Moet worden: View= [approved,published] Basisquery: [workarea: VVV Assen] Het inregelen van de kanalen valt buiten scope. Inschatting: 4 D Beperken van pagelength parameter In de SearchAPI kan je met behulp van de parameter pagelength bepalen hoeveel resulten je in de listview wenst te krijgen. Op dit moment is hier geen limiet op. We zien in de logging dat sommige partijen > items in de listview opvragen. We zien hier geen enkele meerwaarde van in. Dit is enkel belastend voor de server. Daarom stellen we voor om dit te beperken tot een maximum van 100 items. Dit zal geen invloeg hebben op de export service en export module. We stellen voor om dit te als parameter op te nemen zodat we: o De beperking op de pagelength parameter kunnen aan/uit zetten o Het maximum aantal items dat de listview kan teruggeven, kunnen instellen. Let op! Het is niet zo dat de searchapi met deze limiet enkel en alleen de eerste 100 resultaten teruggeeft. Door middel van de page parameter kan je de volgende resultaten opvragen: Bv: q=hotel&pagelength=100&page=1 geeft de eerste 100 resultaten terug. q=hotel&pagelength=100&page=2 geeft de volgende 100 resultaten. Inschatting: 0,5 D 3.2. Hardware Momenteel heeft de database server 26GB geheugen. Ik stel voor dit op te trekkenhet parsen en compileren van de queries 3.3. Eventdetail Bij het opvragen van eventdetails via de searchapi worden eventblob s 1 voor 1 opgehaald dit kunnen we aanpassen zodat deze in bulk opgehaald worden. Hierdoor zijn er minder calls naar de database nodig. Inschatting: 1 D 5/5 Performantie SearchAPI en database: deel 2