历时差不多15个工作日的domino邮件系统的性能测试算是完成了，于是今天闲暇有空把这个项目做个小结写下来，总结不足之处加以补充，有什么新的发现也能扩展自己的知识面。

　　此次domino邮件系统测试的主要目的有两个，一个是domino邮件系统单机下是否能够支持6000用户日常操作；另一个是考察此系统采用的NAS存储架构的稳定性和性能表现。

　　由于以前从未接触过domino，所以几乎是对domino一无所知，零时抱佛脚找资料学习，到测试开始只是对搭建domino单节点服务和配置邮件系统有所掌握，很多关于domino的配置调优边测试边学习了。

　　domino邮件系统不同于常见的关系型数据库，是采用传统的文件数据库方式存储，每位用户的资料单独的生成一个文件存储在磁盘上，对于人员众多的机构来说，这个存储的数据量是非常巨大的，拿这次测试的邮件系统是针对华夏银行邮件系统，按照20000的用户容量来考量计算，使用web邮件用户模板，每个用户初始数据文件大小大概为20M，要准备总共20000用户的初始化邮件数据则需要（20000*20M）=400G的数据，这些数据还不包括任何邮件，只是为每个用户准备一个空的邮箱，这次的方案中采用NAS存储架构准备了6TB的阵列用作测试环境。

　　此次测试工具包括server.load、loadrunner、iozone，监控工具用到spotlight及windows自带的性能监视器。

　　server.load是lotus domino客户端套件中包含的一个工具，用来生成初始化数据及生成domino负载，由于实际测试中发现一些问题，

　　最终放弃server.load作为负载工具，采用loadrunner来生成负载。server.load负载工具实际对于domino的负载来考量 domino性能也是IBM所推荐的方式，由于server.load通过命令行的方式完成了负载及响应的监控工具，这在很大程度上减轻了负载端网络可能成为瓶颈带来的问题，同时场景的修改更加的灵活便捷，只要通过修改简单的命令行就可以实现了。

　　生成初始化的用户数据是必须要通过脚本方式或者手动方式来实现的，不能如同关系数据库那样采用SQL或者过程来做。

　　比如：在domino系统中通过管理员注册一个新的邮件用户注册完成的过程会自动的在对应的磁盘位置为用户生成一个nsf文件。

　　所以20000万用户手动注册是不可能的，采用批量注册也是一个办法，但是每次能支持多少个也是问题，而且必须首先按照格式设计好批量用户的txt文件，其中用户的资料都需要写进txt文件，工作量也是很大的，server.load在这里就起到了很大的作用。

　　在负载客户机上安装server.load套件，官方的说法server.load每个客户端支持1500虚拟用户，server.load按照每个线程模拟单个用户操作，我们实际测试环境采用10台负载生成机来跑server.load生成初始数据，我们采取将生成初始邮件数据的脚本时间间隔减小以达到加快生成数据文件，周末两天初始数据生成完毕。

　　初始数据的生成脚本在上一篇文章中已经说明：http://www.51testing.com/html/79/n-133279.html

　　在采用server.load来产生实际负载是出现的问题造成我们不能使用server.load来完成最终的测试，遇到的问题如下，我在很多论坛都求助过没但未能得到解决：

　　server.load负载，为什了发送的邮件都跑到mail0和mail1用户，实际上我使用代理产生用户没有mail0的环境：lotus domino server7

　　使用代理namagent.nsf创建用户1-100;(mail1-mail100),并将用户文档拷贝到domino目录的namesnsf文件中；

　　执行server.load设置参数，执行初始化；mail1.nsf-mail100.nsf文件生成

　　执行负载的script参数设置：

　　webpereferneceOFF=0

　　numMessagerecipients=100

　　其他略

　　numMessagerecipients按照配置文档解释意思是，发送的信息接收人的数量，server.load会随机在names.nsf文件库中选择；

　　但实际负载中发现，邮件都只发送给mail0和用户mail1？

　　这是为什么？

　　这个问题不得而知，只能放弃采用server.load负载的方式，零时改用LoadRunner。

　　loadrunner负载做domino测试存在问题：

　　loadrunner 负载对负载生成机器要求相对较高，由于domino自身投递邮件的方式不同与关系数据库方式的响应方式，也就是说，loadrunner投递了一封邮件出去，domino只是先放到mailbox中排队，如果没有队列等待就可以投递，否则只能等待轮到自己在投递，而此时loadruner统计的事务响应时间早已完成，实际上这是不正确的，loadrunner反映的只是web端的响应，实际上邮件也许更根本还没有发送到邮件接收人

　　那里。所以对loadrunner端生成的发送邮件的理解只能是domino服务web响应，并不代表邮件投递完成。如果采用server.load统计出的数据就会是真实的投递邮件响应时间。这是loadrunner在这里所不能办到的，只能通过另外的方式监控。

　　测试场景设置体会到的：

　　有一个原则是一定要记住的，那就是模拟的场景一定要尽可能的接近用户端业务操作场景，这样才有意义。这出现在我和另外一位工程师讨论采用怎么样场景思考时间设置出，邮件系统实际上在发送邮件之前都会有一个书写的过程，这个时间是没有压力的，IBM的基准测试场景推荐15分钟会做一次发送邮件的动作，我们在开始对这个时间做了几次，主要都是减小时间，也可能是在领导的要求下希望尽可能的产生更大的压力，最终发现都缺乏一些说服力，很多时候压力过大使得测试无法进行。讨论在观点无法统一的时候就会短路，很多错误的决定就会长生，所以切记一些遵循的原则。

　　存储测试工具ISZONE使用：

　　这个是从这次存储提供商杨工程师这里学到的，以前由于对存储专门测试的工具关注的很少，几乎没有什么了解。

　　iozone是一个开源的磁盘读写性能测试工具，能够设置的选项异常的丰富。

　　iozone的配置使用改天我再学习过后放上来。

　　下面看一个这次测试显示的面板：

　　readops readbytes writeops writebytes

　　6.82K   137M       8.42K    213M

　　6.73K   150M       7.84K    218M

　　9.12K   197M       11.3K    287M

　　11.3K   230M       11.2K    295M

　　10.6K   212M       11.8K    333M

　　10.5K   209M       12.9K    339M

　　13.6K   238M       11.7K    313M

　　13.3K   226M       10.0K    269M

　　12.4K   216M       11.8K    309M

　　16.7K   276M       9.16K    263M

　　7.15K   117M       6.66K    189M

　　13.1K   207M       10.6K    291M

　　12.6K   161M       5.45K    145M

　　我们这次在实际的测试中监控到阵列的操作吞吐量还是很优秀的，最高的时候达到过每秒读写的和加起来1000Mbytes多，平均能够保持在300MBytes-400Mbytes速度稳定的读写，原始数据的积累在2.5TB左右的情况下依然是这样的表现。所以这次nas的存储是完全能够承受并且超出华夏邮件系统的性能需求的。