>>>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...

Are you 100% sure it isn't CPU-bound? The way I would test it:

1. Make sure no-one else has a user session running on the TS
2. Start up a session on the TS and fire up Task Manager. Make sure you can view the utilization of all the virtual CPUs allocated to the TS VM
3. Start up another TS session. Run the ERP system, access some function that is "slow" and takes some time to run (say, at least 5 seconds) - maybe a report
4. See if one of the VCPUs in Task Manager in the first session is pinned at 100% utilization for any length of time

If you just look at global CPU utilization you can get the wrong impression. Suppose you do the above test and you have 10 cores allocated to the TS VM. If the TS is not busy doing other things, and ERP does pin one of the VCPUs then the peak global CPU utilization you'll see will probably be only about 15%. That's why you have to look at the VCPUs individually while you run the ERP test.

Since you haven't seen a big gain going from magnetic HDs to the PCI SSD, disk subsystem was not the bottleneck. I can think of 2 possibilities:

1. ERP is actually CPU-bound

2. Your total data set for ERP is small enough to fit in the disk cache of the TS VM. So, once the ERP table data are loaded for use in ERP, there isn't much I/O back and forth to the underlying disk subsystem. You would see a faster initial load from the SSD, but after that not a big gain, especially if you have write caching enabled

As a side note, that's one of the beauties of a TS - its disk cache can cache the ERP tables globally for all users without using any extra RAM.

As an extra data point, what's the total size of all the tables in the ERP? Or, at least the tables that are regularly accessed (not counting archives etc.)

I'm a sysadmin as well as a developer. When someone complains to me about performance the first question I ask is:

- Do you have a specific performance issue you need to address, or

- Do you just want assurance that the app is running as fast as it possibly can?