关于性能优化的一个总结

最近一段时间在做性能优化，触动比较大的就是一定要去转换思路，调整方向，才能有根本性的提高，否则就只是小修小补了。

在第一个性能优化中，由于业务需求，需要将原来分散的对象信息收集起来，然后统一进行展示。由于数据量巨大，因此采用视图或者查询时再去收集和组织整理这些数据，在效率上是不可接受的。然而目前在三张数据库表中，为每个用户存储上万条的业务对象数据，然后三个表去联合查询下，从而获得一个用户的完整数据，然后将这些数据转换为corba对象数据并打包，发送给客户端，在这个过程中，如果有很多的用户，就会导致一个表中有大量的数据，比如后续规模扩大，一个用户可能有十万个数据，如果有一百个用户，就会导致相应的表中有千万级的记录，然后再联合查询这样的效率是可想而知的，并且这个过程与数据库的繁忙程度有直接的关系，就会导致每次客户端的查询耗时都是不稳定的，其次是一个大的corba结构的分配，由于采用sequence，就是需要连续内存，这个是corba限定的，你没法改变，更为糟糕的是你提前也是无法预知这个序列的大小的，这就加剧了痛苦。

在对此进行优化的过程中，一个看起来比较可行的方案是每个用户单独分表，这样就可以在一定的程度上解决数据库查询的问题，但是对于后面的corba数据结构打包问题还是没有用处的，这个提议作为备用的选择。然后提出了将每个用户的数据首先导出来放到磁盘上，客户端查询时再将这些数据打包压缩作为字节流传递给客户端，由于用户数据可以拆成更小的单元，每次每个单元的数据发生了变化，则仅仅将相应的单元的数据收集导出到磁盘上，开始时还不确定这个做是否会更快点，后续的实验证实这个过程还是蛮快的，然后客户端进行查询时，后台将这些磁盘文件进行打包压缩，再读取压缩包作为字节流传递给前台，实验同样证实了采用7z压缩能够很快的结束这一个过程（7z压缩能够比古老的zip压缩快了很多),
同样客户端对于收到的字节流再进行内存解压，从而使得整个流程能够在几秒内就完成了，极大的提高了性能。

在这个优化中，转换了思路方向，不在利用数据库进行大数据量的数据存储，而是利用磁盘文件，我觉得主要是由于这个数据是读频繁，并且要求快速，而更新数据则要求稍微放松些，并且数据的更新时机也是比较分散的，因此在数据量比较大时，比较适合采用这个方案。

其次是也是查询速度慢的优化，实际上这个查询已经优化过一次了，只是在查询的时候一次获取所有信息，然后在这个缓存中来组织构建数据，但是在大数据量的情况下，获取查询需要的所有信息会耗去大部分的时间，因此需要一次彻底的优化，原来在查询所有业务信息时，得到的对象就是源对象的一个克隆，而源对象是由好多小的字段构成的，如果系统中的小对象数据达到几千个时，就会导致这个查询的速度非常的慢，并且速度也是不稳定，此外还有可能导致内存碎片化问题，接着经过讨论，觉得采用引用计数可以解决这个问题，因此开始动手去做了。由于考虑业务对象采用传递对象引用的方式，对象引用本身是非常的简单了，这时boost::shared_ptr就成为我们的选择了，每个引用中实际是含有一个shared_ptr，这样在相应的对象不再含有引用时，就会自动释放源对象了，但是其中有一点需要注意的是，如果是要修改对象，则需要克隆一个源对象，然后修改这个对象，最后将这个对象添加到系统中，如果不遵循这个原则，就可能导致你在修改一个对象，而别人正在使用，那就只有core一条路了。目前来看我们的系统中采用复制克隆对象的技术还是比较多，对于访问比较频繁时，是需要调整为传递引用对象的。

最后，我们在处理对象时，一般都是喜欢一次处理一个，这时如果对象的数目比较少时，你是看不出来任何问题的，但是如果对象是成千上万的，呵呵，你的程序就不知道要处理到什么时候了，可能要等到第二天了，这时就需要进行批处理，但是你想一下子处理完吗？如果是一万个文件，你要一次性都加在要内存中吗，这个时候我们就需要进行分组，一万个小对象，每次仅仅处理一百个就可以了，这样比较多快好省了！