Date:  09/26/2009 05:23:58 AM Msg ID:  004038
From:  Michael Haggis Thread:  004011
Subject:  Re: Multiprocessor Performance Issues
You may want to do a simple test with a vfp mtdll and look and see if it does in fact take advantage of multiple cores.  If it does, that's one possible way to take advantgae of the hardware.  If it doesn't, then you know you've hit the limits with vfp :(
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,
TechniScan, Inc.