Hi Luc,

VFP can only use the first 2GB of memory. So the total memory usage of all your VFP users has to be kept below that total. If you assign more memory, it will be swapped out to the pagefile. If you see it using more than that for your app, totaling all current users, it is using the swapfile.

Pulling the data from the SAN will be as much the issue as anything. Having a ramdisk (we use IMDISK) of 8GB will accommodate 20 users (set the temp directory with tmpfiles in config.fpw; target a directory on the ramdisk to handle security issues that can arise with writing to the root directory of a drive). That's about all you can do. Hyper-v is better at handling disk access than VMWare, I am told. In VMware, for a form opening with 37 cursors against MSSQL, we see a 30% or greater speedup on form opening, from ~5 seconds to ~3.25 seconds. There are several tweaks to make that happen, but they apply to working against MSSQL, not dbf's.

The near-universal consensus is to turn write caching off to avoid dbf corruption.

BTW: you are nearly out of dbf space given that 1.7GB file.

Hank


>>>I'm talking about Visual Foxpro settings for memory, temp files settings...
>>>The server is optimized for performance.
>>>
>>>
>>>I've tried giving the virtual machine 48 Gig of memory, 32 Memory, 24 gig of memory and didn't see any improvement
>>>
>>>>If you're doing a lot of heavy processing within VFP and need high performance of VFP within a TS session, you're probably already most of the way there by having lots of RAM available and an extremely fast PCI-based SSD. However I believe there are some circumstances where VFP by default may allocate more >RAM than is required for maximum performance, and performance can actually suffer as a result. I think Thomas Ganss has some experience with this, maybe >he can offer some advice.
>>>
>>>
>>>The ERP application was originally running on a RAID10 of 15K SAS drives with about 12Gig Ram.
>>>Now it is running with PCI-SSD drive and more RAM but doesn't seem to perform better.
>>>
>>>Since Foxpro is 32 bits, can it use or take advantage of more then 32 GIG of memory ?
>>>
>>>Also what would be the settings for to Adjust the memory needed with sys(3050,1) and sys(3050,2) as per Fernando?
>>>Should I create a "Ram disk" to allocate temp file ?
>
>>VFP as a 32-bit user process has a maximum 2GB address space: https://msdn.microsoft.com/en-us/library/aa366778%28v=vs.85%29.aspx . There is some >discussion about limiting memory usage on systems with lots of RAM at http://fox.wikis.com/wc.dll?Wiki~sys3050~WIN_COM_API . The final >recommendation there is to not exceed 512MB no matter how much RAM you have. I haven't worked with large tables (largest only 100MB or so/1M rows) and >I don't explicitly limit RAM via SYS( 3050 ), but the highest RAM usage I've seen in production is only around 250MB.
>
>>I *think* the above gybes with Thomas's experiences, hopefully he'll chime in.
>
>>Where more RAM can help on 64-bit systems is as disk cache. If all the tables in your ERP databases total, say, 4GB, that can all be cached in RAM after >initial load. That can be a big win with magnetic disks. With your PCI SSD maybe not as noticeable.
>
>>You sound like you've got an ideal situation for RAM and disk subsystem. That leaves CPU. As I explained earlier, VFP is single-threaded and will use only a >single physical or virtual processor core. Modern Xeon server processors can have 10+ cores with large L1, L2 and L3 on-chip caches but one area that hasn't >advanced much in recent years is performance per core. Stock performance without overclocking typically tops out at around 4GHz with gaming-oriented >desktop CPUs. Server CPUs are typically less, their forte is total processing throughput across many cores.
>
>>This is easy to check. Fire up Task Manager and look at CPU utilization as you run the app. If one core spends most or all of the time at 100% utilization, or at >least when active and not waiting for user input, then it's CPU-bound.
>
>>You don't say how many cores you have on the server, or how many simultaneous TS sessions you need to run. For Hyper-V, rule of thumb is to leave 4GB >RAM and a couple of CPU cores for the host OS. You can allocate the rest to the Hyper-V VMs. The beauty of 1 or more core-heavy Xeons is that lots of >simultaneous users can basically each get a core dedicated to them, but even if only 1 user is on the system its speed won't exceed the performance of a >single core (other than the slight bump offered by Turbo Boost or similar).
>
>>I would definitely rule out or confirm the app being CPU-bound before trying anything else like RAM disks.
>>Regards. Al
>
>>"Violence is the last refuge of the incompetent." -- Isaac Asimov
>>"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
>
>>Every app wants to be a database app when it grows up
>
>On that terminal server there is 20 users running only the Foxpro v9 ERP
>I can used 50 Gig of RAM if needed to get better performance but I I'm not sure if FoxPro is using what is available to it.
>
>The ERP is definitely IO Bound and Not CPU Bound
>
>As mentioned in the in your second link:
>
>SYS(3050, 1, MIN(536870912, VAL(SYS(3050, 1, 0))))
>SYS(3050, 2, MIN(536870912, VAL(SYS(3050, 1, 0))))
>
>Every terminal session will use 1/2 Gig for foreground and 1/2 Gig for background = 1 Gig
>
>Is my reasoning ok: if I have 20 users * 1 Gig = 20Gig of RAM ? This is the CAP Foxpro can manage.
>
>My underlying question was. What would be the best Foxpro Settings if you would have 64Gig of RAM available to run your application. It seem that beyond that 20 Gig threshold for 20 users there is not much to gain...