NAV Classic Client: Bound to CPU frequency?

Pdahm

Hello everyone,

i'm here today to ask a rather complicated and (maybe) stupid question.
Since a short time i'm "responsible" for a dynamics sytstem (Nav 2009 R2, Classic, 5.01 objects).
Now, i have not very much knowledge about dynamics, but i know something about SQL databases, Windows Server Systems, programming.
So maybe i'm the wrong person for the job, but we will see...

For quite some time we have trouble with our ACIE process. We have "average" as costing method, an if i have read it right, this is the slowest of all possible solutions. :thumbsdown:
Whatsoever, we have a fairly fast SQL 2008 where the Database is hosted, and in the moment, this is the only DB on this machine. In case you wonder: 48 Disk SAS Raid 10, 64+GB ram etc. That thing won't be the bottleneck. So, if i run the classic client local on the SQL (TCP or named pipes, does not matter), i get about 2000 Batch requests/second, the SQL has about 0-2% CPU usage, and the raid is about 0.1 mb/s (Hell, what do i need a raid that does 1.8 Gb/s? ). All ACIE relevant indexes seem to be present.

I was wondering: The client does not use much CPU, the SQL does not use CPU or DISK I/O - what the hell is taking so long in the ACIE process?

So i started a little "debugging" and found out that the Navision framework seems to have some "unnecessary" waits and additionally, these seem to be bound to the CPU frequency.
So how did i checked that?
Modern CPU's slow down if the processing power is not needed. Intel's speedstep is one of these technologies. So, if the system is sleeping most of the time, the CPU frequency multiplier goes way down to preserve energy and temperature. Since i had as good as no CPU usage on that system while ACIE was running, the CPU multiplier was (in my case) at 12. Now, i started to force the CPU to go to full speed (you could do that with Throttlestop or I7 turbo, if they work for you - i needed something real:prime95, low priority) and guess what: CPU multiplier went up to 19 (as expected)
and SQL batch requests per second raised to nearly 3800.

So what does this tell me? I think that the client has some old programming inside that keeps it from running at maximum efficiency. Furthermore, i believe there are some timers inside the navision code that are bound to the CPU cycles. This was OK with older CPU's - maybe. But as modern CPU's are not anymore static in this behavior, we are loosing a lot of performance in navision thanks to this issue. And i think without waits in the programming, thinks like ACIE could run a LOT faster than now....

Before i do anything stupid: Is there anyone who is willing and able to check this behavior in his environment and rather confirm or deny my finding?

Have a nice day/evening,

Patrick

kriki

I have some answers/remarks on it:

1) NAV is working record by record and does a lot of calls to SQL Server for 1 or a few records that it then consumes record by record. This is the reason that the NAV-client is waiting a lot. This is normal for any ERP: a lot of data-access but little CPU-use.

2) to get the max speed of this kind of processing, it is best to run the client directly on the server (you don't specify if you do, but I think you did).

3) On a SQL Server, on of the first thing you should do is disable the possibility that the CPU throttles its speed. This is always a big performance bottleneck (NAV o no NAV). You can disable that in Windows or probably also in the BIOS. (No need to install programs that burn CPU-cycles for nothing increasing. Those programs are really useless because the throttling is for saving electricity but to avoid throttling you burn more CPU-cycles raising (a lot) electricity-use.)

Sog

Pdahm wrote:

Since a short time i'm "responsible" for a dynamics sytstem (Nav 2009 R2, Classic, 5.01 objects).

I think that the client has some old programming inside that keeps it from running at maximum efficiency.

Well, since the classic client is still in play, you may be sure it still has some old programming inside.
The classic client is used since NAV beforemytime.
See a history of the program here: http://www.navisionplanet.com/2009/06/n ... sions.html

mdPartnerNL

kriki wrote:

I have some answers/remarks on it:
3) On a SQL Server, on of the first thing you should do is disable the possibility that the CPU throttles its speed. This is always a big performance bottleneck (NAV o no NAV). You can disable that in Windows or probably also in the BIOS. (No need to install programs that burn CPU-cycles for nothing increasing. Those programs are really useless because the throttling is for saving electricity but to avoid throttling you burn more CPU-cycles raising (a lot) electricity-use.)

Could you give more info about what setting and if you have the time explain this a little more?

Sog

Thats CPU/vendor specific.
This should be the right direction: http://www.bing.com/search?q=cpu+disable+underclocking

Pdahm

kriki wrote:

I have some answers/remarks on it:

1) NAV is working record by record and does a lot of calls to SQL Server for 1 or a few records that it then consumes record by record. This is the reason that the NAV-client is waiting a lot. This is normal for any ERP: a lot of data-access but little CPU-use.

That's more or less correct, but the observed increase in Batch requests/s give me a hint that there are more waits than neccessary. From personal experience, i know that sql requests can be a lot faster that what is observed here, so i have a strong feeling that the client is waiting too much.

2) to get the max speed of this kind of processing, it is best to run the client directly on the server (you don't specify if you do, but I think you did).

It was done this way.

3) On a SQL Server, on of the first thing you should do is disable the possibility that the CPU throttles its speed. This is always a big performance bottleneck (NAV o no NAV). You can disable that in Windows or probably also in the BIOS. (No need to install programs that burn CPU-cycles for nothing increasing. Those programs are really useless because the throttling is for saving electricity but to avoid throttling you burn more CPU-cycles raising (a lot) electricity-use.)

Hmm, i will check if this is really a needed setting for databases systems. Normaly, as soon as something is requesting CPu power, the system comes up.

kriki

1) The NAV-client is not really waiting. It is going at full speed but a classic client is not using machine code to process the programs. Compiling in C/AL means converting it to a more compact code so the C/AL interpreter can interpret it faster when it needs to execute it but it still isn't pure machine code (this is different for RTC!).
Basically, it also comes down to CPU-throttling again (apart from the fact that the classic client is slow executing pure code because it is interpreting code).

3) But a lot of times it is just a spike that goes down before the CPU can get up to speed and when it is up to speed, the spike is already finished. Read also this http://www.brentozar.com/archive/2010/10/sql-server-on-powersaving-cpus-not-so-fast/

mdPartnerNL

Thanks for the tip.