windows azure应用程序所需的实例数

我对Windows Azure相当陌生，希望托管一个调查应用程序，该应用程序将由appr填写。同时有30000名用户

该应用程序由1.aspx页面组成，该页面将发送给客户端一次，询问25个问题，并在最后总结给出的答案。当用户给出答案并点击“下一个问题”按钮时，给出的答案将通过.ashx处理程序发送到服务器。回答是下一个问题和答案。在完全回发后，将向客户端发送总结。 答案保存在一个Azure表中，该表已分区，因此每个分区最多可以容纳450个用户

我想问一下，是否有人可以估计一下，为了让这个应用程序继续运行，我们需要启动多少个web角色实例。（如果这太难说了，那么是否更有可能启动5个、50个或500个实例？）

更好的方法是什么：20个小实例还是5个大实例

---

谢谢你的帮助

最明显的答案是：你最好自己测试一下，看看你的应用程序如何运行。您可以轻松地从Windows Azure获取性能计数器和其他诊断；例如，您可以连接Microsoft SCOM（System Center Operations Manager）以在测试期间监视您的环境。是一个用于Windows Azure的简单负载测试工具（在MSDN代码库上）

除了这个非常明显的答案外，我还将分享一些猜测：考虑到负载的类型，您可能更适合使用更多的小实例，而不是数量较少的大实例，特别是因为您已经对存储进行了分区。如果你真的要同时有3万名访问者，并且在阅读问题和发布答案之间给他们15秒的间隔，那么你每秒会看到2000个请求。10个节点应该足以处理该负载。请记住，这只是一个简单的估计，在您的体系结构中缺乏任何形式的洞察力，等等。对于这些类型的负载，缓存是一个非常好的主意；这将大大增加每个节点可以处理的负载

---

然而，我能给你的最好建议是确保你在积极监控。启动其他实例所需时间不到30分钟，因此，如果您监视您的环境和/或确保在它开始阻塞时收到通知，您可以轻松升级安装程序。请记住，您确实需要联系客户支持部门才能访问20多个实例（这是一个默认限制，用于保护您避免过度消费）。

除了tijmenvdk给您的sage建议之外，让我补充一下我对实例大小的看法。一般来说，使用支持你的应用程序的最小尺寸，然后扩展以处理增加的流量。这样，当您缩小规模时，您的最小计算成本保持在较低的水平。例如，如果您运行一对特大型实例作为基线（因为您总是希望至少有两个实例获得正常运行时间SLA），那么您的成本占用从每小时0.12 x 8 x 2=$1.92开始，即使在低流量时间也是如此。如果你使用小的实例，你会得到0.12x1x2=$0.24每小时

每个虚拟机的大小都与相关的CPU、内存和本地（非持久）磁盘存储有关，因此请选择应用程序有效工作的最小大小单元

---

对于负载/性能测试，您可能还需要考虑托管的解决方案，例如.< /p> 现实中的请求是如何同时发生的？ 他们会在同一时间输入地址吗

也就是说，在本地评测你的应用程序，这将使你能够估计Azure上的CPU、网络和内存使用情况。然后，不要看你需要多少实例，而是看你如何减少需求！应用这些提示，然后再次在本地配置文件

大多数性能提示都会在cpu、内存或带宽与使用量之间进行权衡，其目的是确保它们的可扩展性相等。如果您的应用程序内存不足，但CPU和网络负载很大，请不要这样做

对于单页调查，确保html、css和js缩小，确保其可缓存

如果可能的话，将它们结合起来，为了实现真正的可伸缩性，将静态文件（css、js和图像）推送到CDN。这一切都减少了Web服务器必须处理的请求数量，从而减少了需要的Web角色数量=更少的网络

ashx如何返回响应？i、 是发送html、xml还是json？ 就个人而言，我会让它返回JSON，因为这将需要更少的网络带宽，并且很可能需要更少的服务器端处理=更少的内存和网络

使用异步API访问azure存储（这使用IO完成端口释放iis线程以处理更多请求，直到azure存储恢复=使cpu能够扩展）

tijmenvdk已经提到使用队列进行写入。问题列表有变化吗？如果没有，则缓存它们，这样应用程序只需在启动时从表存储中读取一次，并在最终包装时为每个客户端读取一次=以牺牲内存为代价节省网络和cpu

所有这些技巧同样适用于单个服务器或web场环境中的普通web应用程序

---

我想说的是，你无法衡量的东西，你无法改进，而衡量、改进和成本都是齐头并进的。动态扩展将降低成本，但从根本上说，如果您的应用程序没有经过测量和资源使用优化，询问您需要多少实例是毫无意义的。

嗨，Tijmen，谢谢您的评论。我们开始了负载测试，但由于我对这门学科相当陌生，所以最好不要重新发明轮子。。。这项调查有些不同：所有30000名观众都在观看一个节目，并将同时回答这个问题。这将使每秒的请求数提高到大约10.000。我们使用缓存、单例类，目前正在对解决方案进行优化，以使其