导航
  • 主页
  • VC综合技术
  • 互联网技术
  • MFC AppLauncher
  • .NET 技术
  • 界面
  • 进程
  • 算法
  • 硬件/系统
  • 数据库
  • VC++技术资源

如何优化

chenyu2202863 2009-09-01 05:13:21
背景:
这是一个网络程序,客户端在一台Intel Atom(7M) CPUN270 1.6GGHZ
内存:1G

服务端的硬件比较好。


现状:
现在需要拷屏(服务端运行一个3D模拟设备)传输到客户端,传输的JPEG文件,同时利用Zlib压缩过,但是造成了客户端延迟严重,CPU占用率100%。

服务端流程如下:
1--拷屏
2--转换为JPG格式
3--压缩
4--发送



客户端流程如下:
1--解压
2--转换为JPG格式流
3--显示


问题:
我需要从哪些方面来优化,降低数据流量,减少客户端的运算,从而保证数据的流畅。

我的想法:
1。降低拷屏产生的数据量,我做了JPG压缩,但是没什么效果
2.不通过压缩这个过程了,直接把转换成的JPG数据发送到客户端
3.是不是我开的线程太多了(服务端21个,客户端11个),造成了CPU浪费在线程的切换?

请大家出出主意吧,主要从降低数据量,提高效率上来考虑



...全文
134 点赞 收藏 36
写回复
36 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
lili0920 2009-09-02
帮顶
回复
wu_qing_yun 2009-09-02
把线程数降下来试一下吧
回复
WuXinyang 2009-09-02
配置太低..
回复
chenyu2202863 2009-09-02
用的select模型,不存在recv太快吧
回复
chenyu2202863 2009-09-02
用的select模型,不存在recv太快吧
回复
chenyu2202863 2009-09-02
CPU占用到100%后,revc跟不上服务端。
大量的CPU用到显示上了,我是每次接收到新的图像数据就刷新的,而且是拉伸显示~
回复
百事烟 2009-09-02
[Quote=引用楼主 chenyu2202863 的回复:]
客户端流程如下:
1--解压
2--转换为JPG格式流
3--显示
[/Quote]
测一下客户端时间主要消耗哪?
关闭123测socket效率
关闭3 测解压和转换效率
..........

如果是sokcet,recv前加Sleep(1)
如果是解压,不用这个功能,直接发jpg,省掉解压和转换的CPU
如果是显示,尽量原始比例显示(这个最快),视频框背景不要刷新(去白闪,稍快),画面尽可能小(稍快)
回复
liangxd09 2009-09-02
既然是客户端机器的问题,那主要在客户端机器上提高显示速度就行了。写显存?
回复
chenyu2202863 2009-09-02
还有人吗?
回复
chenyu2202863 2009-09-02
是那客户端机器太变态了~,配置低得很!

在其他配置较好机器上(双核)就没这个问题
回复
百事烟 2009-09-02
[Quote=引用 35 楼 chenyu2202863 的回复:]
用于TCP接收数据的就用7个通道,7个线程
[/Quote]
接收最多用2个,换个模式试试?
回复
chenyu2202863 2009-09-02
线程降不下来了,用于TCP接收数据的就用7个通道,7个线程。一个日志线程,一个GDIPlus线程,一个主线程

哎,现在只有换硬件了~
那个CPU实在太烂,还跑不赢赛扬的主频为1.6GHZCPU
回复
百事烟 2009-09-02
桌面大小是1024*768,再大也不会大到哪去,服务器压jpg的时候质量不要设成100,如果设为75或70。人的眼睛看不出什么的,这样每整张桌面的jpg文件不会超过100K,不用再压缩了,可以省掉压缩和解压缩的过程。
线程数也就降下来了

socket的缓冲区要大一些,10240,20480都试一下,10240最少了

sokcet,recv前加Sleep(1) 的目的不是说收的太快,而是适时把CPU交出去,防止100%,如果程序运行的非常好,可以Sleep(0),但一定要加,

实在解决不了,就只好降低帧数,



客户端流程如下:
1--解压 //去掉
2--转换为JPG格式流 //去掉
3--显示

如果没有别的功能,客户端只是接收jpg流(每张100K),显示,1-3个线程完全够用了
回复
whg01 2009-09-01
是不是因为每个线程始终在运行,没有sleep?
回复
Conry 2009-09-01
可以参考一下ultravnc,
如果要求比较高的话,可以用驱动来解决,直接取显卡的buffer
回复
xingzhe2001 2009-09-01
利用媒体压缩的原理,两个相邻帧之间只有很小的差别,因此你在客户端计算出两帧数据的差别,对差别进行压缩传到客户端,客户端再计算出应该显示的帧来。
回复
deng335995 2009-09-01
[Quote=引用 19 楼 gordon3000 的回复:]
JPG不用压缩,能节省一部分资源。

[/Quote]
同意,就算压缩也少不了多少的,而且还要解压,花的时间够多的了.
回复
副组长 2009-09-01
JPG不用压缩,能节省一部分资源。
回复
chenyu2202863 2009-09-01
是那台客户端机器太恶心了,CPU居然是Atom
而且现在是两台机器对接的,不存在网络问题
回复
WuXinyang 2009-09-01
是不是和网速有关系呢,你找个网速快的试一下.
改为下载我认为应该好点(不知道是不是真能好点).
HTTP多线程下载试试.
回复
发动态
发帖子
VC/MFC
创建于2007-09-28

1.5w+

社区成员

VC/MFC相关问题讨论
申请成为版主
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……