估计 Web 应用程序峰值带宽需求的最准确方法是什么？
我正在处理一个客户提案，他们需要升级其网络基础设施以支持托管 ASP.NET 应用程序。 本质上，我需要估计具有已知用户数量（当前为 250）的系统的峰值使用情况。 像“您需要专用 T1 线路”这样的简单答案可能就足够了，但我想要有数据来支持它。
另一个问题引用了 NetLimiter，它看起来非常灵活，可以获取对正在使用的东西的感觉。
我的总体想法是，我将启动网络应用程序并使用该系统，就像我预期客户会使用它一样，在一定的时间跨度内以悠闲的速度，然后将带宽使用量乘以带宽使用量用户并除以时间。
这看起来不太科学。 对于提案来说这可能已经足够好了，但我想看看是否有更好的方法。
我知道有一些负载工具可用于测试 Web 应用程序性能，但这些工具似乎无法准确模拟用于带宽测试目的的峰值用户负载（一次太多）。
该平台是 Windows/ASP.NET，应用程序托管在 SharePoint (MOSS 2007) 内。
I am working on a client proposal and they will need to upgrade their network infrastructure to support hosting an ASP.NET application. Essentially, I need to estimate peak usage for a system with a known quantity of users (currently 250). A simple answer like "you'll need a dedicated T1 line" would probably suffice, but I'd like to have data to back it up.
Another question referenced NetLimiter, which looks pretty slick for getting a sense of what's being used.
My general thought is that I'll fire the web app up and use the system like I would anticipate it be used at the customer, really at a leisurely pace, over a certain time span, and then multiply the bandwidth usage by the number of users and divide by the time.
This doesn't seem very scientific. It may be good enough for a proposal, but I'd like to see if there's a better way.
I know there are load tools available for testing web application performance, but it seems like these would not accurately simulate peak user load for bandwidth testing purposes (too much at once).
The platform is Windows/ASP.NET and the application is hosted within SharePoint (MOSS 2007).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里还有几个额外的问题需要问。
是 250 个总用户，还是 250 个并发用户？ 如果并发，是 250 个峰值，还是 250 个典型值？ 如果总共有 250 个用户，他们是否都希望同时使用它（例如，内部网站点，人们必须将其作为工作的一部分），或者它更像是一个社区网站，他们可能会也可能不会用它？ 我假设您的措辞方式是总共有 250 个用户，但这仍然不足以说明该网站的情况，无法进行估计。
如果它是一个社区或“普通”互联网站点，它也将取决于使用情况 - 例如，人们真的会大量使用它，还是某些用户只会登录一次，然后就忘记了？ 从您的角度来看，这可能是一个棘手的问题，因为您会想要假设前者，但如果您在网络基础设施上花费了大量资金并且最终没有人使用它，那可能是一件非常糟糕的事情。
该网站在做什么？ 在低端，有一个“典型”的 Web 应用程序，其中有合理大小（例如 1-2k）的页面和少量图像。 更激烈一点的是拥有大量媒体的网站 - 例如 flickr 风格的图像浏览。 高端是一个有大量下载的网站 - 流媒体电影，或者只是下载大文件或数据集。
这有点超出了你的问题的范围，但另一件事需要考虑的是该网站的未来：使用率是否可能在明年或下个月增加一倍？ 警惕与 T1 或光纤连接等签订长期合同，而没有某种方式升级的情况。
另一个问题是可靠性 - 您是否需要连接冗余？ 前期成本可能很高，但有多种方法可以实现多宿主连接，您可以平衡多个链接的访问，然后在发生故障时仅使用一个链接（尽管容量有所减少）。
另一个需要考虑的选项是在数据中心托管应用程序，它可以有效地让您完全避免整个问题。 您支付相对较低的月费（与专用高质量连接的成本相比较低），并且您可以获得所需的带宽（例如，大多数托管计划将为您提供每月 500GB 的传输量，首先- 有些只会给你无限）。 该数据中心也将比您可以构建的任何东西（除了您自己的 6 位数以上数据中心之外）更可靠，因为它们拥有冗余互联网、电源备份、冗余冷却、消防、物理安全......并且它们有人员管理所有内容为您提供这些，因此您永远不必处理它。
There are several additional questions that need to be asked here.
Is it 250 total users, or 250 concurrent users? If concurrent, is that 250 peak, or 250 typically? If it's 250 total users, are they all expected to use it at the same time (eg, an intranet site, where people must use it as part of their job), or is it more of a community site where they may or may not use it? I assume the way you've worded this that it is 250 total users, but that still doesn't tell enough about the site to make an estimate.
If it's a community or "normal" internet site, it will also depend on the usage - eg, are people really going to be using this intensely, or is it something that some users will simply log into once, and then forget? This can be a tough question from your perspective, since you will want to assume the former, but if you spend a lot of money on network infrastructure and no one ends up using it, it can be a very bad thing.
What is the site doing? At the low end of the spectrum, there is a "typical" web application, where you have reasonable size (say, 1-2k) pages and a handful of images. A bit more intense is a site that has a lot of media - eg, flickr style image browsing. At the upper end is a site with a lot of downloads - streaming movies, or just large files or datasets being downloaded.
This is getting a bit outside the threshold of your question, but another thing to look at is the future of the site: is the usage going to possibly double in the next year, or month? Be wary of locking into a long term contract with something like a T1 or fiber connection, without having some way to upgrade.
Another question is reliability - do you need redundancy in connections? It can cost a lot up front, but there are ways to do multi-homed connections where you can balance access across a couple of links, and then just use one (albeit with reduced capacity) in the event of failure.
Another option to consider, which effectively lets you completely avoid this entire question, is to just host the application in a datacenter. You pay a relatively low monthly fee (low compared to the cost of a dedicated high-quality connection), and you get as much bandwidth as you need (eg, most hosting plans will give you something like 500GB transfer a month, to start with - and some will just give you unlimited). The datacenter is also going to be more reliable than anything you can build (short of your own 6+ figure datacenter) because they have redundant internet, power backup, redundant cooling, fire protection, physical security.. and they have people that manage all of this for you, so you never have to deal with it.
您始终可以进行粗略的猜测，而不是良好的带宽使用报告工具。
N = 最繁忙时段的页面浏览量
P = 平均页面大小
(N * P) /3600) = 每秒平均流量。
服务器本身可能会为数据库服务器/NAS/等提供更多的内部流量。 但面向外应该能让你对利用率有一个非常粗略的了解。 显然，您需要远远超过上述值，因为您永远不想 100% 利用率，并允许其他流量。
我也不建议使用任意数量（例如 250 个用户）。 使用最繁忙的生产日/小时作为参考。 如果您愿意，可以加倍或加倍，但是如果您有良好的日志文件/用户审核，这将为您提供预期的用户行为分布。 这将有助于使您的猜测更加准确。
正如另一位评论者指出的那样，当冗余和带宽可用性成为问题时，数据中心是一个好主意。 您的需求可能会有所不同，但不要轻易忽略该建议。
In lieu of a good reporting tool for bandwidth usage, you can always do a rough guesstimate.
N = Number of page views in busiest hour
P = Average Page size
(N * P) /3600) = Average traffic per second.
The server itself will have a lot more internal traffic for probably db server/NAS/etc. But outward facing that should give you a very rough idea on utilization. Obviously you will need to far surpass the above value as you never want to be 100% utilized, and to allow for other traffic.
I would also not suggest using an arbitrary number like 250 users. Use the heaviest production day/hour as a reference. Double and triple if you like, but that will give you the expected distribution of user behavior if you have good log files/user auditing. It will help make your guesstimate more accurate.
As another commenter pointed out, a data center is a good idea, when redundancy and bandwidth availability become are a concern. Your needs may vary, but do not dismiss the suggestion lightly.