Windows Azure 应用程序所需的实例数
我对 Windows Azure 相当陌生，想要托管一个由 appr 填写的调查应用程序。同时有 30,000 个用户。
该应用程序由 1 个 .aspx 页面组成，该页面将发送给客户一次，询问 25 个问题，并在最后总结所给的答案。当用户给出答案并点击“下一个问题”按钮时，给出的答案将通过 .ashx 处理程序发送到服务器。回应是下一个问题和答案。完整回发后，总结将发送到客户端。 答案保存在已分区的 Azure 表中，以便每个分区最多可容纳 450 个用户。
我想问是否有人可以估计我们需要启动多少个 Web 角色实例才能让该应用程序继续运行。 （如果这太难说了，启动 5 个、50 个还是 500 个实例的可能性更大吗？）
什么是更好的方法：20 个小型实例还是 5 个大型实例？
感谢您的帮助！
I'm fairly new to Windows Azure and want to host a survey application that will be filled out by appr. 30.000 users simultaniously.
The application consists of 1 .aspx page that will be sent to the client once, asks 25 questions and will give a wrap-up of the given answers at the end. When the user has given the answer and hits the 'next question' buttons the given answer will be send via an .ashx handler to the server. The response is the next question and answers. The wrap-up is sent to the client after a full postback.
The answer is saved in an Azure Table that is partitioned so that each partition can hold a max of 450 users.
I would like to ask if someone can give an estimated guess about how many web-role instances we need to start in order to have this application keep running. (If that is too hard to say, is it more likely to start 5, 50 or 500 instances?)
What is a better way to go: 20 small instances or 5 large instances?
Thanks for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最明显的答案是：您最好亲自测试一下，看看您的应用程序如何运行。您可以轻松地从 Windows Azure 获取性能计数器和其他诊断信息；例如，您可以连接 Microsoft SCOM（System Center Operations Manager）以在测试期间监控您的环境。 Site Hammer 是一个简单的 Windows Azure 负载测试工具（位于 MSDN 代码库）。
除了这个非常明显的答案之外，我将分享一些猜测：考虑到负载类型，您可能更适合使用更多的小型实例，而不是较少数量的大型实例，特别是因为您已经对存储进行了分区。如果您真的要同时拥有 30K 访客，并在阅读问题和阅读问题之间给他们大约 15 秒的间隔。发布他们的答案后，您会看到每秒 2,000 个请求。 10 个节点应该足以处理该负载。请记住，这只是一个简单的估计，缺乏对架构等的任何形式的了解。对于这些类型的负载，缓存是一个非常好的主意；它将大大增加每个节点可以处理的负载。
然而，我能给你的最好建议是确保你正在积极监控。启动其他实例所需时间不到 30 分钟，因此如果您监控您的环境和/或确保每当它开始阻塞时您都会收到通知，您可以轻松升级您的设置。请记住，您确实需要联系客户支持才能使用超过 20 个实例（这是默认限制，旨在防止您超支）。
The most obvious answer: you would be best served by testing this yourself and see how your application holds up. You can easily get performance counters and other diagnostics out of Windows Azure; for instance, you can connect Microsoft SCOM (System Center Operations Manager) to monitor your environment during test. Site Hammer is a simple load testing tool for Windows Azure (on MSDN code gallery).
Apart from this very obvious answer, I will share some guesstimates: given the type of load, you are probably better of with more small instances as opposed to a lower number of large ones, especially since you already have your storage partitioned. If you are really going to have 30K visitors simultaneously and give them a ~15 second interval between reading the questions & posting their answers you are looking at 2,000 requests per second. 10 nodes should be more than enough to handle that load. Remember that this is just a simple estimate, lacking any form of insight in your architecture, etc. For these types of loads, caching is a very good idea; it will dramatically increase the load each node can handle.
However, the best advice I can give you is to make sure that you are actively monitoring. It takes less than 30 minutes to spin up additional instances, so if you monitor your environment and/or make sure that you are notified whenever it starts to choke, you can easily upgrade your setup. Keep in mind that you do need to contact customer support to be able to go over 20 instances (this is a default limit, in place to protect you from over-spending).
除了 tijmenvdk 给您的明智建议之外，让我添加我对实例大小的看法。一般来说，选择能够支持您的应用程序的最小尺寸，然后进行扩展以处理增加的流量。这样，当您缩小规模时，您的最低计算成本就会保持在较低水平。例如，如果您运行一对超大实例作为基准（因为您总是希望至少有两个实例才能获得正常运行时间 SLA），那么您的成本足迹起始为每小时 0.12 x 8 x 2 = 1.92 美元，即使在低迷时期也是如此。交通时间。如果您使用小型实例，则每小时费用为 0.12 x 1 x 2 = 0.24 美元。
每个虚拟机大小与关联的 CPU、内存和本地（9非持久）磁盘存储有关，因此请选择您的应用程序有效运行的最小大小单位。
对于负载/性能测试，您可能还需要考虑托管解决方案，例如< a href="http://www.loadstorm.com" rel="nofollow">Loadstorm。
Aside from the sage advice tijmenvdk gave you, let me add my opinion on instance size. In general, go with the smallest size that will support your app, and then scale out to handle increased traffic. This way, when you scale back down, your minimum compute cost is kept low. If you ran, say, a pair of extra-large instances as your baseline (since you always want minimum two instances to get the uptime SLA), your cost footprint starts at 0.12 x 8 x 2 = $1.92 per hour, even during low-traffic times. If you go with small instances, you'd be at 0.12 x 1 x 2 = $0.24 per hour.
Each VM size as associated CPU, memory, and local 9non-durable) disk storage, so pick the smallest size unit that your app works efficiently in.
For load/performance-testing, you might also want to consider a hosted solution such as Loadstorm.
现实中请求的同时发生程度如何？
他们会同时输入地址吗？
也就是说，在本地分析您的应用程序，这将使您能够估计 Azure 上的 CPU、网络和内存使用情况。然后，不要考虑您需要多少实例，而是考虑如何减少需求！应用这些技巧，并再次在本地进行分析。
大多数性能技巧都会在 CPU、内存或带宽使用之间进行权衡，其想法是确保它们同等扩展。如果您的应用程序内存不足，但您有 CPU 和网络负载，则不要
进行单页调查，请确保您的 html、css 和js 被缩小，确保其可缓存。
如果可能的话，将它们组合起来，并获得真正的可扩展性，将静态文件（css、js 和图像）推送到 CDN。这一切都减少了网络服务器必须处理的请求数量，从而减少了您需要的网络角色数量=更少的网络。
ashx 如何返回响应？即它发送的是 html、xml 还是 json？
就我个人而言，我会让它返回 JSON，因为这将需要更少的网络带宽，并且很可能更少的服务器端处理 = 更少的内存和网络。
使用异步 API 访问 azure 存储（这使用 IO 完成端口来释放 iis 线程来处理更多请求，直到 azure 存储恢复 = 使 cpu 能够扩展）
tijmenvdk 已经提到使用队列进行写入。问题列表有变化吗？如果没有，则缓存它们，以便应用程序只需在启动时从表存储中读取一次，并为每个客户端读取一次以进行最终总结 = 以内存为代价节省网络和 CPU。
所有这些技巧同样适用于单个服务器或网络场环境中的普通 Web 应用程序。
我想表达的观点是，你无法衡量，就无法改进，而衡量、改进和成本都是齐头并进的。动态扩展会降低成本，但从根本上来说，如果您的应用程序尚未经过衡量并优化资源使用情况，那么询问您需要多少实例是毫无意义的。
How simultaneous are the requests in reality?
Will they all type the address in at exactly the same time?
That said, profile your app locally, this will enable you to estimate CPU, Network and Memory usage on Azure. Then, rather than looking at how many instances you need, look at how you can reduce the requirement! Apply these tips, and profile locally again.
Most performance tips have a tradeoff between cpu, memory or bandwith usage, the idea is to ensure that they scale equally. If you're application runs out of memory, but you have loads of CPU and network, dont
For a single page survey, ensure your html, css & js is minified, ensure its cacheable.
Combine them if possible, and to get really scaleable, push static files (css,js & images) to a CDN. This all reduces the number of requests the webserver has to deal with, and therefore reduces the number of webroles you will need = less network.
How does the ashx return the response? i.e. is it sending html, xml or json?
personally, I'd get it to return JSON, as this will require less network bandwidth, and most likely less server side processing = less mem and network.
Use Asyncronous API's to access azure storage (this uses IO completion ports to free up the iis thread to handle more requests until azure storage comes back = enabling cpu to scale)
tijmenvdk has already mentioned using queues to write. Do the list of questions change? if not, cache them, so that the app only has to read from table storage once on start-up and once for each client for the final wrap-up = saves network and cpu at the expense of memory.
All of these tips are equally applicable to a normal web application, on a single server or web-farm environment.
The point I'm trying to make is that what you can't measure, you cant improve, and measurement, improvement and cost all go hand in hand. Dynamic scaling will reduce costs, but fundamentally if your application hasn't been measured and resource usage optimised, asking how many instances you need is pointless.