Performance of G/L-Posting - any benchmark?

theshmike

Hi there,

is there any guidance on how to size NAV14/BC SQL servers or how to benchmark good or poor performance? A customer asked us to analyze some kind of poor performance on their NAV14 production environment. They are complaining about slow general ledger journal import from csv and slow journal posting.

On an isolated test system I was able to tune the import of 3k rows to 36 seconds and post (check lines, check balance, post, delete) the 6k journal lines in 270 seconds, which breaks down to ~10ms for importing a row and ~78ms for posting a line. From analyzing waits and locks, there is absolutely no bottleneck in storage, memory or cpu.
The customer uses to import journals with 50k rows and "feels", that this takes too much time. So I am trying to find out which are good measures for this task.
Is there any advice you can give me?

I am very experienced in ERP systems, especially with AX, but I am new to NAV. I also don't know if the journal import functionality is standard or customized by the implementation partner.

And just to say: I was wondering if it's common use in NAV to post such large journals in a dialog. In AX we mainly imported journals with batch jobs and queued them for posting at night or whenever nothing is to do...

I would be thankful for any advice

David_Singleton

I have a client that regularly posts journals with 100,000+ lines. It depends on a lot of things, but basically once you get into larger system with NAV/BC you can't expect it to "just work" without significant tuning effort. Every other ERP system expects this, NAV?BC is the same.

But unfortunately there is no magic bullet, you will find there will be 4 or 5 major issue and then a whole lot of smaller ones all of which need to be resolved.

The hardest part of tuning a NAV/BC SQL server is explaining to the client that this will cost money and getting a budget to do the work. Once you have that it becomes fairly straight forward.

jordi79

Seems like the system was customised. You have to first establish a "base line". Import "similar" 50,000 lines into a standard NAV database, and post to establish a base line, and compare with what you have now in the PROD system. If it is not far off, then this is a the "best you can get" scenario.

If what you have in PROD is far from "base line", then this is something you can work with. And it gets technical here. You can dissect and find out what the previous implementation partner did to the system to cause the slowness. E.g. maybe they introduce some validations, some other table updates else where etc.

But to do this proper, you'd need to know the system. Good luck!

David_Singleton

jordi79 wrote: »

..., then this is a the "best you can get" scenario.
...

I would disagree with this. I do agree that it appears that there may be customizations that need to be reviewed, but the NAV base app is by no means ideal in terms of performance, and can always be improved significantly. I have never seen a this is the "best you can get scenario" as you describe.