轮询 Web 服务性能 - 这可行吗？
我们的应用程序需要即时通知，所以显然我应该使用一些 WCF 双工或套接字通信。 问题是该应用程序部分信任 XBAP，因此我不允许使用除 BasicHttpBinding 之外的任何内容。 因此我需要轮询更改。
不，问题来了：我的 PM 说更新间隔应该约为 2 秒，并在单个 Web 服务器上有 500 个用户的 Intranet 上运行。
你们中有人有过轮询如何影响网络服务器的经验吗？
该服务非常简单，它接受一个 guid 作为参数，并返回一个 guid 列表。 所有数据访问都会被缓存，所以我猜想对于一次调用，服务器上的负载是最小的，但是对于 500 次......
除了轮询之外，网络服务器几乎没有什么工作。
那么，根据这个小信息（假设一个标准服务器硬件，无论是什么），是否可以做出合格的猜测？
- 是否可以实施这个，它会起作用吗？
的想法，我会很高兴
是的，我知道估计这很困难，但如果你们中的一些人能分享一些对此
Larsi
Our app need instant notification, so obvious I should use some some WCF duplex, or socket communication. Problem is the the app is partial trust XBAP, and thus I'm not allowd to use anything but BasicHttpBinding. Therefore I need to poll for changes.
No comes the question: My PM says the update interval should be araound 2 sec, and run on a intranet with 500 users on a single web server.
Does any of you have experience how polling woould influence the web server.
The service is farly simple, it takes a guid as an arg, and returns a list of guids. All data access are cached, so I guess the load on the server is minimal for one single call, but for 500...
Except from the polling, the webserver has little work.
So, based on this little info (assume a standard server HW, whatever that is), is it possible to make a qualified guess?
- Is it possible or not to implement this, will it work?
Yes, I know estimating this is difficult, but I'd be really glad if some of you could share some thoughts on this
Regards
Larsi
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
250 qps 可能在相当适度的硬件和网络带宽下是可行的，前提是您确实最大限度地减少了发回和发送的数据。 向前。 我假设您在客户端上缓存这些 GUID 列表，因此在正常情况下您只需发送一个小的“无更新”响应即可。
使用简单的原型应该很容易测量，但要更有信心。
250 qps probably is doable with quite modest hardware and network bandwidth provided you do minimize the data sent back & forth. I assume you're caching these GUID lists on the client so you can just send a small "no updates" response in the normal case.
Should be pretty easy to measure with a simple prototype though to be more confident.
不要估计，基准。
Don't estimate, benchmark.
轮询.. 不好，但如果您别无选择，那么它是理想的:)
请记住这样一个事实，您无疑将保持活动状态，因此您将拥有 500 个永久连接的用户。 其内存使用量可能比处理器使用量更重要。 我无法想象网络访问（即使在相对庞大的网络服务中）会使用大量的网络容量，但您的网络延迟可能会成为一个问题 - 特别是当我们都看到网络应用程序“暂停”一段时间时。
最后，你可能会没事，但你必须自己检查一下。 有很多 Web 服务压力测试工具，您可以使用 Microsoft 的 WAS 工具 之一，这里是< a href="http://www.testingfaqs.org/t-load.html" rel="nofollow noreferrer">一些链接到其他人。
Polling.. bad, but if you have no other choice, then it's ideal :)
Bear in mind the fact that you will no doubt have keep-alives on, so you will have 500 permanently-connected users. The memory usage of that will probably be more significant than the processor usage. I can't imagine network access (even in a relatively bloaty web service) would use much network capacity, but your network latency might become an issue - especially as we've all seen web applications 'pause' for a little while.
In the end though, you'll probably be ok, but you'll have to check it yourself. There are plenty of web service stress testers, you can use Microsoft's WAS tool for one, here's a few links to others.
尝试使用 Web 服务测试工具 soapui 来检查 Web 服务的性能。 有付费版本和免费的开源版本。
干杯
Try using soapui, a web service testing tool, to check the performance of your web service. There is a paid version and an open source version that is free.
cheers
我认为这不会是一个特别的问题。 我想每个请求的响应时间会非常短，除非您要拉回大量数据，因此 2 秒内分布的 500 个连接不会对其造成太大影响。
在进行此设计之前，您可以使用压力测试工具来验证您的网络服务器是否可以处理负载。
I don't think it will be a particular problem. I'd imagine the response time for each request would be pretty low, unless you're pulling back a hell of a lot of data, so 500 connections spread over 2 seconds shouldn't hit it too hard.
You can use a stress testing tool to verify your webserver can handle the load though, before you commit to this design.