我是 Windows Azure 的新手，我想托管一个调查应用程序，该应用程序将由 appr 填写。同时有 30.000 名用户。
该应用程序由 1 个 .aspx 页面组成，该页面将发送给客户一次，询问 25 个问题，并在最后给出给定答案的总结。当用户给出答案并点击“下一个问题”按钮时，给定的答案将通过 .ashx 处理程序发送到服务器。响应是下一个问题和答案。在完整回发后，总结会发送给客户端。答案保存在已分区的 Azure 表中，因此每个分区最多可容纳 450 个用户。
我想问一下是否有人可以估计我们需要启动多少个网络角色实例才能让这个应用程序继续运行。（如果这很难说，是不是更有可能启动 5、50 或 500 个实例？）
有什么更好的方法：20 个小型实例或 5 个大型实例？
谢谢你的帮助！
最明显的答案是：您最好自己测试一下，看看您的应用程序如何运行。您可以轻松地从 Windows Azure 中获取性能计数器和其他诊断信息；例如，您可以连接 Microsoft SCOM (System Center Operations Manager) 在测试期间监控您的环境。Site Hammer是一个简单的 Windows Azure 负载测试工具（在 MSDN 代码库上）。
除了这个非常明显的答案之外，我将分享一些猜测：考虑到负载的类型，您可能最好使用更多的小实例而不是较少数量的大型实例，特别是因为您已经对存储进行了分区。如果您真的要同时拥有 30K 访问者，并在阅读问题和发布他们的答案之间给他们大约 15 秒的间隔，那么您每秒会看到 2,000 个请求。10 个节点应该足以处理该负载。请记住，这只是一个简单的估计，对您的架构等缺乏任何形式的洞察力。对于这些类型的负载，缓存是一个非常好的主意；它将大大增加每个节点可以处理的负载。
但是，我能给您的最佳建议是确保您正在积极监控。启动额外实例只需不到 30 分钟，因此如果您监控您的环境和/或确保在它开始阻塞时收到通知，您可以轻松升级您的设置。请记住，您确实需要联系客户支持才能超过 20 个实例（这是一个默认限制，可以防止您过度使用）。
除了 tijmenvdk 给您的明智建议之外，让我补充一下我对实例大小的看法。通常，使用支持您的应用程序的最小尺寸，然后横向扩展以处理增加的流量。这样，当您缩减规模时，您的最低计算成本就会保持在较低水平。例如，如果您运行一对超大型实例作为基准（因为您总是希望至少两个实例来获得正常运行时间 SLA），那么您的成本足迹从 0.12 x 8 x 2 = 1.92 美元/小时开始，即使在低-交通时间。如果您使用小型实例，则每小时的费用为 0.12 x 1 x 2 = 0.24 美元。
每个 VM 大小作为关联的 CPU、内存和本地 9non-durable) 磁盘存储，因此请选择您的应用程序有效运行的最小大小单位。
对于负载/性能测试，您可能还需要考虑托管解决方案，例如Loadstorm。
这些请求在现实中的同步程度如何？他们会同时输入地址吗？
也就是说，在本地分析您的应用程序，这将使您能够估计 Azure 上的 CPU、网络和内存使用情况。然后，与其查看需要多少实例，不如查看如何减少需求！应用这些提示，并再次在本地配置文件。
大多数性能提示在 cpu、内存或带宽使用之间进行权衡，其想法是确保它们平等地扩展。如果您的应用程序内存不足，但您有大量 CPU 和网络，请不要
对于单页调查，确保您的 html、css 和 js 被缩小，确保其可缓存。
如果可能，将它们组合起来，并获得真正的可扩展性，将静态文件（css、js 和图像）推送到 CDN。这一切都减少了网络服务器必须处理的请求数量，因此减少了您需要的 webroles 数量 = 更少的网络。
ashx 如何返回响应？即它是发送html、xml 还是json？就个人而言，我会让它返回 JSON，因为这将需要更少的网络带宽，并且很可能需要更少的服务器端处理 = 更少的内存和网络。
使用异步 API 访问 azure 存储（这使用 IO 完成端口来释放 iis 线程以处理更多请求，直到 azure 存储恢复 = 使 cpu 能够扩展）
tijmenvdk 已经提到使用队列来编写。问题列表会改变吗？如果没有，则缓存它们，这样应用程序只需在启动时从表存储中读取一次，并且为每个客户端读取一次以进行最终总结 = 以内存为代价节省网络和 CPU。
所有这些技巧都同样适用于普通的 Web 应用程序，在单个服务器或 Web 农场环境中。
我想说的是，你无法衡量的东西，你也无法改进，衡量、改进和成本都是齐头并进的。动态扩展将降低成本，但从根本上说，如果您的应用程序没有被测量和资源使用优化，那么询问您需要多少实例是没有意义的。