这时我们就需要将代码打成各个片段，记录每个片段的运行时间以缩小范围、进而定位到性能瓶颈的几条语句。但是 Lotusscript 中的 Now 只能精确到秒，显然是不够用的。还好通过 getThreadInfo 我们可以获取到毫秒级的时间值，具体代码如下：

Dim startTic As Long
Dim seconds As Double

startTic = Getthreadinfo(6)
seconds = (Getthreadinfo(6) – startTic) / Getthreadinfo(7)

msgbox “Finished. The code ran for ” & seconds & ” seconds.”

请参考：Updall does not index views flagged as hidden in design properties

注：此条博客不是在开玩笑：）

今天在一个同事的机器上启用了 Fiddler 之后，IE 打开一个页面要十多秒的时间，不用 Fiddler 则没有问题。通过 Fiddler 的 Log 标签页，可以发现以下错误信息：

Fiddler.Network.AutoProxy> AutoProxy Detection failed

最终发现更改以下设定可以解决问题：

IE Internet 选项 > 连接标签页 > 局域网选项 > 取消选择“自动检测设置”项

以上方案供大家参考。

在 Domino 环境下开发时，我们接触的字符编码主要有三种：

• UTF-16：LotusScript 内部的字符编码，中文和英文都占两字节。
• LMBCS（Lotus Multibyte Character Set）：存到文档域中的值以及公式等使用，中文占三字节，英文占一字节。这是在 Unicode 标准推出之前，Lotus 为了解决多语言问题自己使用的编码方式。
• 操作系统的编码方式：我们的 Domino 一般都跑在 GB2312 环境下，中文占两字节，英文占一字节。

UTF-16 和 GB2312 就不多说了，网上介绍的文章非常多。这里着重说明一下 LMBCS。

LMBCS 为了解决多语言问题，将字符分成了若干个组并将其分别编号，从 0x01 到 0x1F，其中 0x01 为 Latin-1（每个文字一字节），0x13 为简体中文（每个文字两字节）。然后每个字符都以自己的组编号开头，这样就实现了在一个字符串里面包含多种语言。例如“中文Test”以如下几个字节表示：

13 d6 d0 13 ce c4 01 74 01 65 01 73 01 74

其中加粗的部分为组编号。很明显这种访问有个很大的问题：每个字符都要标识其组编号，大大的浪费了空间。所以有了改良方案：每个程序（application file）有个默认的组编号，如果一个字符的组编号和默认的相同，则可以忽略不写（我没有找到设置这个组编号的方法，测试过程中它总是 0x01）。于是在默认组编号为 0x01 的情况下，上面的内容变成了这样：

13 d6 d0 13 ce c4 74 65 73 74

这样就有了中文占三字节，英文占一字节的结论。有了上面的背景知识，我们可以得到以下结果：

• Len(“中文Test”) = 6，6 个字符
• Lenb(“中文Test”) = 12，在 LotusScript 中占用 6×2 个字节
• Lenbp(“中文Test”) = 8，按照操作系统的字符编码，占用 2×2+4 个字节
• 值为”中文Test”的域大小为 10 （2×3+4）字节

顺便一提，由于 LotusScript 采用的编码与 Domino 环境中其他地方不同，所以每次读写域值、print 语句都会进行转换，所以减少这种转换可以提升性能。比如：

for i=1 to 100
    print i
next i

进行了 100 此编码转换，而

strTemp = ""
for i=1 to 100
    i = strTemp & i
next i
print strTemp

只进行了一次转换，所以性能上会有优势。

请参考：Computing Strings @Length

索引器任务由 Update、Updall（Update all）两个任务组成，它们通过调用 Notes Index Facility (NIF) 和 Full-Text services，保持各视图和全文索引内容为最新。本文仅讨论视图和索引器任务相关的部分，全文索引相关内容并未涉及。

Update 任务默认写在 Notes.ini 文件的 ServerTasks 参数中，所以它是随服务器一起启动的，持续不断地运行，检查其工作队列以查找需要更新的视图和文件夹。Update 保持两个工作队列：一个即时队列，一个延迟队列。其他服务器组件，例如路由器（Router）和复制器（Replicator），在数据库发生修改时将请求投递给 Update 任务。有些请求投递为延迟，有些请求投递为即时。此请求只包含数据库的完整路径，不包含视图名。延迟队列请求在被处理之前会保持 15 秒，以便在此时间内更新同一数据库的请求作为重复请求而被忽略，通过统一处理来提高性能。这个 15 秒的延迟时间可以通过 Update_Suppression_Time 参数修改。

