Hi all Does anyone of you people have any experience in what the hardware requirements would be with Navision and SQL Server and 300 current users and approx. 1 million postings a year? Server size(RAM, hard drive etc.) Any help is welcome. Regards Andreas L.
Hi. I have tested Navision server 256Mb RAM and 20Gb Hard drive. It seems to me that this server worked too slow. But SQL server these resurses must be 2 times biger. With regards, Maris
Be careful here - you’re on the edge of Navision Financials/Attain capabilities. Being so close to -or even over- the limit is asking for troubles in the longer run. What if the user wants to expand further? 1 Million postings/year = (approx.) 5000 per day = 625 per hour = 6 seconds available for each posting only. Apart from all the other stuff to be done (order entry, inventory movements, printing(!!), etc. etc.) It’s not impossible, but only with very heavy hardware (multiprocessor serverS, plenty of RAM, multiple disks, high speed network, and so on). But in this case, I would seriously start looking at the Navision package which was designed to have such a load - Axapta running Oracle. Your client might be better off with that solution… John
1 million postings is not the problem at all. One of our customers has 1.9 million per year on a native financial database (18 users) with an “older” HP-server. The problem are the 300 users. How “heavy” are they requesting data from the database?
You should request a copy of the Siemens white paper from your NTR. It will provide you some guidance. Please note that it hasn’t yet been updated (at least that I’m aware of).
Navision Attain 3.01 has much improved performance over 3.0 for the SQL version on the same hardware, in many areas including posting. For Sales Order posting (5 lines), a throughput of around 2500 postings/hour can be achieved with a standard application setup, with this hardware: 2-way 600Mhz machine 500MB RAM Minimum disk payout (3 Disks, no RAID used) The problem, as Walter says, is the 300 users and how much they load the server with their activities (most importantly, how long their transactions are). Along with the amount of server memory needed to support this number of concurrenct connections. This is where scaling becomes a problem and difficult to plan for.
Guys its not that difficult to scale to 300 users… you just need some hardware. Dont be frightened by such a big number. SQL works very well… even at 2.6 level with distribution. Perhaps not at such a high transaction level, but perhaps with 3.x it will be. 2.6 without distribution posts very quickly. SQL is your only choice if you need multiple database servers with multiple processors. As for Axapta… nice technology but even Navision will admit that Navisions functionality is stronger in a lot of areas. Give it time. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
Help! I love this topic because we are in the midst of a NavFin SQL Server implementation and are experiencing significant performance issues. We have 200+ concurrent users and 15,000+ item codes, and are unable to run a MRP regen to completion. Running MRP on 1 item code (with only 1 user on the network) takes 5-10 minutes. We have resources galore looking at this issue, with not a lot of progress. Any comments? Thanks!
Please add some more information, like your Financials-version, do you use SQL2000 or SQL7, describe shortly your hardware, … Did you already use the client monitor to check out what’s happening during the MRP ? (MRP is reservation, right ???)
We have CPUx2 server, 1024 RAM. But… Navision not clearly SQL-oriented application. Maximum of CPU usage for each CPU was ~4% in very huge posting. Navision makes huge amount of small requests for server (give one record, give me another record and so on). He do not understand batch processing. SQL server spends his time for retrieving very small parts of data. HARDWARE must be VERY-VERY-VERY STRONG. :Win2k Advanced Server + 4096 MB of RAM : +fastest HDDs Business Applications Programmer Sertified Navision Developer SIA “Sintegra” Latvia
One tip for an implementation process - if you need to do heaps of processing, and you have a big enough server, then run the processing on the server as well. Generally things wont run much faster on the processing side, but you will gain from no network latency. Small but measureable gains to be had. You can also put clients on the same switch (not hub!) as the server to quick processing. Being on the end of cascaded network hardware etc can really slow things down. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au