VFP programs run on a single thread, so you would definitely not see an increase in performance on a multi-processor system (all else being equal) and I would actually expect a small drop. However, a 50% drop is surprising. It's possible that the problem would not manifest itself in a regular multi-processor environment (as opposed to running within VMWare). Also, I can guarantee you that you will see a significant jump in performance if you run on native hardware, instead of inside a virtual machine.
One factor that should be considered is the overall performance of your server. Even if individual scripts take longer to run, each CPU will be able to handle a separate script, so you should be able to get at least twice the overall performance with 4 cores (4 x 1/2 the performance of a single core).
FoxWeb does not control the processing of programs by VFP, so none of its settings would help you. In fact, I bet that you will see identical results if you run the same report in a regular VFP program. Each channel runs as a separate VFP process, so the operating system SHOULD be able to optimize performance for your hardware. From past experience (unrelated to FoxWeb) I have found that trying to be too smart with processor affinity/management will only hurt performance.
Sent by techniscan on 09/03/2009 01:04:13 PM:
First of all, thank you for producing such a great product! We have been using FoxWeb to generate PDF reports for our clients on our website since 2002, and are currently running Version 3.51 (Vfp9, using run-time DLL, not as service) with 4 channels on a Win2K-SP4 VM with IIS5 (ISAPI ...\CGI\FoxWeb.DLL). We are now migrating from a four year old VMware GSX single core host to a much faster VMware ESXi host with 4 cores and a very fast RAID array.
The old VM was configured with a single virtual processor, and the Win2K had an ACPI Uniprocessor HAL. When initially migrated to ESXi the Win2K retained the Uniprocessor configuration, and the performance improvement was in the order of 300% during our single-channel benchmark set of reports. ESXi reported (as we expected) that all of the work during the single-channel benchmark (or multichannel stress tests, for that matter) was being done by only one of the machine's virtual processors, since the Win2k VM was configured as a uniprocessor. So far, so good.
Next we reconfigured the VM with 4 virtual processors and Win2K with an ACPI Multiprocessor HAL. Our benchmark performance numbers for the VFP portion of our report generation dropped significantly (nearly 50%), but the performance of the GhostScript (postscript to PDF) portion of the benchmark remained high -- essentially unchanged. Curiously, ESXi reported that the single-channel benchmark activity was spread nearly equally over all four virtual processors.
We realize that there could be hundreds of factors involved in the drop in performance of a VFP report generator (~30 second clock time single .fwx generating a report from a single .dbf located on a directly connected RAID array). We also understand that a multiprocessor configuration has inherent overhead. But 50% for the VFP part and nothing noticable for the Ghostscript? Running FoxWeb as a service did not help. Turning off "hyperthreading" in both the virtual processors and physical cores also did not help.
Based on your experience, are there any FoxWeb configuration options that mitigate the VFP9 performance degradation in multiprocessor environments? Is there a way to have FoxWeb utilize the "thread safe" VFP9T.DLL in lieu of the VFP9R.DLL default (and if so, does it matter)? Are there ways to attach any given channel (or VFP thread) to a specific processor? Or, tossing the multiprocessor option, is there a trivial way in FoxWeb to dispatch the work to multiple single-channel uniprocessor VMs?
Thanks for your help,