工作队列中记录了哪些数据库需要更新索引，那么数据库中的具体哪个视图需要更新呢？在数据库的头信息里面，记录了数据库的修改时间；同时在视图的索引信息里面也记录了上次更新索引的时间。通过比较两个时间就可以判断哪些视图需要更新。

Updall 与 Update 类似，但它不是持续不断地运行，也不使用队列；而是根据需要运行。默认情况下，Updall 包括在 NOTES.INI 设置 ServerTasksAt2 中，因此它在每天凌晨 2 点运行。在运行 Updall 时您可以指定选项，但是如果不指定这些选项，则 Updall 会更新服务器上所有数据库中，需要更新的任何视图索引或全文搜索索引。为节省磁盘空间，Updall 还从数据库中清除删除存根（deletion stubs ），并删除符合条件视图的视图索引。

在视图属性的高级页签中，有两个和索引相关的选项：刷新、废弃。先看看刷新选项：

• 第一次使用后自动刷新
  新建视图时的默认选项，也是一个功能和性能比较均衡的选项，无特殊情况下推荐使用。在用户第一次访问之前，索引器不会更新它，减小了无用视图对性能的影响。用户第一次访问时建立视图索引，所以这次访问会比较慢。不过一旦索引建立起来，索引器就会负责更新它，从而保证用户访问时无需等待。
• 自动刷新
  与上一个类似，只是不管用户是否使用过它。这个选项对于用户的体验是最好的，因为打开视图时一般来说无需等待就能查看最新的数据；但对服务器来说压力是最大的，因为即使视图从没有人使用过，依然需要更新它的索引。情谨慎使用。
• 手工刷新
  索引器不更新视图索引，完全依赖用户手工操作，对于服务器来说压力最小。用户打开视图时没有任何延迟，但是看到的数据可能不是最新的。此情况下视图左侧会显示刷新图标，提示用户数据并非最新的，用户点击图标或者按 F9 刷新数据。但对于浏览器应用来说，没有任何方式可以触发索引更新，所以无法使用。
• 间隔 n 小时自动刷新
  手工刷新和自动刷新的混合体。如果距上次更新索引的时间超过了 n 小时，与自动刷新类似；反之与手工刷新类似。用于可预知更新频率的视图，比如每天晚上定时任务会创建文档，则可以设定为 24 小时刷新一次。

废弃选项：

• 如果闲置 45 天
  45 天内没有任何用户访问此视图，则删除其索引。可以通过 Default_Index_Lifetime_Days 参数修改。
• 每次使用后
  用了就删，下次用再重新创建。此方式对服务器压力会很大，一般很少用到，除非真的几乎是一次性使用。
• 如果闲置 n 天
  与第一个选项类似。

请参考：The Indexer and Its Functionality，The basics of Notes view index refreshing，Updall switches, Update and NIF – Notes indexing basics，Indexer tasks: Update and Updall

这种差异会导致最终用户很早就会发现某个视图的速度很慢，但是反映到管理员后，管理员发现速度很理想，直到他用最终用户的ID登录后才发现问题。

产生这种令人不解的效果的原因如下：由于Domino事先不知道应该把哪些文档展现给用户，所以会在用户请求视图时逐条检查，以决定用户是否有权限查看。同样显示20条文档的情况下，管理员只需要检查20条文档就够了，但是对于只能看到几条文档的用户，可能会检查完所有文档，也没有20条文档可以显示。这就是看到文档越少，性能越差的原因。

对于这种情况，一般采用以下两种办法解决：

一、将视图按照读者域分类，然后显示单个分类。这几乎是最佳方案。这样用户对于自己分类下的文档，总是有权查看的，也就没有了性能问题。但是这种方法对于读者域是群组的情况无法处理（除非把群组展开成用户）。

二、将视图作分类（但是不要选中不显示空分类）。这样每个分类下的文档就会减少很多，可以减轻性能问题。但是有的用户可能看到很多空的分类，这也许会让人很恼火。