如何在 Windows Azure 上使用我的辅助角色中的所有核心？
假设我指定希望我的辅助角色在 4 核虚拟机上运行。如何利用所有核心？
看起来我重写了 RoleEntryPoint.Run() 方法来安装我的请求处理程序。
如何处理使用所有核心的请求？我是否手动生成线程并将处理委托给它们，或者是否有一些现成的巧妙抽象可以帮助自动完成此操作？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您应该按照此处所述在 WorkerRole::OnStart() 中添加多个工作人员 http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/running-multiple-threads-on-windows.html
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
生成线程或使用 .Net 4 任务让 .Net 使用线程池安排您的作业。
Spawn threads or use .Net 4 Tasks to have .Net schedule your jobs using a thread pool.
+1 给 Oliver - 在每个请求上生成 TPL 任务，框架运行时应该处理从那里开始的所有事情。
+1 to Oliver - spawn TPL Tasks on each request, the framework runtime should take care of everything from there.
让所有 4 个核心保持繁忙的另一种方法是将应用程序扩展到 Web 角色的多个实例，以便每个核心都在其实例中运行（请注意，在 Windows Azure 中，每个实例都在其自己的实例中运行）虚拟机）。由于在 Windows Azure 中，您按小时为每个核心付费，因此在 4 个辅助角色实例上各使用一个核心的成本与在单个辅助角色实例上运行 4 个核心的成本相同。
使用 4 个辅助角色实例的好处是，您可以更方便地调整为 3 个、2 个或 10 个实例，具体取决于您在任何时间点需要承担的计算量。更改正在运行的实例的数量很容易 - 您不需要重新部署应用程序。要更改实例的大小，您需要重新部署。此外，只有实例大小的粒度较小：部分、1、2、4 和 8 核。不存在 6 核等实例大小。
另请注意，如果您有单个实例，Windows Azure SLA 不会生效。在各种 SLA 生效之前，至少需要 2 个实例。这在一定程度上是为了让 Azure 的 Fabric 控制器可以更新部分应用程序（例如使用操作系统补丁），而无需关闭整个应用程序。
警告：对于在设计时未考虑到云的遗留代码，当运行多个实例时，代码可能无法正常运行。换句话说，它无法有效地“横向扩展”；在这种情况下，您可以通过在更大的实例大小（例如 4 核）上运行它来“扩展”。
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).