How do I make use of all cores in my worker role on Windows Azure?

Suppose I specify I want my worker role to run on a 4-cores virtual machine. How do I make use of all cores?

Looks like th开发者_开发技巧ere's RoleEntryPoint.Run() method that I override to install my requests handler.

How do I handle requests to make use of all cores? Do I manually spawn threads and just delegate processing to them or is there some ready clever abstraction that will help do it automatically?

---

You should add multiple workers in the WorkerRole::OnStart() as described here http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/running-multiple-threads-on-windows.html

---

Spawn threads or use .Net 4 Tasks to have .Net schedule your jobs using a thread pool.

---

+1 to Oliver - spawn TPL Tasks on each request, the framework runtime should take care of everything from there.

---

Another way to keep all 4 cores busy is to scale your application out to multiple instances of your Web Role such that each core is running in its instance (note that in Windows Azure, each instance runs in its own virtual machine). Since in Windows Azure you pay by the hour for each core, using one core on each of 4 Worker Role instances will cost the same as running 4 cores on a single Worker Role instance.

The benefit of using 4 Worker Role instances is that you can adjust more conveniently to 3, or 2 - or 10 - instances, depending on the amount of compute you need to bring to bear at any point in time. Changing the number of running instances is easy to do - you do not need to redeploy the application. To change the size of the instances, you need to redeploy. Also, you have less granularity with just instance size: partial, 1, 2, 4, and 8 cores. There is no instance size with, say, 6 cores.

Note also that the Windows Azure SLA is not in effect if you have a single instance. A minimum of 2 instances is required before the various SLAs kick it. This is in part so that Azure's Fabric Controller can update parts of your application (such as with an O/S patch) without taking down your whole application.

Caveat: for legacy code that is not designed with the cloud in mind, it is possible to have code that will not function correctly with more than one instance of it running. In other words, it can't "scale out" effectively; in this case, you can "scale up" by running it on a larger instance size (such as with 4 cores).