承接基于.Net的系统研发,精通物流系统,特别是仓储物流管理,有意者请联系。

系统优化浅思

        曾经一个朋友开发了一个项目,客户端是Windows的应用程序,通过WebService服务操作数据库。系统的功能都已完成,用户比较满意。但是有一个问题存在,就是在查询时如果读取大数据量时,系统获取数据并显示的等待时间比较长。为了解决这个问题,朋友采用BinaryFormat格式化数据,同时对数据进行压缩,数据的大小只有原来的8%,效果虽然比以前好一些,但还不是另人满意。于是朋友继续找寻着压缩率更高的压缩算法。

        我想在开发过程中,很多朋友都会遇到我朋友这样的情况,当用户点击后,等了5秒(还算好),10秒(有点不爽),20秒(系统是不是当掉了),再往后就不敢想了。用个一次两次的,用户也许还能接受。如果有段时间需要统计,那用户还不得给你吹胡子瞪眼睛啊。在遇到大数据量查询时,我朋友的解决方法也是对的,至少效果比以前好了一些。但问题仍然没有解决,那么我们是否将注意力集中到其他地方呢?为什么?1、采用压缩算法后数据只有原来的8%,现行压缩率更高的算法还能有多少的提升空间;2、业务数据只会更多。

         不考虑除硬件因素,仅考虑技术开发,就这个例子来说明,解决大数据量查询,通用的做法是采用分页、格式化并压缩数据等。可是系统反应速度慢,并不只是WebService的大数据量传输的“功劳”,因为从数据获取到界面显示经历了多个环节。要说优化,我想每个环节都可以进行优化。我知道的并不很多,抛砖引玉吧。(建立在上述的例子上,还是优点针对性比较好,不然就要空谈了,又要开始Remoting WebService还是Windows Communication Foundation技术之争了,那就没完没了了。还是那句话:适合才是正确的
     
     1、数据库。
          我们的数据都是它给的,它的读取数据的时间对系统的反应速度也是有影响的。对数据库的优化方式很多了,很多书籍都专门讲解如何优化数据库,比如常用的索引等;存储过程和SQL语句的选择;存储过程和SQL语句的写法有讲究的,表的顺序、条件的使用,不是想怎么写就怎么写,曾经有朋友做查询存储过程,修改了一种写法,原来半分钟才出来结果,结果只用几秒,具体多少忘了,至少用户可以接受了。

      2、应用层。数据库的API,针对.Net,比如就有DataReader和DataSet的选择以及转换等,这个根据具体情况而定;还有呢就是大家常采用的数据的格式化和压缩,以及采用分页,减少传输的数据量;是否可以把一部分处理逻辑放在客户端呢,减少服务端的工作量。

       3、数据传到了界面,界面是否有需要优化的地方呢?如果一个界面打开后所需时间较长,有可能是初始化的工作量太多,是否可以考虑减少在窗体加载时的初始化工作,而放到窗体显示后呢?这个据具体情况而定;还有就是界面控件的选择,很多人都使用过第三的控件,第三方控件是较开发平台提供的功能强大,但因为做的工作比较多,所以效率相对较低。     这里需要说明的一点,我做过一个测试,分析两段时间的百分比,一个是是从数据库取出数据的时间,一个是控件绑定数据时间(使用的是第三方的控件)。当然例子非常的粗糙,数据库也没有进行过优化,因为每次执行机器情况的不尽相同,不足以验证结论数据的可靠性,只作为一种参考,但我想还是有影响的。数据读取量从1万、2万、5万、10万、50万到100万不同级别,每个级别都做了3次测试,记录两段时间,然后算它们所占总时间的百分比,计算这一级别两段时间占用时间的平均值,最后将6级别的平均值在进行平均,得到一个结论:使用第三方控件grid数据绑定过程占用40%左右的时间。

      排除硬件因素,一个系统的优化涉及到很多的方面,不同的项目,不同的环境,就会有不同的优化。我说的只是很多优化中的一角,但不论采用什么方式优化,只要我们坚持,我们的项目将会越来越有竞争力。

      我所做的项目有限,积累也就很有限,认识就更有限了,考虑的情况不周全,仅仅只是曾经我在项目中采用该种优化提高了一些的效率的经验,不好展开,因为太多了,但我说的也不一定正确,大家随便看看,最欢迎指教。

 

posted @ 2006-09-29 13:04  阿修罗一平  阅读(1794)  评论(12编辑  收藏  举报