Virtualization As a Way To Multi-Task

[sflaum]

We have developed a compute-bound, long-running (several hours) app, which we sell commercially. We’d like to make it run faster.

Although our app is now single-threaded, the computations could easily be partitioned into several parallel threads. However, each thread would need an instance of Excel. Unfortunately, you can run only one instance of Excel per Windows instance. Therefore, we’re thinking of having our app’s main process open multiple VMware Workstation boxes, each with its own instance of Windows & Excel. The main process would then allocate computation between the VMware boxes. Each of these boxes would write its results to a file and the main process would merge these results.

Is this practical? How efficiently would multiple VMware Workstation instances use multiple cores? How difficult would this be to program? Where can I find technical information on how to do this?

Does VMware have an OEM program which would allow us to distribute VMware Workstation as a part of our product?

Thanks.

[Student_Driver]

You might be better off releasing it as a "VM appliance" rather than bundling it with VMware Workstation, and if it's some that's server-based, you might want to try it in ESX, as the server would consolidate most of those pages of RAM and scale better. Just a thought.

Dell SXPS 1340, P9600, 8GB RAM

MCSE/MCSA 2003, MCTS, RHCT

[ClayMon]

Excel can run more than once per Windows installation by running multiple instances with different user accounts. Use the RunAs command to test it. After changing to the Office12 directory from the CMD prompt, I used this line:

runas /user:TestUser excel.exe

Entered the password when prompted and the 2nd instance of Excel launched next to the already running program.

So, I would suggest creating a 'service account', or more than one if needed, for launching Excel. This could all be coded in VBscript and certainly in high-level languagues, and it will certainly be easier to manage, and license, than using VMware's wonderful products.

[sflaum]

Thanks. I appreciate the suggestion.

Stephen (Steve) Flaum

sflaum@CommissionCalc.com

(888)962-6667 x24

[sflaum]

I didn't know you could do that. Thanks.

I'll have to do some research on how to communicate between different users (perhaps by sharing files, but maybe there's a better way) and enter passwords programmatically, but it seems that there must be a way to do those things. Also, a little Googling found ways to "impersonate" a user that, at first glance, seem specifically designed for programmatic use, such as http://msdn.microsoft.com/en-us/library/ms730088.aspx/ . This might or might not help.

I appreciate the suggestion. As I said, I didn't know there was a way to run multiple instances of Excel.

Stephen (Steve) Flaum

sflaum@CommissionCalc.com

(888)962-6667 x24

[ClayMon]

Yes, impersonate is one way to go. All these steps could be coded in VBscript, even controlling Excel, so the higher languages must be able to do this.

You could try using Named Pipes or use a small Access database for communicating between threads. VBscript can create and manipulate .MDB files so Access doesn't have to be installed.

[sflaum]

Thanks again. I've never used either Named Pipes or impersonation, so I'll have to do some research to figure them out, but you've given me a good start.

If (after I figure out how named pipes work) I decide that communicating via the disk is the way to go, using a database instead of flat files makes sense. My app already uses Microsoft SQL Server heavily, so I might as well stick with that.

Stephen (Steve) Flaum

sflaum@CommissionCalc.com

(888)962-6667 x24

[ClayMon]

Yeah, if you've already have a database in play then I would think that is the way to go, unless there is a high rate of communication.