Optimera prestandan i PIM iPMC

Har du någonsin undrat hur du bygger den mest optimerade inRiver PIM extensionen? Jag har satt ihop ett par prestandatester för att visa det bästa och mest effektiva sättet att hämta ut datan på. Som jag nämnde i ett tidigare inlägg här finns det flera sätt att ladda in datan i PIM, båda bra och dåliga sätt.

 

Att bygga ett snabbt och effektivt extension handlar om att anropa rätt API under Remoting API. För det här inlägget kommer jag att sätta upp följande fall och visa dig hur hur du får ut datan genom de olika anropen i Remoting API:

·       Get one Entity, using “GetEntity”

·       Get one Field, using “GetEntity” and “GetField”

·       Get five Fields, using “GetEntity” and “GetFields”

·       Get ten Fields, using “GetEntity” and “GetFields”

·       Get one Link, using “GetEntity” and “GetInboundLinksForEntityAndLinkType”

Testen kommer inte att utföras på ett korrekt vetenskapligt sätt, men det kommer att ge en indikation på hur du bäst programmerar din extension. Låt oss gå igenom förutsättningarna för testerna. Jag kommer att utföra dem från min lokala maskin genom fjärranslutning mot iPMC så laddtiderna kommer inte att reflektera vad du faktiskt kan förvänta dig när du kör extensionerna direkt i iPMC. PIM systemet har ungefär 2000 entiteter och innehåller en standarduppsättning för en marknadsföringsmodell (produkt, föremål, resurs). Samma gäller för länk typerna som används. Som de flesta av er redan vet så påverkar mängden entiteter och länkar prestandan för PIM systemet på olika sätt. För att reducera skillnaden i svarstiderna, på grund av "load balancing", cache etc. Har jag valt ut och hårdkodat i den för 25 entiteter och sedan beräknade den genomsnittliga responstiden för dessa föremål. Jag körde sedan testerna flera gånger och siffrorna jag presenterar här de bästa jag fick från testerna. Obs! att köra dessa tester kommer alltid att ge olika siffror.

Nog pratat om förutsättningarna för testerna, låt oss börja!

 

Get one Entity

Test case:

Detta är ett bastest för ”DataService.GetEntity” och vi kommer att jämföra genomsnittstiden genom att använda tre oilika ”Loadlevels”. Du kan lästa mer om de olika ”LoadLevels”  here.

Kod som används för “Get one Entity” test.

Resultat:

Shallow: ~0.60 s.

DataOnly: ~0.63 s. 5% längre respons tid än “Shallow”.

DataAndLinks: ~0.67 s. 12% längre respons tid än  “Shallow” and 6% längre än “DataOnly”.

Sammanfattning:

Som förväntat har mindre mängd hämtad data kortare responstid. Men jag måste säga att jag är lite förvånad över att skillnaden inte är större än detta. 

 

Get one Field

Test case:

I det här fallet kommer vi att första ladda in Entity med “LoadLevel” “DataOnly”, sedan hämtar vi ut fältet med entity. () och sen kommer vi att hämta fältet igen genom DataService. GetField anropet

Kod som används för "Get one Field” test.

Resultat:

GetField: ~0.18 s.

GetEntity (DataOnly): ~0.63 s.

Sammanfattning:

Precis som förväntat så har att hämta mindre data också lägre responstid. I det här testet är det 3,5 gånger snabbare att hämta GetField än hela Entity. Om du bara behöver ett värde för ett field så ska du absolut bara köra “GetField” call. Ett tips är att du också kan få  “EntityTypeId” från “FieldType” object. Så om du har en " lyssnare" som bara ska processa items, då kan du använda “GetField” call istället för “GetEntity”.

Get five Fields

Test case:

“Get One Field”. Here we will first load the Entity with “LoadLevel” “DataOnly” and then get five fields using entity.GetField() and then we will get five Field using the DataService.GetFields call.

Kod som används för “Get five Fields” test.

Resultat:

GetFields: ~0.35 s.

GetEntity (DataOnly): ~0.63 s.

Sammanfattning:

Som tidigare test, mindra data ger snabbare responstid. Hämta fem fields är nästan dubbelt så snabbt som att hämta hela Entity.

Get ten Fields

Test case:

Låt oss dubbla anatalet fields som vi vill ha från iPMC.

Kod som används för “Get ten Fields” test.

Resultat:

GetFields: ~0.37 s.

GetEntity (DataOnly): ~0.63 s.

Sammanfattning:

Det är inte mycket ökning från fem fält till tio fält i responstid. Så det är fortfarande snabbare än att ladda hela enheten, men det börjar vara mycketFieldId som du måste lagra i inställningar eller i kod för att samla in de data du vill ha.

  

Get one Link

Test case:

Som de flesta av er vet så finns det flera sätt att hämta en Länk. För det här tester kommer vi inte att känna till Link ID så vi kommer att behöva hämta länken baserat på Entity ID och en känd LinkType ID. Först kommer vi att hämta länken genom att använda "GetEntity" och "DataAndLinks" i andra testet kommer vi att hämta länken med "GetInboundLinksForEntityAndLinkType". Alla items som används i det här testet har en länkad produkt med 4-10 länkade resurser och omkring fem länkar för channel nodes.

Kod som används för “Get one Link” test.

Resultat:

GetInboundLinksForEntityAndLinkType: ~0.70 s.

GetEntity (DataAndLinks): ~0.76 s.

Sammanfattning:

Jag måste medge att jag alltid har trott att "GetInboundLinksForEntityAndLinkType" är mycket snabbare än att ladda in hela entiten via "GetEntity". Jag gjorde testet flera gånger för att verifiera mitt resultat. Detta betyder att om du laddar in entitet med ”loadlevel.shallow” och sedan hämtar länken med ”GetInboundLinksForEntityAndLinkType” då kommer faktiskt konsumera mer tid än att hämta all data med en gång med ”DataAndLinks”.

Avslutning:

Förhoppningsvis finner du mina testresultat behjälpliga för dig när du skall utveckla en snabbare och bättre ”Extension”. Obs stirra dig inte blind på den faktiska responstiden utan detta kommer att vara mycket snabbare om det ligger ute i produktion än vad jag fick från min lokala dator. Det intressanta är däremot att kolla på skillnaden i svarstid på de olika metoderna att hämta data på.

 

Daniel Jansson
inRiver PIM Developer
daniel.jansson@sigma.se

2018-06-13

PIM
Unified Commerce