>>>>>>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.
>>>>
>>>>You simply don't need that much unless you have many hundreds of busy users. Try limiting the VFP app's RAM to 128M. I've never seen a VFP app benefiting from half a gig and we do extremely heavy munging of cursors with tens of millions of rows.
>>>>
>>>>>>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...
>>>>
>>>>Check on the fox.wikis.com wiki: in the old days a server with just 4 Gig was expected to deliver satisfactory TS performance for 50 VFP users.
>>>>
>>>>We have customers with hundreds of TS users on far lesser hardware than yours. A few things to consider:
>>>>
>>>>- As an experiment, run the app on another PC on the same domain/router as the TS machine with identical apps runtimes etc. Is it slow?
>>>>- Make sure each user has their own temp folder which is the TS default. Sharing a temp folder can cause contentions and slow things down.
>>>>- Don't forget the wretched virus scanner! VFP creates and manipulates files at frenetic speed and a server virus scanner that scans the temp folder (often a default) will briefly seize VFP temp files, causing slowdowns or file access errors. You can exclude file types (.dbf/.fpt etc) but an easy solution is to create your own temp folders and add them to the scanner's exclude list which means the scanner can keep an eye on the normal temp folders that can be a vector for hackers.
>>>>- Check paths to data or required files. If the app is walking a complicated network to find a table or file, it'll be slow. Ditto printers, even if the printer is right beside the user it's worth checking how the TS server locates it.
>>>>- Where is the data stored? VFP tables on a file server? If so, check indexes: an unoptimized locate or select can draw a whole table across the wire. Get 50 users doing that and you can expect slowdowns.
>>>>- If you have grids or browses against tables with a SET FILTER- that is a notorious cause of performance issues. A Remote or Local view has the same effect and significantly speeds things up if your filter can be optimized.
>>>>- Make sure VFP runtimes, app/exe files and ideally lookup tables are on the TS server itself or a direct SAN so they're always accessed locally rather than across the wire. For TS I'd advocate putting all the required runtimes in the app folder to maximize your control.
>>>>
>>>>Are you able to say a little more about the slow performance?
>>>
>>>
>>>I'm not complaining that it is slow, I want to know what are the optimal settings to get maximum performance out of Foxpro.
>>>The application is well written and is behaving nicely. It's using DBF on really fast local disk (PCI-SSD)
>>>
>>>With that much ram I could create a RAMdisk to strore tmpfiles like you mentionned
>>
>>I'll say that every one thinks their app is well written and behaving nicely - until someone like me shows that it is not. There are a ton of misconceptions about how FoxPro works. I have seen many apps which gained significantly by changes to the code, not the hardware.
>
>
>You may be right but lets say it's behaving nicely with 4 Gig of RAM.
>Performance should improve if I increase memory to 24Gig or 48Gig of 64Gig unless there is something that is stopping it from improving.
>
Don't think so

Think increasing RAM ( see sys(3050)) can make a vfp app go slower.
See here http://fox.wikis.com/wc.dll?Wiki~sys3050