>>>>Luc,
>>>>
>>>>I would stop focusing on hardware. You might squeeze a few percent more performance out of it, but you can get much and much more performance gains (up to 10.000% and more) when you look at your application. Identify slow parts and try to tune them.
>>>>Are there slow queries? If so, try to rune them by adding or tuning indexes. You might want to redesign queries to run faster.
>>>>
>>>>Walter,
>>>
>>>I'm not complaining about the speed of the ERP software. It is running nicely.
>>>I was just surprised that after moving the virtual machine from a 5 year old server with less memory to a new server with all the top notch hardware improvement and 64Gig of memory the gain in performance was not that significant.
>>>
>>>This means that the 4Gig limit was already obtained on the previous server and adding more memory had no effect on the application on the new server.
>>
>>We've already been over this. I suspect even on the old server, all the significantly used data files were disk-cached in RAM. So with the new server:
>>
>>- the data files are also cached in RAM
>>- CPU performance per core is not a lot better than the old server
>>
>>So, not surprising the new server isn't much faster than the old one.
>>
>>If someone's giving you grief because they paid $$$ for a new server and expected more performance gain, well, that's too bad. But facts are facts.
>>
>>The general consensus seems to be that configuring VFP to use more RAM can be counterproductive. But, your mileage may vary. You could run some tests and let us know.
>>
>>If you do find some hardware/configuration "secret sauce" that speeds things up significantly, could you let us know?
>
>
>The new server is also running an Office VM, all users have outlook, excel... installed on it and this one loves RAM.
>I think that Foxpro was already at it's limit on the old server and even if I added more ram on the new one there was not much impact.
>
>I will concentrate on IO for the next server. Probably a RAID-10 of PCI SSD...for now they are too expensive.
>
>For sure I'll keep you informed.

Hmm... I think you might be missing the point about disk caching in RAM. Consider this scenario:

1. Cold start your TS VM, which has been allocated lots of RAM

2. Fire up one TS session and run the ERP app. Run ERP functions that access most or all of the commonly used data. Take note of the initial performance - time to load forms, get results etc. This initial data access is where you see a win using PCI SSD instead of conventional magnetic drives.

3. After you do this, the ERP data are cached (basically, copied) in RAM. The purpose of a cache is to snoop on file I/O requests; if they can be serviced from the high-speed cached copy in RAM they will be, and the actual physical or VDISK file will not be touched. This is extremely effective for read-mostly access patterns typical of business-oriented database programs. After the initial data load into disk cache, the physical drive or VDISK will hardly be accessed at all.

4. Now, start up a second session on the TS VM and run ERP. You will find ERP performance will be immediately fast. It's not pulling any data from disk/VDISK, it's all coming from the RAM disk cache.

5. You can keep adding new TS sessions until you exhaust available RAM (at which point the TS VM will have to start paging to the physical or VDISK and/or the disk cache size is reduced until it's no longer effective). Or, you start to hit CPU limitations. As long as you can avoid these exhaustions each ERP session will be as fast as the second one, or any other one after the initial data load in the first session.

If you have tons of RAM, all the fast disk subsystem is buying you is quicker initial data load (step 2 above), plus better performance on any write operations that may be going on. I don't know why you'd want to spend a ton of money speeding up just step 2, which will have little or no effect on sustained performance.

Yours sounds like a case where you might be better served getting higher-performance RAM memory:

- quad-channel DDR4
- highest memory speed combined with lowest available latency

Also, if you have any significant periods of time when a VCORE is pinned at 100% utilization, you could consider getting the fastest possible server CPUs. However, high-speed server CPUs with high core counts are expensive, you should be certain you actually have a bottleneck there before investing in them.

Enthusiast/performance desktop chips with low core counts offer the highest clock rates, which can usually be increased with careful overclocking. Coupled with lots of fast RAM these offer the highest possible performance for single-threaded applications such as VFP. However, these aren't suitable to support lots of TS users - for that you need lots of cores and ability to access a ton of RAM, which is where the Xeons come in. The downside to the Xeons is typically lower clock speed per core than what is available in the fastest desktop chips.

If your current server is from a tier-1 or equivalent vendor, you're probably close to, or already at, maximum available performance for VFP apps in TS sessions. If you have unlimited funds you can keep spending money on even faster components but the ROI may be nonexistent, further gains are likely to be incremental at best.

If you still want or need big gains, you may need to optimize the coding of the app itself.