>>>>>>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.
>
>Hi Al
>
>I know for a fact that a VFP exe is repeatedly accessed as the user triggers parts of the app. I've watched it happen with performance monitor. Can you say that TS caches the exe so that all users share it? I also remember that because it is shared, making it read-only was at one time a sneaky trick to make accessing it faster.

I never delved too deeply into the details but it's my understanding a TS does, in effect, load only one copy of certain files such as EXEs (and maybe some DLLs) regardless of how many sessions use them. ISTR the mechanism was something like this:

- A session requests an EXE
- The TS host OS doesn't actually load the EXE into the session's allocated RAM/address space. Instead, it loads it local to itself and provides the session with a handle/pointer to that EXE. The session can then request part or all of that file using the handle
- If another session wants the same EXE, the host OS just gives it another handle

The net effect is only one copy of the EXE is loaded by the host OS, and RAM usage by sessions using that EXE is reduced compared to what it otherwise would be. This was A Big Deal back in the 32-bit TS days with limited RAM and address space. I don't know whether it's still the case with modern 64-bit TSs.

Assuming my memory of the mechanism is correct, I'm not sure "caching" would be the best term for what's happening. It's more like file sharing. But, the shared file is in RAM, and nothing actually gets loaded when subsequent sessions request the same EXE (other than a new handle). So from a performance POV it's as if the EXE is cached.

Even if EXE sharing doesn't happen with modern 64-bit TSs, chances are a frequently-accessed EXE would still end up conventionally cached in the TS's allocated RAM. So, requests to it would still not hit the physical disk subsystem or VDISK.

Re marking EXEs read-only: ISTR there used to be some performance benefits back in the days of Windows 3.x, if you were accessing them from a network share. The network redirectors of the day would load files in shared mode unless they were marked read-only. The performance difference was something like the difference between USE ... SHARED and USE ... EXCLUSIVE.

I think in the early Novell days, EXEs stored on the server could only be shared if they were marked read-only. Also, it was a simple line of defense against some early viruses/worms that would try to hook EXEs and didn't know how to change file attributes.