Question Status

Verified
Paul Heisterkamp asked a question on 28 Mar 2013 6:08 AM

Hi,

We run more and more into performance issues with the TFS integration of AX.

When we started using TFS the performance was not the best but also not as worse as now. A check-in with more than 10 objects takes minutes/hours in some cases…

We are using AX with TFS integration with up to 15 developers and same count of functional users. The functional users manage everything around work items via Team Explorer of Visual Studio.

All our devs are using a separate TFS-connected environment with dedicated AOS, SQL and DEV-client.

The configuration of our TFS is a virtualized environment with 4 CPUs and 8 GB Ram and the SQL-database is located on a dedicated NON-virtualized SQL-Server.

Did anyone else face performance issues during check-ins to TFS or even did customizations to speed up the check-in from AX?

 

Thanks and regards,

Paul

Reply
Suggested Answer
Joris de Gruyter responded on 28 Mar 2013 8:21 AM

Our environment seems similar to yours as far as virtual/physical setup. I agree the integration is not the fastest, but minutes or hours to check-in more than 10 objects is not acceptable but I have honestly not had that issue.

One thing that comes to mind is how AX performs the integration... it compiles the object and exports the XPO which creates some overhead and of course also disk access prior to checking in.

But no, I have not seen any bad performance to that scale. We've been using TFS for 3 years or so now, both on AX 2009 and AX 2012.

Reply
Paul Heisterkamp responded on 29 Mar 2013 4:51 AM

Hey Joris,

first of all thank you for your quick reply.

Can you go a little bit more in detail about your tfs sizing in case of RAM and CPUs?

And what is your compiler and BP-check setup. I guess the compile and BP-check in the process of check-in is the reason for the bad performance....

Paul

Reply
Martin Dráb responded on 29 Mar 2013 7:51 AM

The worst thing in compiler setup (for performance) is update of cross-references. BP-check also slows things down.

When dealing with any performance issues, it's always important to find out what exactly is slow. As you see, if the problem is in compilation in AX, trying to optimize TFS won't help.

About CPU and RAM, you can measure if you have any pressure on resources. If there is none, adding more resource won't make any difference. If there is some, you still may get improvements by other means like changing configuration, ensuring that database has fresh indexes etc.

Another potential area of issues is in network communication, including authentication.

If the problem is on TFS side, Tips for Improving Team Foundation Server Performance may give you few more ideas.

Martin "Goshoom" Dráb | Freelancer | Goshoom.NET Dev Blog

Reply
Verified Answer
Paul Heisterkamp responded on 4 Apr 2013 4:51 AM

So here is the solution for my problem.

In the last days the trace parser became a friend of mine and he helped me to find the performance leak.

The problem was the compile and bp-check in the process of check-in.

Before check-in starts the compiler level will be set to Level::4. Because of this setting the first bp-check for on element will be performed while compile. The second bp-check will be performed while checking BP separately.

Because we are using also checked-in shared projects the tfs integration will compile and bp-check all elements included in the project a second time.

So if an element will get checked in which is also included in the project (which get checked-in) this element will get compiled twice and get bp-checked four times.

I made some changes in our environment to check every element only once and I also added some caching in bp-checks to speed up the checks in general.

In my case the duration of check-in decreases for a specific element-set from 5 minutes to 30 seconds.

Reply
Verified Answer
Paul Heisterkamp responded on 4 Apr 2013 4:51 AM

So here is the solution for my problem.

In the last days the trace parser became a friend of mine and he helped me to find the performance leak.

The problem was the compile and bp-check in the process of check-in.

Before check-in starts the compiler level will be set to Level::4. Because of this setting the first bp-check for on element will be performed while compile. The second bp-check will be performed while checking BP separately.

Because we are using also checked-in shared projects the tfs integration will compile and bp-check all elements included in the project a second time.

So if an element will get checked in which is also included in the project (which get checked-in) this element will get compiled twice and get bp-checked four times.

I made some changes in our environment to check every element only once and I also added some caching in bp-checks to speed up the checks in general.

In my case the duration of check-in decreases for a specific element-set from 5 minutes to 30 seconds.

Reply
Suggested Answer
Joris de Gruyter responded on 28 Mar 2013 8:21 AM

Our environment seems similar to yours as far as virtual/physical setup. I agree the integration is not the fastest, but minutes or hours to check-in more than 10 objects is not acceptable but I have honestly not had that issue.

One thing that comes to mind is how AX performs the integration... it compiles the object and exports the XPO which creates some overhead and of course also disk access prior to checking in.

But no, I have not seen any bad performance to that scale. We've been using TFS for 3 years or so now, both on AX 2009 and AX 2012.

Reply