测试wcf的http和tcp绑定以及非wcf的命名管道传输文件速度对比
最快速度是在本机上使用非wcf的命名管道有113MB/s
局域网机器传输文件速度最快是使用wcf的tcp绑定,速度有70~120MB/s
测试速度对比:
本机互传 | 局域网机器互传 | |
---|---|---|
wcf的http绑定 |
104~116MB/s缓冲模式(25MB需要0.21~0.23秒) 40~45MB/s流模式(25MB需要0.5~0.6秒) |
50~60MB/s缓冲模式 7~10MB/s流模式 |
wcf的tcp绑定 |
290~370MB/s缓冲模式(25MB只需要0.07s) (wcf的命名管道也只需要0.07s) 60~70MB/s流模式 |
70~120MB/s缓冲模式(25MB只需要0.20~0.37秒) 2~3MB/s流模式 |
非wcf的命名管道 | 113MB/s | 10MB/s |
缓冲模式使用的缓存大小大于文件大小(即文件先全部放入内存),这是用资源换取速度的方法,实际使用中不能耗费太多资源。
写文件的操作使用了缓冲层。
希望有兴趣的朋友一起交流。
测试时Read方法的缓冲大小为15000;发现该缓冲过大速度会过慢,大到一定程度上后接受不到数据并会提前终止。
测试TCP发现每次Read有一个规律:
第一获取255,
第二次4089,
第三次6,
第四次以及之后4089
难道这就是传说的三次握手吗?
测试HTTP发现每次Read都是4096
PS(2014/3/25):众所周知,传输速度(注意区分你测到的速度和网络传输速度的区别)的快慢的影响因素是多方面的。大体上来讲,接受来自网络的大数据时,在未接受完成前,将数据暂存在内存中是测试到的传输速度是最接近网络传输速度的。如果不这样做,那么也建议持久化的线程与接收网络数据的线程不要在同一线程上。建立和切换连接与频繁访问磁盘是耗时操作。
就像在测试一个算法的效率的时候,频繁打印计算进度是严重影响实际效果的,因为访问打印设备也是耗时操作。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?
2012-02-26 使用.netFx4.0提供的方法解决32位程序访问64位系统的64位注册表