D365FO Unit Testing Performance Degradation After Import-D365Bacpac (T2 Bacpac)

[jpiquot]

Description

After importing a T2 bacpac using Import-D365Bacpac, D365FO unit tests take approximately 3 minutes longer to execute compared to a fresh Cloud Platform VM environment.

Environment

• Environment: Cloud Platform VM (LCS)
• Database: GOLDEN T2 bacpac imported via Import-D365Bacpac
• Test Framework: D365FO unit testing framework

Steps to Reproduce

1. Create a new Cloud Platform VM from LCS (10.0.45)
2. Create a new D365FO project with the default test class
3. Run the unit tests
   • Result: Tests complete in approximately 45 seconds
4. Refresh the VM database with a GOLDEN T2 bacpac using Import-D365Bacpac
5. Run the same unit tests (that do nothing else than assert an error) again
   • Result: Tests now take 3 minutes and 45 seconds to complete

Expected Behavior

Unit tests should maintain similar execution times (~45 seconds) after importing a bacpac, comparable to a fresh environment.

Actual Behavior

Unit tests take 3 minutes longer (3m 45s total) after bacpac import, representing an 8x performance degradation.

Analysis

The 3-minute delay suggests a potential SQL connection timeout issue:

• The default SQL timeout is typically 3 minutes
• This points to possible connection configuration problems with the restored database
• The tests may be attempting to connect and waiting for timeout before proceeding

Question

Is there a specific configuration that needs to be changed after using Import-D365Bacpac to avoid this performance issue?

Possible areas to investigate:

• SQL connection strings
• Database compatibility settings
• User permissions or login configurations
• Query Store or execution plan cache
• Database statistics or indexing

Additional Context

This issue is reproducible and consistent across multiple bacpac imports from T2 environments.

// Prefer the name of the class or area being tested with the Test suffix.
// The test class must transitively extend the SysTestCase class.
// You can find more information here: https://docs.microsoft.com/en-us/dynamicsax-2012/developer/unit-test-framework
public class DummyIntTest extends SysTestCase
{

    // Test methods must be public, take no parameters and return void.
    // Their names can start with test, or they can be adorned with the SysTestMethod attribute.
    [SysTestMethod, Hookable(false)]
    public void MyTest()
    {
        // Use the assert* functions to check the outcomes.
        this.assertNotNull(null);
    }

    // This is a test method because of the test prefix.
    [Hookable(false)]
    public void testSomething()
    {
        this.assertTrue(false);
    }

    public void setup()
    {
        // This method will be called before every test method.
        super();
    }

    public void tearDown()
    {
        // This method will be called after each test method
        super();
    }

    public void setupTestCase()
    {
        // This method is run before any test method
        super();
    }

    public void teardownTestCase()
    {
        // This method is run post all test methods.
        super();
    }

}

[jpiquot]

Even when building in Visual Studio, we still see an extra three minutes of build time after a T2 refresh—1:30 on Contoso and 4:30 after the GOLDEN refresh.

[Splaxi]

Thank you for taking the time to provide an extensive description of the issue.

The Import-D365Bacpac is just built on top what Microsoft is offering, so it behaves as Microsoft has designed things to work. Have you considered trying to use the sqlpackage.exe and validate if the issue persist?

With that said, have you any data points from earlier versions before 10.0.45? To see if it might be something on the D365FO (Application / Platform) that has changed?

Did you ask around on the engage community groups, to see if other people experience the same?

Do you have access to a SQL DB Administrator, that can assist you with some insights whether or not there could be some index tuning needed?

[jpiquot]

Hi @Splaxi,

I’ve carried out many engagements as a performance-focused DBA, and from my perspective there is no SQL Server performance issue here — especially since the database is extremely small (much smaller than a standard Contoso DB).
Yes, we did attempt to update the environment manually using several procedures with "SqlPackage.exe" found on the web, but the result was always the same. We also deployed a CHE VM on version 10.0.43, but encountered the same behavior (the BACPAC remaining at version 10.0.45).
We haven’t found any posts or reports from others experiencing this issue.
We will open a Microsoft support case to try to resolve it, and I will share the outcome once we have more information.
Thanks again for your help.

[FH-Inway]

@jpiquot
Interesting behavior. Does the longer runtime stay consistent for multiple runs after the bacpac restore? If it is just a longer runtime for the first unit test run after a restore, the reason might be that the required data is not loaded into the working memory and caches. While the unit test itself requires no database access, the setup done by the unit test framework for every run requires database access.

If the runtimes are consistently longer, it might be worth figuring out if a trace of a unit test run can be created using Trace Parser. That should reveal the culprit.

I'm assuming the tests make use of the SysTestCaseDataDependencyAttribute to require a database restore? If yes, consider rewriting the tests so they don't require the attribute (the Acceptance Test Library can be of great help with that). Then or if the attribute is not used and there are no other dependencies on the data, the database restores would not be necessary anymore.

Good luck with Microsoft support!

[jpiquot]

@FH-Inway I don't use the SysTestCaseDataDependencyAttribute. I reproduced the issue with the simplest case: create a project, then "Add Item" and choose "Code" → "Test Class", and run the test. I will try the trace parser to see if it finds anything relevant. We use the database bacpac import to get the latest setup and working data from the staging instance, not to reset the test data. Thanks for the information.

[jpiquot]

The slowdown in development environments is caused by OData discovery during startup. I believe the D365FO tools script should set the following parameter to false when importing into a T1 environment. Since it runs before anything else, it cannot be detected by the debugger or trace tools (no active session).

Missing operation:
UPDATE SystemParameters SET ODataBuildMetadataCacheOnAosStartup = 0