NAV 2018 CU7 - Very slow RapidStart performance

jonathanchyejonathanchye Member Posts: 34
edited 2018-08-16 in NAV Three Tier
We recently upgraded our servers to a hyper-converged (NUTANIX) solution. We've setup 2 Server 2016 VMs, one for Service Tier and the other for SQL DB.
Specifications exceeds the Microsoft recommendations.
We find the RapidStart performance very slow. For some reason the RTC client is not responsive at the end of the "Apply Package" process. The RTC will remain in this state until the process is completed.
I've monitored server performance and during this time the only intensive activity is network activity where the SQL server is sending data to the Service Tier server.
We've applied a package which updates Items at about 50,000 records and that took about 15 hours to complete. It only updated 50 records in the end even though there were no issues with validation which is weird. Anyway this could be down to user error so will park that.
I've then created another package to update the Post code table which is about 3,000 records. I've turned on "Skip table triggers" this time. It's been 5 hours and it's still running.
We are on CU7 on NAV2018 and I did have a look at CU8 notes but can't see anything related to RapidStart.
I'm diving into server setup and configuration but can't see anything that is amiss. From Googling I've found a thread (https://community.dynamics.com/nav/f/34/t/283389) which means a final call to FixIntegrationRecordIds but nothing really conclusive.
Hopefully someone can kindly shed some light as this will impede the Go Live data upgrade timings.

Answers

  • jonathanchyejonathanchye Member Posts: 34
    So I've fired up the Event Subcriptions and noticed a high number of subscriber calls (500k) to CU5150 Integration Management OnUpdateReferenceIdField. The subscribers are part of the Graph Mgt CUs.
    Any idea why it's doing this?
    It's looking like any RapidStart will take 15+hours regarding of the data...
  • jonathanchyejonathanchye Member Posts: 34
    Excellent! Thank you!
  • jonathanchyejonathanchye Member Posts: 34
    Actually I do have one more question please.
    I'm importing an Item Package with circa 50k records. Excel file size is 12MB.
    I have 61 fields included and 58 fields have validation.
    After clicking "Import from Excel" the client just hangs, there's no progress bar etc. I've waited for about 15 minutes now still no change.
    Just wondering if this is normal?
  • adevapartadevapart Member Posts: 1
    There are multiple phases of RapidStart Excel Worksheet loading that are slow.

    Phase 1 - Read the worksheet into an DotNet DataTable - very slow. 16 minutes for 88k records
    Phase 2 - Convert this to XML and process it into Config. Package Data records. This will become one record per field per row in source data (for my file it is 88k rows * 10 fields = 880k Config. Package Data recs.

    At some point, Phase 3 - Validate related data tables. This is where the time sink really happens. If you have a large database and your import has many related tables, RapidStart is not our friend here. You would have to turn off all field validation to get your data in before you grow old. This is not a user friendly experience. I have so many user stories for excel import export, it is painful. Having to come up with a creative means to give the user what they want, and not encumber them along the way.

    Regards,
    Mark

  • mrborgmrborg Member Posts: 2
    edited 2018-11-02
    Welcome to the Real World dear MS (You should visit us more often).

    I have always wondered who have tested these Rapidsstart imports with what data and who have accepted the usability and especially the performance before release. Someone most have developed this module and someone most have tested this module and minimum requirement for this module most have included data is imported OK and no module may show "not responding" for more than a minute without a user warning about this task will take a considerable amount of time.
Sign In or Register to comment.