架构设计中影响性能的因素及解决方案

性能(performance)设计非常重要，对于服务器端实时交易系统来说系统性能的重要性不言而喻，对客户端软件来说性能好的软件也会获得良好的用户体验，从而给用户留下高质量软件的良好印象。因此在进行架构设计中性能设计非常重要。

      但架构设计实际是一个平衡设计，在可用性、可扩展性、可维护性、可靠性、高性能等之间做个妥协选择。这些非功能性的需求再加上复杂的功能性需求，同时还要考虑到项目管理上tight schedule, low cost, perfect effect的三角难题约束，有时需求还不是很明确，vision不是很清楚，这种情况下系统架构设计真是一门艺术。(可参考笔者另外一篇文章《也谈系统设计的一些原则》)

      单就性能设计来说，在架构设计初期就一定要把系统性能考虑在内，否则等开发完成以后测试发现性能不好就比较难办，通常要花费较长的时间来诊断性能瓶颈，找到提升的办法，甚至要改变架构，伤筋动骨，往往造成项目延期。所以性能设计首先要有明确的性能目标，根据用户和软件本身的性能要求来设计，合适的就是最好的。其次，要有适当的度量标准和量化的性能指标。最后，要有相应的设计策略，具体的测试方法。

      根据我的经验，影响系统性能主要瓶颈在I/O，包括数据库，socket，网络通信，文件等，例如频繁查询数据库并返回大量结果集，频繁操作大文件等，这些昂贵的操作会占用大量的CPU时间。拿系统响应和服务一个事务来说，有几个Round trip，要通过哪几层I/O，如何合理的分配这些I/O的调用，降低不必要的I/O，都是进行系统性能设计要考虑的。而有些性能问题在初期并不会表现出来，但当拿到实际上线环境下，存在多用户并发、大数据量的情况下就会暴露出严重的问题。所以性能设计时一定要考虑到I/O，同步，并发，资源争用，以及大数据量等因素。通常，I/O操作、网络响应、差的算法、数据库、以及其他的低效的资源使用都会导致低劣的性能。

具体可用的设计策略有：

l        缓存以及缓存层(caching layer)

    在数据层和应用层之间增加数据缓存层，提供全局数据服务。可以大大减少数据库往返次数。与读取数据库和读取大文件（如XML文件）比，读取内存的速度无疑要快的多。所以对经常要访问的数据进行缓存是非常好的实践方法。因为现在系统往往内存很大，可以充分利用大内存，而共享内存更能实现数据并发访问。

l        多线程(multi-threading)

    现在基本上大部分软件实现多线程或多进程，多线程对单CPU系统还只是顺序利用CPU时间和改善用户体验，多CPU系统才是真正的并行。要注意的是多线程不要争抢访问同一资源而导致部分串行操作，要做到真正的并行操作多线程并不容易。另外，在多线程间同步一个庞大的资源，过多创建线程又没有实现线程池也会导致系统性能下降。

l        负载平衡(load balancing)

    物理上增加地位对等的集群服务器（Cluster），通过负载分配算法分配相应服务器来相应客户端请求。很多系统支持负载均衡，Windows server2003 IIS就支持负载均衡服务，其他如WebLogic, WebSphere也有集群版本支持负载均衡。当然你也可以自己实现负载分配算法。

l        数据库优化（database optimization）

   如果应用程序使用了数据库，可以采取许多步骤来消除访问和写入数据时的瓶颈：

Ø         标识潜在的索引，但不要创建过多的索引。

Ø         如果使用 SQL Server，则使用 SQL Server 的事件探查器和索引优化向导。

Ø         监视处理器的使用；理想范围是：75-80% 处理器时间。

Ø         使用查询分析器分析查询计划以优化查询。

Ø         使用存储过程优化性能。

Ø         标准化写入的大量数据 —写入较少的数据。

Ø         取消标准化读取的大量数据 —读取较少的数据。

l        文件系统优化

     有时候系统性能不好，但当你关闭写log的功能，性能一下子提高很多。因为频繁的打开关闭大log文件时I/O开销非常大，同样记录log到数据库也一样。所以，release版尽量减少写log，或干脆移到裸设备上。

      频繁打开关闭文件对系统性能下降程度是惊人的，可以通过一些变通办法来减少文件的频繁操作。

      例如，原来的缓存持久化实现是保存在XML文件，每次要获得一个配置项，都打开XML文件，通过XPath拿到这个配置项的值，这样效率不高，而且容易把这个XML文件lock住；改进的方法是：通过比较XML文件的修改时间(System.IO.File.GetLastWriteTime)判断是否要再次打开文件，大大提高了效率；另一个可以改进的方法是：启动时读取所有配置到一个静态的HashTable，每次要获得一个配置项都从内存HashTable获取，在最后或适当的时候持久化到XML。

