系统优化浅思

        曾经一个朋友开发了一个项目，客户端是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％左右的时间。

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

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