Is there a way to improve the Assets performance of the last step?
Asked by Stefan Stadler:

Hi team,

I hope you are doing fine.

I have a problem with importing a larger number of objects.

On some large object types, I got importing time, which is taking an hour or even longer for about 50000 objects (some with references to even larger object types).

Most of the time (more than 95% of the overall time) is spent within the last step to create the references.

Are you aware of any ways to improve the performance of this step?

Thanks!


Answers:
author: Carla Ann Rowland
body: on the import, with that amount of data then you can remove the fields that do not be imported. Also you might write a filter to have it only import data that meets a specific criteria.


author: Carla Ann Rowland
body: data center and cloud process is same for the Asset tables just the layout of the import screens are slightly different


author: Carla Ann Rowland
body: the import process is same for data center and cloud


author: Carla Ann Rowland
body: The only way to do that is so save the configuration so it can be reused. then you can review the mapping instead of recreating the mapping

comments: author: Stefan Stadler
body: Hi Carla,

can you please explain this in a little more detail?

And can you let me know, what exactly is causing this mapping to be that expensive? Maybe there is some way to improve the performance by some hardware tuning.


author: Carla Ann Rowland
body: when you import items into asset tables: you set up the import and then you map the fields from your csv to your asset fields this is saved. Here is a link: <https://support.atlassian.com/jira-service-management-cloud/docs/create-objects-from-data-using-object-type-mapping/>


author: Stefan Stadler
body: Hi Carla,

thanks for that. I noticed this document is for Cloud only. And it basically describes how to link objects to other objects. That is what I am doing, which is why the last step (Updating references) is executed at all.

We are running on a Server instance, so the article does not apply completely, but if I did not misunderstood this, We are already doing this. This is the configuration we are running. The object type LotID is referenced by another object type. Unfortunately LotID holds more than 600k objects. And also the new object type is holding about 30k objects.

![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/327406i081DCD8FA1A0F300/image-size/large?v=v2&px=999 "image.png")

![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/327407i9F52C34392EAED04/image-size/large?v=v2&px=999 "image.png")![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/327403i935E8AD4234813A2/image-size/large?v=v2&px=999 "image.png")

I am a little concerned about the amount of references to be updated. It seems the import updates all objects available even if almost nothing has changed. Is this the expected behaviour? Or did I miss anything in configuration, which is forcing this to happen?

Thanks for your help!


Tags: jira-service-desk-data-center

jira-service-management

jira-service-management-data-center

jira-service-management-server

server