l        代码性能设计

             在编程实现上，代码性能设计也很重要，一些昂贵的操作会占用大量的资源和CPU时间。例如，字符串相加没用StringBuilder, 频繁创建对象，差劲的排序或递归算法，过多的装箱拆箱，过多的使用反射（Reflection），频繁new HashTable或大的数组，用异常（Catch Exception）用做正常的逻辑，使用复杂的正则表达式，等等。具体可以参考《Effective C++》《Effective C#》等书籍。

l  语言的选择

   另外，语言选择也很重要。比如相对于Java, C#, C++, 大多数OLTP系统用C语言效率高的多，因为在所有的高级程序设计语言中，C程序设计语言的运行效率是公认的。再比如我们熟悉的一些框架，框架本身是C#或是Java的，但其核心独立模块是C++封装的，这样可以达到最佳的性能。所以对于一些特定的业务需求目标和数据的具体情况，对于核心的模块或算法，可以用特定的语言来实现以获得更好的效率。

l  应用层   

    比如应用层和数据库的API，在.Net中就有就有DataReader、DataSet和IList等的选择以及转换等，这个根据具体情况而定；还有就是大家常采用的数据的格式化和压缩，以及采用分页，减少传输的数据量；是否可以把一部分处理逻辑放在客户端呢，减少服务端的工作量。界面端也是有很多针对性能优化的考虑，例如绘图，控件重绘都是非常耗资源的，各控件的数据加载和数据绑定性能也各不相同，尽量采用惰性加载，异步加载；初始化和启动速度等都是需要考虑和优化的。

   这些只是我项目经验积累和归纳，水平有限，项目有限，认识更有限，欢迎大家指正补充。

-------------

例1：

现象：广告应用做性能测试时，用1个虚拟用户时，性能正常，用3个虚拟用户时响应有些慢，用10个虚拟用户不到2分钟，就报错java.lang.OutOfMemoryError:Java heap space，负载方面正常
原因：每一次计数都要写入，不停的打开关闭文件太频繁，导致内存不足
解决方案：计数先存入缓存，到一定量时再一次性写入文件，比如10000的量写入

例2：

现象：我平时在linux环境上做开发时很习惯封装类似如下的文件追加函数，而且性能很高。
int appendfike(...)
{
   fopen...
   fwrite...
   fclose...
   ...
}
按上面代码移植到vc6或vc2008时发现性能好低呀，追加上万条记录就感觉到很慢了。
但是我改成只打开一次，而写N条记录这样性能却很高。
请问是文件系统不同的原因造成的吗?还是其它原因呀?

原因：你这封装的也太烂了，每一次计数都要写入，不停的打开关闭文件太频繁，不但导致效率很低，文件本身就很容易坏掉而无法打开。

解决方案：把FILE打开就留下来重复使用；

先将要写入的数据放到一块内存中，积累到了一定数量的时候，一次写入。几乎所有的数据库也都是这么干的，就是在commit(提交)的时候，数据才会真正写入到数据库文件中，否则都是在内存里面。在未commit之前，自己虽然可以看到数据表的变化，但是其它的用户是看不到的。

曾经用sqlite3在android手机上做过一个实验，如果每插入一条记录就commit一次（类似楼主的做法），其性能要比插入300条记录，commit一次差好几十倍。

不管是*nix还是windows，楼主的那种做法，效率都不会高，硬盘也会受不了的。

转：http://www.cnblogs.com/mainz/archive/2007/12/15/996082.html

留言：

Jonny Yu 

博主主要谈的是如何优化系统性能 ，其实我觉得这些技术本身都是很好的，但是一般来说出现性能问题并不是因为缺乏优化的意识和技术，而更多的是由于没有发现的性能瓶颈或者忽视了这个瓶颈的重要性。 对于长期使用的系统的架构设计时，加入应用服务质量指标的检测的目标是很有必要的

@Jonny Yu 

同意，最好有性能测试，压力测试，以及相关工具来找出瓶颈，这个往往比较困难