Optimizing performance in iPMC
Ever wonder how to build the most optimized inRiver PIM extensions? I have put together a set of performance tests to show you the best and most efficient ways to get you the data you want. As I mentioned in my earlier post found here there are several ways to load the desired data in PIM, both good and bad ways.
Building a fast and efficient extension is all about using the right API calls in the Remoting API. For this post I’m going to set up the following cases and show you how to get the data using the different calls in the 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”
This will not be a scientific correct executed test but it will give you a hint on the best ways on how to code your extensions. Let’s go through the conditions with who I will perform these tests. I will run all test from my local machine using a remote connection to iPMC so the actual loading times will not be reflected with what you can expect running your extension directly in the iPMC. The PIM system will contain proximally 2000 entities and contains a quite standard set up of the marketing model (Product, Item, Resource). The same goes for the link types used. As most of you already know the amount of entities and links in the PIM system will have an impact on the performance in different ways. To decrease the differences in response times, due to load balancing, caches etc., I have selected and hard coded entity ids for 25 Items and then calculated the average response time for those items and then I ran the test several times and the numbers I will present here are the best once I got. So please note, running these test will always generate different numbers.
Ok, enough with the premises of the tests. Let’s get started!
Get one Entity
Test case:
This is a basic test using the “DataService.GetEntity” and we will compare the average time using the three different “LoadLevels”. You can read more about the different “LoadLevels” here.
Code used for “Get one Entity” test.
Results:
Shallow: ~0.60 s.
DataOnly: ~0.63 s. 5% longer response time then “Shallow”.
DataAndLinks: ~0.67 s. 12% longer response time then “Shallow” and 6% longer than “DataOnly”.
Conclusion:
As expected less data fetched has shorter response time. But I have to say that I’m a little surprised that the difference isn’t larger than this.
Get one Field
Test case:
In this test we will first load the Entity with “LoadLevel” “DataOnly”, then get the field using entity.GetField() and after that we will get the Field again using the DataService.GetField call.
Code used for “Get one Field” test.
Results:
GetField: ~0.18 s.
GetEntity (DataOnly): ~0.63 s.
Conclusion:
Again as expected less data fetched has shorter response time. In this test the difference is larger, it’s 3,5 times faster running the GetField call then loading the whole Entity. If you only need the value for one field you should definitely go for the “GetField” call. A tip here is that you can also get the “EntityTypeId” from the “FieldType” object. So if you have a listener that should only process items, then you can use the “GetField” call instead of “GetEntity”.
Get five Fields
Test case:
This test will be quite similar to “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.
Code used for “Get five Fields” test.
Results:
GetFields: ~0.35 s.
GetEntity (DataOnly): ~0.63 s.
Conclusion:
As in earlier tests less data fetched is faster. Getting five fields with GetFields call takes almost half the time than loading the whole Entity.
Get ten Fields
Test case:
Just for fun lets double the amount of fields that we want to get from iPMC.
Code used for “Get ten Fields” test.
Results:
GetFields: ~0.37 s.
GetEntity (DataOnly): ~0.63 s.
Conclusion:
So there is not a much of an increase in time to load then fields instead of five. So it’s still faster than loading the whole entity but it’s starting to be a lot field IDs that you have to store in settings or in code to collect the data you want.
Get one Link
Test case:
In this test are going to get one Link based on a known “LinkType” ID. As most of you know there are several ways to get a Link. In this test we will not know the Link ID so we have to look for the link using a known Entity ID and a known “LinkType” ID. First we will get the link using “GetEntity” “DataAndLinks” and second we will get the Link using “GetInboundLinksForEntityAndLinkType” call. All items used in this test have one linked product, between 4-10 linked resources and around five links to channel nodes.
Code used for “Get one Link” test.
Results:
GetInboundLinksForEntityAndLinkType: ~0.70 s.
GetEntity (DataAndLinks): ~0.76 s.
Conclusion:
I have to say that this result surprised me a bit. I have always thought that “GetInboundLinksForEntityAndLinkType” was much faster than loading the whole Entity with data and links. I had to run the test several times to verify the response times, but it looked like this every time. So this means if you first load the entity using “LoadLevel.Shallow” and then get a link using “GetInboundLinksForEntityAndLinkType” it will actually consume more time than just fetching all the data (DataAndLinks) at once.
Final words
So hopefully you find my test and conclusions helpful for you to develop better and faster extensions. As I started the post, don’t stair yourself blind on my response times since they are from my develop machine and are not representative for the response times you will get by running your extension deployed in the cloud. The interesting thing to look at in my tests are the difference between the response times using different methods to get the data.
Daniel Jansson
inRiver PIM Developer
daniel.jansson@sigma.se
2018-06-13
PIM
Unified Commerce
