如何将并发用户转化为每秒点击数？
我当前正在开发的系统的 SRS 包括以下非功能性要求：“SuD 应可扩展到 200 个并发用户”。如何将此陈述转换为更可测量的特征：“每秒点击次数”？
SRS for the system I'm currently working on includes the following non-functional requirement: "the SuD shall be scalable to 200 concurrent users". How can I convert this statement to a more measurable characteristic: "hits per second"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
假设您正在谈论一个 Web 应用程序（基于您想要估计每秒“点击次数”），您必须做出一些假设。
- 用户在交互之间会花费多长时间？对于典型的内容页面，这可能是 10 秒；对于交互式 Web 应用程序，也许只需 5 秒。
- 将用户数量除以“思考时间”即可获得每秒点击次数 - 200 个并发用户的思考时间为 10 秒，平均为 20 个并发用户。
- 然后乘以“峰值乘数” - 大多数网站在夜间相对安静，但在晚上 7 点左右非常繁忙。因此，您的平均次数需要考虑到这一点 - 通常，我建议峰值次数在 4 到 10 次之间。
这为您提供了每秒的峰值页面请求 - 这通常是 Web 应用程序的限制因素（尽管并非总是如此 - 例如，流媒体视频通常受到带宽的限制）。
如果您确实想了解“点击量”，则需要执行以下操作：
- 您的页面上有多少资产？图像、样式表、javascript 文件等 - “命中”通常指任何类型的请求，而不仅仅是 HTML 页面（或 ASPX 或 PHP 或其他）。大多数现代网络应用程序都包含数十种资产。
- 您的页面和/或资源的可缓存性如何？大多数图像、CSS、JS 文件等应设置为可由浏览器缓存。
将页面请求乘以不可缓存资源的数量。如果您想要超级精确，请将访问者数量乘以资产数量相加。
所有这些通常意味着你必须做出很多很多的假设——所以最终的数字充其量只是一个指标。对于可扩展性测量，我通常会花更多时间尝试了解系统中的瓶颈并观察负载下的系统。
Assuming you're talking about a web application (based on your desire to estimate "hits" per second), you have to work on a number of assumptions.
- How long will a user spend between interactions? For typical content pages, that might be 10 seconds; for interactive web apps, perhaps only 5 seconds.
- Divide the number of users by the "think time" to get hits per second - 200 concurrent users with a think time of 10 seconds gives you 20 concurrent users on average.
- Then multiply by a "peak multiplier" - most web sites are relatively silent during the night, but really busy around 7PM. So your average number needs to take account of that - typically, I recommend a peak of between 4 and 10 times.
This gives you a peak page requests per second - this is usually the limiting factor for web applications (though by no means always - streaming video is often constrained by bandwidth, for instance).
If you really want to know "hits", you then need to work through the following:
- How many assets on your page? Images, stylesheets, javascript files etc. - "hit" typically refers to any kind of request, not just the HTML page (or ASPX or PHP or whatever). Most modern web apps include dozens of assets.
- How cacheable are your pages and/or assets? Most images, CSS, JS files etc. should be set to cacheable by the browser.
Multiply the page requests by the number of non-cacheable assets. Add to this the number of visitors multiplied by the number of assets if you want to be super precise.
All of this usually means you have to make lots and lots of assumptions - so the final number is an indicator at best. For scalability measurements, I usually spend more time trying to understand the bottlenecks in the system and observing the system under load.
如果不了解您的应用程序或其用途，就不可能回答这个问题。您需要计算出一个用户在使用该应用程序时每秒可能产生多少次点击，然后乘以 200。
顺便说一句，每秒点击次数并不是您需要关注的唯一指标。如果有 200 个并发用户，那么内存开销是多少？有多少磁盘访问或打开的文件句柄？有多少数据库读/写？多少带宽（应用程序是否涉及流媒体）？一台机器能处理这一切吗？等等等等
Well that's impossible to answer without knowing anything about your app or what it does. You need to figure out how many hits per second one user is likely to make when using the app, and multiply by 200.
Incidently, hits/second is not the only metric you need to be concerned with. With 200 concurrent users how much memory overhead will that be? How much disk access or open file handles? How many db reads/writes? How much bandwidth (does the app involve streaming media)? Can it all be handled by one machine? etc etc