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
datum sec0_1 sec1_2 sec2_3 sec3_4 sec4_5 sec5_10 plus10sec totaal 2014-05-24 1528700 46888 8015 2588 970 955 632 1588748 2014-05-25 1503523 48003 14851 6935 3696 4004 1010 1582022 2014-05-26 1328733 55430 22745 12357 8672 12090 1813 1441840 2014-05-27 1366073 59888 25953 13055 9739 14514 2208 1491430 2014-05-28 1424736 51243 27673 14327 7283 6306 1748 1533316 2014-05-29 1623450 34828 5971 1760 655 762 542 1667968 2014-05-30 1575506 48117 24084 11787 5108 4825 1518 1670945 2014-05-31 1561771 36936 7348 2625 1049 1003 676 1611408 2014-06-01 1363509 43371 19638 9937 4260 4330 1710 1446755 2014-06-02 1405749 42886 19344 9287 3878 3851 1786 1486781 2014-06-03 1191705 44047 25652 13240 5899 5136 1942 1287621 2014-06-04 965839 18976 5055 1544 618 628 315 992975 2014-06-05 1026037 48213 22532 10170 4104 3800 1283 1116139 2014-06-06 1192331 83424 34839 18789 9446 9973 2709 1351511 2014-06-07 1461148 111150 23921 7657 2790 2778 1243 1610687 2014-06-08 1273378 102612 32352 14733 7214 8120 2226 1440635 2014-06-09 983255 78212 31939 15669 7850 7435 2004 1126364 2014-06-10 964475 87189 17053 4864 1779 1670 760 1077790 2014-06-11 1068680 141211 46498 22354 11224 12521 2475 1304963 2. 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. Oplossingen 3.1. SearchAPI queries 3.1.1. Reeds uitgevoerd Op release 2.5.9 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 10.000 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. 3.1.2. 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
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: 1.144.915 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
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: www.vvvassen.nl/sitecore 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 > 15.000 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