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.

 optimize main

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

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

2018-06-13

PIM
Unified Commerce

Vill du veta mer om utveckling i PIM? Kontakta oss.


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


Adan Hultgren
E-handel, PIM, digital strategi
adan.hultgren@sigma.se
+46 730 449515


Reflektioner av 2019

Självskatta er Master Data Management-mognad med nytt onlineverktyg!

Om alla levde som genomsnittlige svensken skulle det behövas 4,2 planeter

Funderar du på nästa steg för att utveckla din digitala affär?

Tävla om strategiworkshop - möt oss på Näringslivsdagen

Stockholm Helsinki B2B Travel Show

Insikter kring språk och översättningar för PIM och Web

Lansering av Ciqola Carpets, webshop byggd av Sigma med Storm Commerce och Umbraco CMS

Sigma inleder samarbete med IHM BUSINESS SCHOOL

Stibo Connect 2019

Webinar: Umbraco och Storm – en vinnande lösning för din e-handel

Episerver partner close-up

I den digitala spåkulan inför 2019

Omnikanal på riktigt

Ny logga!

Vad är headless?

The story about Golden Record and how you get total control over your Content Provided data.

Hur du ställer in ditt första PIM iPMC- Extension på 5 minuter

Optimera prestandan i PIM iPMC

10 tips for the inRiver PIM developer

E-handel B2B vs B2C (3 VIKTIGA FAKTORER)

Sugcon India 2018 Retrospective

Förändringsdrivna IT-projekt

Vad är PIM?

Ta nästa steg med inRiver PIM

Sugcon India 2018

På väg till Camp digital

Sigmas inspirationsdag

En dag pa Husqvarna

Efter Pimpoint 2018

Välkommen på frukostseminarium

Om sömlösa digitala ekosystem för handel på D-Congress

Sigma på PIMpoint i Malmö 12-13 april

Upplev den senaste tekniken live!

Sigma på Data2020 i Stockholm den 14 sept

Om digitalt ekosystem för handel på D-Congress

Seminarium om Unified Commerce as a Service

Lansering av Unified Commerce as a Service