I’m experiencing a very poor performance while using Navision 3.7. The hardware that’s being used:
Compaq Proliant ML370 1.4GHz 1*P-III CPU (average usage 10%, peaking to 60%)
2 GB internal memory (usage steady at 1.64 GB)
Smart array 5i controller, 16MB read cache
6 internal WU3 SCSI disks 10K Rpm (2 in raid 1 for OS, 4 in raid 0+1 for DB)
network is 100MB switched
wild variety of clients (w98-2003) all using 100MB switched connections
Navision C/Side DB settings:- Size is 8 GB (4 segments of 2 GB each, 23% of free space)
Commit cache enabled
1 GB Cache, 8 MB ObjectCache
Application is version 3.01.B, client/server 3.70.A
Average of 60 concurrent users
The table optimizer is scheduled to run on a daily basis.
Besides the usual client data-entry, reporting etc. we have one typical client: interface into our APS environment using ODBC. The interface runs with a frequency of twice per minute. Any suggestions as to how to measure and improve performance (as perceived by the end-user)? I’m wondering if there is any improvement to be gained by changing database storage:- now: 1 logical drive (single partition) based on raid 0+1 of 4 physical disks, containing 4 database segments.
option1: keep logical drive as is, store DB in a single segment
option2: rebuild to 2 logical drives (each single partions) based on raid 1, store DB in two segments (one on each drive)
Final, rather costly option; order new HW based on SAN storage.
Recently we tried to figure out if there was a risk in activating the commit cache. It seems impossible to get a description as to how this cache works. Talking to my NSC I got the impression that it is fairly safe to use it but I’m still not sure. What if the server crashes while there is still some data in the cache? What information is stored in commit cache? And in what order is this information written to disk? Anyway, performance is such an issue we decided to activate commit cache. Nice thing is we have a tool (client report) which merely uses the disk performance tool to write the read/write times to a logfile. And now, the curious part: Before using commit cache: read avg: 7 msec (with peaks up to 30 msec) write avg: 9 msec (with peaks up to 100 msec) After enabling commit cache: read avg: 9 msec (with peaks up to 30 msec) write avg: 19 msec (with peaks up to 100 msec) Lukily, the end-user is perceiving a slight performance improvement. But I’m puzzled, what tools are there to get a measurable indicator for the performance? While I’m at it; anyone suggestions for some good reading on performance tuning? So far I’ve been looking into “Installation & System management” (w1w1ism.pdf) and mibuso.
Hi, refer your NSC to a Whitepaper/Tool called “Performance Troubleshooting Guide”, which should help to identify your performance problems. The “Performance Troubleshooting Guide” can be downloaded in Partner Guide/PartnerSource. br Josef Metz
What performance counters are you looking at? The queue … counters are the most important you now. What is slow? which tasks, is it faster on the server itself?