SAAS邮件服务作为一个云端服务，区别于传统的邮件服务系统，其性能要求也不尽相同，性能测试所需要考虑的因素也有所区别，但是总体来说衡量一个邮件系统的基本性能指标还是相似的。本文从SAAS邮件服务的性能指标开始分析，逐步剥离各种SAAS邮件服务的性能测试干扰因素，构架一个简单实用的测试框架。
第一弹，确定SAAS邮件服务系统的性能指标
作为一个邮件服务最主要有三大指标：邮件处理速率，并发连接数，高压力下的邮件滞留时间。
速率：单位时间内接受的邮件或者发送的邮件。
并发连接数：同时能接受多少SMTP请求或者发起多少SMTP请求。
滞留时间：在一定的压力条件下一封邮件滞留在邮件服务系统的时间。
这三者之间也有一定的关系。速率越快，一般来说滞留时间就越短，但是有的时候可以用增加滞留时间在提高邮件的平均接收速率。例如，如果这个邮件服务系统是分层次的，前端接受邮件，中间段处理分析邮件，后端发送邮件。那么这个系统在系统较忙可以让前端服务器无限制的接受邮件无论中段或者后端来不来得及，当邮件系统清闲的时候再慢慢处理滞留在系统内的邮件。从外部看来，这个邮件系统的接受速率相当的好，但是这是以牺牲滞留时间来获得的。速率和并发连接数也有一定关系，邮件系统处理邮件的速率再快都会受到并发连接数的限制，理论上只有无限大的并发连接数才能实现无限大的速率。但是在现实中，往往需要限制并发连接数来得到一个较好的速率。因为太高的并发连接数会消耗相当大的系统资源，最终使得速率下降。所以并发连接数的调节也是邮件服务非常重要的性能指标之一。而且可以想象，在资源竞争的条件下，过高的并发连接数同样会影响到滞留时间的增长。
第二弹，影响邮件服务系统性能指标的内部因素
提到因素分析，可能大家就开始头疼了，影响性能指标的因素有很多，从哪里开始啊?其实，由于各种性能指标已经清晰，要研究影响性能指标的因素，那么离不开内部结构和外部环境两个方面。内部环境当然就是邮件服务的内部结构了，当前流行的结构有以下几种：
1.全透明，整个SAAS邮件服务就是一个proxy，SMTP协议发起端会被直接relay到最终接受端，整个邮件处理的过程保持SMTP连接。这种模式下，所有邮件不需要落地存盘，节省了读写磁盘的开销，但是，对并发连接的要求会比较高，滞留时间和smtp的timeout设定要同时考虑。这是中典型的速率受并发度限制的模型。
2.两层结构。全透明的模式下，SAAS邮件服务的上游服务器到下游服务器之间只有一个SMTPsession。两层结构是指SAAS邮件服务的接受端是一个SMTPsession，向下游发送端又是一个SMTPsession，两个session是顺序关系，没有严格的依赖关系。显而易见的，这种结构比全透明模式多了一个SMTPsession，在邮件被发送之前需要将mail在本地保留一份拷贝，但是一定程度上打破了速率对并发度的依赖。
3.多重结构，比起两层结构，在接受和发送之间增加了一层邮件处理环节，在系统内部之间选择更好的数据流动方式，无论是SMTP还是HTTP或者任何别的什么技术。
一定程度上的系统结构分析会给性能测试带来不少的切入点，或者说观察点。在高效的性能测试中，实时观测是非常重要的。虽然，所能观测的除了以上提到的性能指标以外就是各台功能服务器的一些实时参数。就是这些实时参数，例如cpu，内存，磁盘吞吐，网络吞吐等等参数，会让你察觉真正的系统瓶颈在什么地方。
对于系统分析，需要具体情况具体对待，在这里也就不多做描述了，毕竟各家的系统结构都是内部知识产权，不太好拿出来品评。
第三弹，邮件流量模型
作为一个SAAS邮件服务平台，它并不单独服务于某一个客户，或者某一群客户。虽然某种客户的邮件流量模型都不同，但是整个SAAS平台的邮件模型基本上是确定的。当然他也有一些地域，或者时间上的区别。例如，虽然所有的邮件高峰期一般都在早上的9点到10点之间，但是作为一个服务全球的 SAAS邮件服务平台，由于时差的关系，他的高峰就会被分为几个部分，北美时间，欧洲时间，东亚时间等等。如果要模拟真实的邮件流量模型，就必须考虑多波峰的情况。
除了时间上的因素。更重要的是并发度模型和邮件大小分布模型。例如北美可能平均邮件大小只有15~20K。但是在多媒体发达的日本，平均邮件大小有110K。欧洲又不同，差不多50K左右。
除了平均邮件大小，邮件尺寸的真实分布也非常重要。在现实的SMTP过程中，DATA命令是逐行发送给下游的邮件服务器。所以，大邮件或者说超多行邮件对SMTP性能的影响是相当大的。同样在邮件策略的应用中如果有邮件内容检查，那么大邮件对性能指标的影响相当大。因此模拟合理的邮件尺寸分布对于邮件系统性能测试来说非常重要。当然，邮件尺寸的分布有一定的规律。那就是，带有下极限值的以平均邮件尺寸为轴的近似正态分布。什么意思呢，邮件有最小尺寸，因为他必须符合RFC定义，即使完全没有正文，也会有基本的邮件头。而说他是近似正态分布是因为，小邮件的数量相对偏多，特别是商务邮件，或者正常工作邮件。
第四弹，邮件并发度模型和网络拓扑
其实，所有邮件系统都有最大并发度限制，没有做限制的邮件系统早就被攻击致死了。所以，对于性能测试来说，需要考虑的是多种并发度条件下的邮件服务平台的表现，比如低并发度，中等并发度，高并发度，极限并发度测试等等。SAAS邮件平台处于公共网络，网络拓扑与其所处的网络环境相关。当然也没有什么特别复杂的地方，网络环境的参数在平台部署的时候就可以得到，需要考虑的是，是不是有类似的与流量相关的产品或者服务于该平台共享网络资源，独立分配的网络资源有多大，是否已经完全满足该平台的网络需求等等。
第五弹，SAAS邮件服务平台的策略应用
通常来说，SAAS邮件服务平台的邮件策略对performance会有较大的影响。策略包括:
1.SMTPsession中的策略：
a)DATA之前的策略对于DATA之前的策略，无论发生在什么阶段，对smtp的影响都相近，毕竟数据还没有真正开始传输。但是对于SMTP的并发度还是会有一定的影响。如果DATA之前拒绝邮件的比例较高，将大大提高总体SMTP速率。
b)DATA之后的策略在DATA之后，一般数据内容都已经被检查，那么对这封邮件所采取的行动将会是影响性能的一个因素。例如，是否要隔离 (DISKIO)，是否要发送(NetworkIO),是否删除该邮件(消耗最少)，是否要对邮件进行更改，包括打标签，水印，屏蔽某些内容等等(这种行动系统消耗最大)。
2.内容过滤对邮件内容进行特定的规则进行过滤，最常见的是关键字过滤，或者依据某种pattern。内容过滤对系统的需求很大，特别是对大邮件而言。
3.送信策略当需要发送给下游的时候，送信策略，特别是差错重传的策略对系统性能的影响也是比较大的。
4.用户数模型SAAS邮件服务平台的用户模型也非常重要，包括总体容量为最大支持多少用户数，一般有多少同时在线发信的上游邮件服务器，平均每个SMTP连接发几封信，平均每个邮件地址接受多少邮件量，等等，对性能影响也是显著的。特别是当SAAS邮件服务平台需要对不同的收件人(或者不同收件人的域名)采取不同的邮件策略的时候，用户数模型对性能的总体影响相当大。
第六弹，性能测试模型设计
前面把所有的相关要素都已经列举了一遍，那么性能测试模型就非常方便了。
1.测试工具，任何一种都可以，只要能产生相应的流量和测试邮件就可以。
a)测试工具的配置必须满足需求。特别是能够满足性能测试所需要的流量模型。
b)测试工具需要按照用户数模型来配置SMTP连接和邮件发送
2.测试邮件的选择。
a)按比例配置测试邮件来触发各种邮件策略
b)邮件发发送者和接受者符合用户模型
