>OK. I was thinking that there would only be one copy of the runtime for n MTDLL servers. I was thinking that the runtime was the bottleneck. But if each MTDLL gets its own runtime, then I guess there is no point to having multiple MTDLLs. I was thinking that I would have some potentially long processes going, and anything sharing the MTDLL with the long process would be slowed down but having discrete MTDLLs going would lessen the chance.

Not an issue. APM threading will take care of that. CPU load is what you need to worry about here, but there's nothing you can do other than make sure that you have appropriate server resources for hte situation.

>Also, since VFP would be apartment threaded any one MTDLL would live on a single processor. So if I have a dual-processor server box and 2+ MTDLLs I could get each one to round-robin its load on the least-used CPU until the MTDLLs were spread between each one. With just one MTDLL it would always live on CPU zero, right?

No. COM objects get marshalled to specific threads or start on a new thread if there isn't one in tcalling apps pool. Whereever the thread is created is where it runs. The OS handles this for you and moves things off to any of the available processors.