平衡 IIS 压缩与 CPU 时间?
例如,当 IIS 压缩级别设置为 9 时,网页浏览速度明显加快。 然而,我的盒子上还有一个 Web 服务应用程序,它会传输大量数据(例如,典型的负载为 3MB),数据到达客户端实际上要花费 20-30% 的时间,因为服务器上的 CPU需要一段时间来压缩它。
是否有关于 IIS 压缩级别与传输数据量的经验法则?
也欢迎轶事经验。
For instance, with a level of IIS compression set to 9, the web browsing is significantly faster. However, I also have a Web Services application on the box, which transfers significant amounts of data (e.g. 3MB payload is typical), it actually takes 20-30% longer for the data to get to the client, because the CPU on the server takes a while to compress it.
Is there a rule of thumb for the level of IIS compression vs amount of data transfered?
Anecdotal experience is welcome as well.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
好的,我运行了一些基准测试,无论您如何分割它,对于我的用例来说,关闭压缩会带来更快的性能。 以下是返回 3.2 MB 数据的 Web 服务调用的结果(主要是反序列化为字节数组的内容列表)。
在 Web 服务调用期间,CPU 相当稳定在第 9 级,在第 8 级和其他任何级别都没有那么糟糕下面是个位数的利用率。
Ok, I ran some benchmarks and no matter how you slice it, turning off compression results in faster performance for my use case. Here are the result for a web service call that returns 3.2 megabytes of data (mostly list of things deserialized into byte arrays)
The CPU is pretty pegged at level 9 for the duration of the web service call, not so bad at level 8 and anything beneath that is in single digits utilization.
值得怀疑,因为有很多变量:
我预计在您的用例中连接速度相当快? 毕竟压缩 3MB 应该不会花那么长时间。
Doubtful, because there are so many variables:
I expect the connection is fairly speedy in your use case? Compressing 3MB shouldn't take all that long after all.