As I mentioned in the past, each FoxWeb channel is a separate VFP process, so the operating system should distribute it to a different CPU. Are you still running in a virtualized server, or on native hardware? Also, you mentioned that you are only seeing 1/4 CPU utilization (1/16 on the 16-core server). How are you making this determination? Are you using Task Manager? I recommend Process Explorer, which provides a lot more information, but regardless, you need to make sure to configure your tool to display a separate graph per CPU. In Task Manager this is done in the View/CPU History menu.
It's quite possible that what you are seeing is not a single CPU utilized 100%, but rather multiple CPUs utilized fractionally. If this is the case, then your bottleneck is elsewhere.
FoxWeb Support Team
support@foxweb.com email |
Sent by Dan Rutz on 02/28/2011 11:59:17 AM:
I'm working with a consultant to try to come to a better understanding of a pattern we've observed a couple of times per the question below and any insight on this would be helpful.
In a 4 core server setup running Windows Server 2008 R2 we see about 1/4 of total CPU being used for FoxWeb application. In a 16 core server setup running Windows Server 2008 R2 we see 1/16 of total CPU being used for the processes. On both servers we ran tests with 16 FoxWeb channels configured and a number of simultaneous requests processed. Application performance in both environments are comparable. We are running FoxWeb version 4.3 and VFP runtime version 9. Is there a way to configure the system to take advantage of multiple cores?
Thank you,
Dan Rutz
Sent by FoxWeb Support on 09/03/2009 01:52:06 PM:
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.
FoxWeb Support Team
support@foxweb.com email |
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.