>I'm pretty sure each EXE is single-threaded, but Web Connection can load multiple instances of the EXE, and therefore make use of multiple processors (assuming the EXEs get split among the processors). Seems like I heard somewhere that VFP uses two threads internally, but I can't remember for sure.

Threads are marshalled by the ISAPI application, so the ISAPI interface controls the threads that are passed to the Web Connection servers. Since ISAPI is multi-threaded the answer is yes WWWC works just fine on multiple processors.

>In my testing, MTDLLs are truly multi-threaded. Multiple processes can run simultaneously in a single runtime environment. This should mean lower overhead than loading up multiple EXEs.

Nope. MTDLLs are no more multi-threaded and EXE servers in the true sense. What happens behind the scenes is that COM isolates each instance of the object on a separate thread and VFP stores all of its local stored state in Thread Local Storage. But there's no binary multi-threading where the same code in memory is run by different threads. This is a simulation of multi-threading that happens through some fancy footwork of the COM subsystem. Objects load and unload on each hit, although the runtime is cached through some COM tricks (extra COM references which basically locks it into memory - this is why you can't unload a VFP COM server after having been loaded into ASP/ASP.Net).

There are also downisdes to this like two components on the same thread share the same VFP instance and environemnt, which maybe good or bad depending of how your components are designed.

EXE servers get a bad rap, but there are a number of important benefits that you just can't do with DLL servers:

* Manage the server remotely (start, stop, hold, update etc)
* Recover from failures
* Keep state

All of these are related to the fact that EXE servers are external to the calling process and can be monitored and managed through the ISAPI interface (or through an external watcher application). DLL servers are hosted inside an uncontrolled aplication (IIS).

In fact if you look at the architecture of ASP.Net you'll see that it uses Out of Process components (not with COM, but named pipes in this case) that to do exactly that - an external process that can be managed is controlled by a small ISAPI extension. This is smart design as it amkes it posssible to put metrics and maintenance smarts into the server so it can fix itself on failures and allow things like automatic updates without shutting the Web server down. Heck, that's the way Unix has been doing server design since the eaerliest times of server applications (daemons).

All that said, MTDLLs work well, and they are very fast in loading etc. and they've gotten faster yet with IIS 6. But the load speed is also diminished by the fact that you have to re-establish your complete environment on every hit, you can't leave tables open or connections established which overall causes more slowness than any COM overhead might. If you have an application with large VFP tables or tables that sit on the network your performance will be crippled by the requirement to re-open tables on every hit.

OTOH, these days performance is not nearly as much as an issue as it used to be. Today the hardware is so fast that all but the biggest applications cause a server to not be able to handle traffic on a single box. The big exception to these things are CPU heavy applications and in those VFP in general is a problem, and the overhead of calling a MTDLL or EXE component is not an issue in the first place.