谈谈Domino邮件迁移过程中的心得--关注大量文档处理时候的效率

 算是支持CSDN开办“IBM Lotus博客之家”吧，也是因为我的blog好像没有分类RSS，把我原创的几个有关的帖子转到这里。

谈谈Domino邮件迁移过程中的心得（1）–背景介绍作者：zongzi 发表于：2007-07-11 23:30 版权声明：采用署名-非商业性使用-相同方式共享 2.5 授权条款，可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明。

 

【背景情况】
1，基本背景
使用Domino邮件服务器，用户数约1600个。

服务器分为：
主服务器（mailServer，一台AS400）；
扩容服务器（bakServer，连接磁盘阵列的PCserver）。

每个用户有3个数据库，分别是：
mailServer上的主邮箱（xxx.nsf）；
bakServer上的扩容数据库（xxx_bak.nsf）和回收站数据库（xxx_rb.nsf）。
其中扩容数据库中是主邮箱中除了最近几天的新邮件之外的邮件的完整备份，有

这种备份的邮件文件器在主邮件数据库中对应存在的都是摘要。
（简单说就是新邮件的完整版在主邮箱，其他邮件的完整版在扩容服务器上。）

2，数据量：
mailServer：165G
bakServer：459G

3，样本情况
选择了三个相对比较小的用户的数据库作为测试样本。
下面简单列出三个样本各个数据库的文件数和大小。
user1：mail，144（文档数），11M（数据库大小）；rb，0；bak，189，71M。
user2：mail，687，81M；rb，4；bak，737，220M。
user3：mail，357，53M；rb，0；bak，1177，155M。
user4：mail，993，866M；rb，8；bak，2789，1839M。
user4也算是比较常见的大小，但是为控制测试时间，多数测试不使用该样本。

4，任务目标
将两个服务器上的数据合并到一起，每个用户从三个数据库合并成一个数据库。
在这个任务目标下，有几个主要的限制：
1）因为要保留用户原来在mail中自定义的文件夹和放置在其中的文档。
对于mail中旧文档的删除，只能从指定的几个文件夹（收件箱、发件箱、草稿、废纸篓）中检索、判断、删除旧文档。
2）迁移操作要求可逆，并可以重复运行。
也就是说，如果迁移异常终止，要能重新运行，而且结果要和一次性运行完毕一 样。
3）要对迁移过程进行记录，用于检查迁移的结果。
4）从bak恢复到mail的文档，要求必须放入收件箱或者发件箱。
bak中大部分文档包含一个叫做formView的域（值为来源视图）；但是实际上有一部分的文档没有这个域，因此需要特别的处理。

5，遇到的问题
开发一些代码来实现合并和迁移数据的功能，本身并不难实现。
基本开发完成后，发现效率成为大问题。

谈谈Domino邮件迁移过程中的心得（2）–测试阶段的效率调整

作者：zongzi 发表于：2007-07-12 00:25 版权声明：采用署名-非商业性使用-相同方式共享 2.5 授权条款，可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明。

开发其实没什么可说的，有点经验的人花点时间总能码出来。

【测试阶段的效率调整】
下面的测试数据，除非特别说明，都是在一台AMD Athlon XP 2500+(1.83GHz)，1G内存的PC上面进行测试的结果。

1，基本版
基本版本（v1）的代码，属于按照顺序逐步完成迁移工作的代码，运行完三个样本的时间在32分钟左右。
从log上分析，发现时间消耗最多的几个环节是：
1）从bak复制文档到mail。（约22分钟左右）
这部分分成3个小环节：文档复制；判断应属于哪个文件夹；放入文件夹。
2）在mail中几个指定的文件夹中，逐个判断文档的时间，对于旧邮件进行删除。（约5分钟左右）

2，增加预先处理来缩短迁移时间
通过增加一个预先处理过程，来缩短实际迁移过程的时间。

对于这个预先处理过程的限制如下：
1）不能对于用户的使用，有任何的影响。
2）不用值守就能运行，也就是不用看着它执行。

经过分析，本次任务中，能进行预先处理的部分包括：
1）mail中判断文档是否是可以删除的旧文档
2）bak中判断文档应属于哪个文件夹

其他可以提高迁移效率的点：
1）将获取mail中可以删除的文档集的方式，从search变为view/folder。
2）将放入文件夹的操作，从一个文档放一次，变成一个文档集放一次。

3，细分最耗时的部分
对于基本版中最耗时间的“从bak复制文档到mail”过程进行细分。
这部分分成3个小环节：文档复制；判断应属于哪个文件夹；放入文件夹。
1）文档复制
这个部分目前没有什么可改进的策略。
2）判断应属于哪个文件夹
在基本版中是先按照fromView处理，没有这个域的，再判断是否来自发件箱。
可选的“优化”有两种：
A）在预处理中，对于没有fromView域的判断是否来自发件箱，并补加fromView域。
B）与用户协商，没有fromView域直接作为投放进收件箱处理。
3）放入文件夹。
经实验，在基本版中，注释掉doc.PutInFolder这句，能节省约5分钟的时间。
（实际上，这一点在最后实际使用中的版本中也一样，由此推断PutInFolder操作是非常耗费时间的。）
对于这个环节，实际可以放到迁移之后，作为候补操作（就是进入买了之后，在用代码遍历一遍，fix一下所属文件夹）。

4，对基本版进行效率优化后
完成预操作1（给mail中可以删除的文档增加标记），耗时约5分钟。主要是可以从正式迁移的时间省下来，在之前先处理掉。
完成迁移操作，耗时约8.5分钟（含PutInFolder操作，无PutInFolder操作时运行时间3分零几秒）。

至此，完成同样的迁移效果，运行时间从31～32分钟降低到（5+8.5）分钟，总时间缩短到基本版的45％。
其中预处理可以在无人值守情况下运行，或者放在主迁移之前，现场测试阶段后期进行。
这样相当于将主迁移时间缩短到基本版的30％左右。

基本版的开发花了2天时间，做目前这些效率优化用了超过之前4倍的时间和精力。
但是为了缩短实际迁移工作的时间，还是需要继续寻找缩短时间的方法。

 

主要介绍我在一次邮件迁移工作中的经验心得。关注大量文档处理时候的效率。