我应该压缩通过 wcf 服务公开的数据吗？
我正在创建一个 WCF 服务，该服务公开一个对象图，该对象图预计在服务启动和运行时会增长。在处理一些测试数据 (85k) 时，我达到了默认的 65k 消息大小限制，该数据比实时预期的要小。快速浏览一下网络，发现在配置中扩展它非常简单。
当我创建服务和使用它的客户端时，我想知道在发送数据之前压缩数据是否有附加值。运行简短的测试后，测试数据缩减至 7k 左右，因此这看起来将有助于缩短通过网络发送消息的时间并增加我可以发送的数据量。
该服务在第一次调用之前预先准备数据，因此每次调用都不会因压缩而产生初始开销。
为了可扩展性并尝试优化性能，这样做是个好主意，还是在不需要的地方增加了复杂性？
I'm creating a WCF service which exposes an object graph which is expected to grow in size while the service is up and running. In playing with some test data (85k), smaller that would be expected when live, I hit the default 65k message size limit. A quick look on the net showed that it was simple enough to extend this in the config.
As I'm creating the service and the client which consumes it, I wondered if there was added value in compressing the data before I sent it. Having run a brief test, the test data shrunk to around 7k, so this looks like it will aid in the time for the message to be sent over the wire and increase the amount of data I could send.
The service pre-prepares the data before the first call is made and so there is no initial overhead on every call due to the compression.
Is it a good idea to do this for the sake of scalability, and trying to optimise performance, or is this adding complexity where it is not needed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通过阅读您的帖子，似乎您能够非常轻松地实现这种压缩。
如果您控制双方，那么当您从中获得大量带宽优势时，添加压缩/解压缩层并不会真正增加一般场景的复杂性。
您可以通过实现一些模式（例如
Interceptor或Decorator）来最大限度地降低复杂性。By reading your post, seems like you were able to implement this compression quite easily.
If you control both the sides, adding a layer of Compression/Decompression does not really increase complexity for general scenarios when you gain a lot of bandwidth benefit out of it.
What you could do to minimize the complexity by implementing some patterns like
InterceptororDecorator.只要您不使用晦涩的压缩格式，我认为您不会增加任何明显的复杂性。一两行代码。也许您可以向服务调用添加一个参数，让客户端选择压缩或未压缩数据。
As long as you're not using an obscure compression format, I don't think you're adding any appreciable complexity. One or two lines of code. Perhaps you could add a parameter to the service call which lets the client choose compressed or uncompressed data.
你们能更具体一点吗，我应该做什么来加密和加密？压缩和解密&两端数据解压成功？哪种压缩算法最适合压缩大数据，压缩和解压缩时间更少，也可以压缩和解压缩小数据，从而有效地在客户端和服务器之间传输数据。
@decyclone：什么是拦截器或装饰器？请具体、明确。
Can you all be more specific, what all I should do to encrypt & compress and decrypt & decompress data successfully at both ends? Which compression Algo is the best for compressing large Data taking less time to compress and decompress and also compressing and decompressing small data, to efficiently transfer the data between client and server.
@decyclone: what is interceptor or decorator? Please be specific and clear.