2008年已经过去了，忙忙碌碌的一年，依旧有点迷茫的一年，静下心来，泡壶茶，点支烟，整理一下自己的心情和思路，也整理一下这些年在性能测试中发现的问题，总结了一些
原因，也算是自己的一个笔记，也为自己的测试路留下一些痕迹。
第一、结构设计不合理造成的性能问题
我发现这类问题是造成性能问题最多的，也是性能调优的重点，通过对结构的调整，性能变化也最明显。结构设计包括程序结构设计和数据结构设计，这两部分一定要综合
考虑，但我发现大多数的软件对程序结构设计偏重的多，对数据结构设计考虑的不是太充分，在下面的例子中我会说明。
例子一：GIS在线编辑图形
在ARCGIS SERVER 9中提供了通过WEB程序来编辑图形的功能，但它的工作机制是，只要客户端启动了编辑功能，后台ARCGIS SERVER就要启动一个进程（类似与启动了一个
ARCMAP），所以对后台的性能压力是非常大的，特别是CPU。如果程序在结构设计的时候没有考虑这些问题，当较多的用户进行图形编辑的时候，系统就会崩溃。事实也确实是这样
，当进行性能压力测试的时候，在5个用户压力下，WEB服务器、数据库服务器的压力都非常小，而ARCGIS SERVER已经几乎不能运行了。这部分的设计应该借鉴中间件的思路，简历
一个一直运行的进程，设立一个最大数，当用户有图形编辑的要求时，就把请求发到进程池中，如果有空闲的进程就直接利用空闲的进程，否则就等待。
例子二：大文件的上传
在一个《企业信息门户》中，允许用户上传一些资料，在数据库设计中，这些资料是保存在一个表中的BLOB字段中，并且有一个编号ID做主键，这样在用户量比较小的时候
是没有问题的，当用户数比较大时，并且并发比较大时，对ORACLE的内存占用很大，并且因为有索引，插入时还要更新索引，开销更大，如果把文件保存到硬盘上而不是保存到数
据库中，随说磁盘的IO速度较慢，但因为是网络的文件传输，网速有限制，这样比存到数据库中的性能要提高很大。
例子三：大数据表问题
在一个关于“测井曲线”成图的系统中，因为是把各个点生成曲线，数据量非常大，这样造成一个表非常大，在进行数据结构设计时，对该表的容量没有充分考虑，造成程
序运行一段时间后非常慢，把大数据表进行分区后，效果非常明显。
第二、程序编写过程中非优化语句
编写高性能代码有很多要注意的东西，因为我关注的是数据库方面的，所以会从SQL语句方面的优化来说一下，程序员在编写代码的时候因为水平不同，并且没有考虑数据库
中数据量的问题，编写的代码在功能测试时是没问题，但当进行稳定性测试的时候，数据库中有很多测试数据的情况下，系统的性能下降就很明显了。比如一个新闻表中，有
ID,NEWS,DATE,CLASSE,AUTHOR这样几个字段，ID是主键，每天大概有2000条的增量，每年有72万条的增量，这样一条语句 select * from table where class ='1'，可以看到就是
建立了索引，该表还是进行全表扫描，当运行一年后，系统的速度大家就可以相象了。
还有一些需要用存储过程的，也是在程序中编辑SQL语句，该使用绑定变量的也没有使用绑定变量，等等问题。
题后话，写程序易，写好的程序不易。性能测试易，做好性能测试不容易。小布老师就说过，虽然现在搞性能测试的人很多，但水平高的做性能测试的，他没碰见几个，他认为先
搞清原理，认真做好有效高效的测试设计才是做好性能测试的基础。
