如何提高Domino应用的性能.ppt

如何提高Domino 应用的性能 朱白云 | FTSS | IBM上海分公司 概述 系统统架构上的性能优优化 应应用架构上的性能优优化 开发发代码码的性能优优化 日程安排 性能优化是系统管理的基本要素 优化内容和流程 影响Domino性能的因素 影响操作响应时间的因素 网络传输时间 从客户端到服务器的距离，数据量，网络延时 请求处理时间 服务器/客户端速度，服务器压力 客户端展现时间 影响服务器资源消耗的因素 服务器工作量 点击数，每次点击的处理工作 应用的后台任务 服务器任务：复制、群集复制、索引等 数据量 开发人员不一定能决定所有因素 但是应用设计确实是重要因素 性能瓶颈可能出现的地方 应用设计之性能原则 Do only what you must 理解应用部署环境 理解应用对网络传输的需求 在设计初始就考虑性能问题 如果设计上有问题，最好的程序员也不能写出满足要求的应用 在现实环境中测试 花时间测试生产环境负载 例如: 实际服务器响应时间 时间网络带宽压力 以普通用户身份测试，而不是管理员 系统层次的注意点 RAID1镜像优于RAID5 Domino程序目录和数据目录最好位于不同的磁盘 数据库索引和数据库本身位于不同磁盘 合理使用Domino系统任务: Update,Replica,Router,AMgr,AdminP,CalConn,Sched,HTTP,RnRMgr 启用事务日志可以有更快的重启速度,但占用一定的系统资源 DominoR7和8具有更高的性能 Domino新版本-性能优化 R8 Native 64-bit Domino （继续支持 32位平台 ） 改变群集复制机制 对 CPU 做了许多额外的重大改进 对 I/O带宽做了许多改进 对 AdminP 性能做了改进 完全支持NSF/DB2 Total disk I/O operations per second for Linux Percent CPU busy for Linux 应用架构的调整点 应用的横纵向切分,将一个访问量大的应用分为若干个, 如按组织层次 分, 按地域分等等 应用Domino和RDB的集成, 将部分结构化数据存储于RDB 应用LEI ND8可通过Composite Application 拆分大数据库 分解为多个小的NSF 在同一个界面显示 Component之间互动 避免超过 20GB的Domino数据库 在慢速网络下，通过Web Services可以提高性能 Web2.0/Ajax提高B/S应用性能 与传统的web应用比较 传统的web应用允许用户填写表单(form)，当提交表单时就向web服务器发 送一个请求。服务器接收并处理传来的表单，然后返回一个新的网页。这个 做法浪费了许多带宽，因为在前后两个页面中的大部分HTML代码往往是相 同的。由于每次应用的交互都需要向服务器发送请求，应用的响应时间就依 赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。 与此不同，Ajax应用将会消除“运行-等待-运行-等待”-web页面交互的固有 特性。这种应用是通过引入一个中间媒介来做到的。此中间媒介又称为Ajax 引擎，它介于用户层和服务器层之间，似乎看来多增加一层到应用程序将会 使得响应更慢，事实却恰恰相反。在开始一个任务开始的时候，浏览器不再 是加载页面，而是加载一个用JavaScript编写，折叠在隐藏结构里的Ajax引 擎。这个引擎负责给用户展示界面和以用户的身份与服务器通信。Ajax引擎 允许用户与应用界面之间进行异步交互，其独立于应用界面与服务器之间的 通信。因此用户再也不会看到当一个操作发送后为了等待服务器的响应而出 现的空白浏览器窗口和沙漏。 传统Web应用的同步交互过程 和Ajax应用的异步交互过程的比较 Google在它著名的交互应用 程序中使用了Ajax异步通讯， 如Google讨论组、Google地 图、Google搜索建议、Gmail 等 亚马逊 Flickr Domino应用设计-性能考虑 算法： 读写模式 视图 动态和静态数据 数据拆分: 归档策略 访问历史数据需求 不一定需要复杂的归档程序，甚至可以手工归档 确保归档正常 Domino应用设计-性能考虑 编码 遍历视图：遍历程序和视图配合 循环嵌套 使用离线功能 并非所有的工作都必须立即完成 可以将部分任务安排在服务器空闲时 后台程序必须被监控，保证可以在规定的时间内做完 Domino应用设计-性能考虑 缓存 对于B/S应用，考虑缓存策略： 浏览器缓存 一次性缓存 Domino服务器缓存 对于c/s应用 本地复本 预先格式化好数据 CACHE参数 Cache.ndk Domino应用设计-性能考虑 处理好一次性事件 对于现有应用，大量改变文档会对性能有预想不到的 营销 重建索引 服务器复制 本地复制 有计划地变更 计划 分组改变 分时 预先警告用户 Domino应用设计-性能考虑 处理好一次性事件 对于现有应用，大量改变文档会对性能有预想不到的 营销 重建索引 服务器复制 本地复制 有计划地变更 计划 分组改变 分时 预先警告用户 数据库属性 视图属性 表单属性 其他编程要素 开发方面的性能优化 不保留未读标记 不覆盖空闲空间 保留LastAccessed 属性 不支持指定的答复层次 Web访问：需要SSL连接 数据库属性 跟踪读和未读的文档会影响应用程序的性能。 例如，假设您有一个有1,000,000 份文档的知识数据库。 有10,000名用户访问该数据库，其中许多用户使用选择的复 制公式本地复制该数据库。当访问服务器上的数据库的用户 最初打开数据库时会遇到延迟，因为该程序必须读取未读标 记表，以确定显示哪些文档为读/未读文档。 要禁用这一功能，选择数据库属性对话框“高级“标签上的不保 留未读标记选项。 不保留未读标记 有未读标记读标记 对100,000条目，3000用户，每秒1.5次访问性能 无未读标记读标记 对100,000条目，3000用户，每秒5次访问性能 覆盖空闲空间将对数据库性能产生负面影响。 做为一种安全性措施，当您删除Notes文档时，Notes覆盖已删 除的数据，以防止任何人重新检索到它。此时，用户是否可以 检索到删除的文档已经无关紧要的，因为数据自身已经被破坏 了。 大多数情况下我们无需保留覆盖的数据。什么时候需要覆盖删 除的数据呢： 服务器和数据库的物理访问受到损害，从而非法用户可 以使用它们。 数据库未加密或ACL使数据库易于遭受攻击。 企业部署了需要这一功能的安全性策略。 如果您的企业、服务器或数据库未出现以上任何一种情形，那 么考虑禁用这一功能选择不覆盖空闲空间选项。 不覆盖空闲空间 Domino跟踪最近访问文档的日期(也就是读或修改文档的最后 时间)。缺省情况下，数据库只跟踪最后修改文档的时间，但 通过选择维持LastAccessed属性功能，数据库还可以跟踪最后 读取文档的时间。 为了实现最佳的应用程序性能，您希望取消选定这一功能。 但是，这一功能对正在按条件归档文档的用户很有用。 我们可以使用维持LastAccessed属性功能，找出最后访 问文档的时间，以确定哪些文档要被归档。我们可以保留 LastAccessed属性来设置归档特性。 LastAccessed属性不适用于Web应用程序。 维持LastAccessed属性 Web访问：需要SSL连接选项为每个 Web事务提供一个SSL(安全套接层)连 接，从而对客户机和服务器之间传输 的所有数据都进行了加密。 在您实现SSL之后，您和您的用户将 体验到近10%的性能下降。 例如，假设您有使用SSL对所有表格 数据进行加密的表格。该表格包含一 个DbLookup 公式。SSL对客户机 和服务器之间的每次事务进行加密， 因此，除了对表格数据进行加密之外 ， SSL还对查询事务进行加密。 可以选择使用SSL的部分 Web访问：需要SSL连接 时间/日期敏感的公式(选择或列公式) 阅读者名称字段 ODBC 访问 视图属性 时间/日期敏感的视图是一种包含具有时 间/日期公式（如Modified 或Now） 的列或具有时间/日期公式的选择公式的 视图。这些视图可以提供强大的功能，但 它们也是高成本的性能方法。每隔15分 钟， Domino服务器运行更新任务来刷新 数据库中的所有视图索引。 系统把包含期间（15分钟）修改的文档 的所有视图标记为过时视图。并且所有时 间/日期敏感的视图被标记为将要过时的 视图。因此，除了更新您合理假设需要更 新的视图外，索引指示器还需要更新所有 时间/日期敏感的视图。这些视图不能被 刷新；它们必须重建。但普通的时间/日 期敏感的视图需要10-50秒来刷新。 可以设置为一段时间后自动刷新 时间/日期敏感的视图是一项非常有用(但 极其昂贵)的功能，因此请小心使用。 时间/日期敏感的公式(选择或列公式) 检查日志文件 如果您不能确定刷新或重建视图的时间，请使用日志文件。在 服务器配置文件中选择Log_update=2，以记录索引指示器刷 新/重建视图的时间。 时间/日期备选方案 在选择公式中使用 Text。使Index程序对此列不敏感。 创建其他条件缩小视图所包含的内容 创建额外的标记缩小视图所包含的内容 时间/日期敏感的公式(选择或列公式) 列排序 视图列上的每个排序箭头增加了视图索引以及它用于刷 新该视图的时间。 从用户界面和维护角度来看，最好是拥有大量排序箭头 的单一视图，而不是多个视图。 从性能角度来看， 关键是避免向视图添加过多的排序箭 头且不减少视图的整体数量。 时间/日期敏感的公式(选择或列公式) ODBC访问属性“在索引中产生唯一的关键字”为数据库的相互 关联提供唯一的关键字。显著缩小了视图的大小。 例如，如果在数据库中只有50个独一无二的类别，这种 隐藏式查找视图将只包括50份文档而不是10,000份。 ODBC访问 只有一种表单属性真正影响应用程序的性能：自动刷新字段。 如果在表单中激活了自动刷新功能，每次从一个字段移动到另 一个字段时，自动刷新功能更新所有先前的字段。这一功能将 影响应用程序的性能。 对于包含验证公式的简单表单来说，自动刷新功能几乎不会影 响性能。对于较复杂的表单来说，考虑使用退出事件而不是自 动刷新。 表单属性 前台程序是从应用程序的用户界面（UI）运行的程序， 例如，从操作菜单手动运行一项代理。 这类程序的优势在于易于诊断，因为您可以通过手工测 试很容易地确定程序运行良好和低效率运行。前台程序的性 能问题经常与字段、按钮、代理相关。 后台程序是在后台运行的程序。 这包括预定的代理，它不时成为与系统性能相关的故障 的来源。 要测试后台程序，审视您的日志是否异常，如完成一项 任务的长时间流逝。如果您正在测试的后台程序是代理，检 查代理日志，查看代理是如何很好地完成其任务的。 前台/后台编程 编程时开发人员最容易犯的一个错误是不能使用临时变量作为检 索数据结果的存储。最明显的一个例子是依靠DbLookup 公式 结果的程序。如果您的程序使用要查找多次的数据，那么将该数 据设为局部变量。现在您可以根据需要多次使用这一数据，包括 ： 检查错误条件时 将数据分解成更小的单元时(例如，多值列表) 对数据进行排序时 另一个典型例子是拥有大量数据和大量用户访问的文档，用户可 以通过点击按钮，以不同的方式对数据进行排序。这种功能旨在 模似悬浮的视图排序功能，但发生在大文档的内部。很明显，这 是一个将您的大量数据设为局部变量，然后对局部变量进行排序 的非常恰如其分的场景。它带来的性能方面的差异非常大。 最后，第三个例子是查找数据库中特定名称的视图的程序。您可 能使用db.views 属性进行循环查找，但您可以通过第一次设定局 部变量，如viewLIST = db.views来缩短程序运行时间，然后您可 以反复使用该临时变量以实现最佳的性能。 临时变量 限制文档中计算的次数可以提升性能。文档中计算执行的次数越多，程序运 行的速度就越慢。无论什么时候您以读模式、以编辑模式、或从读模式切换 到编辑模式时，系统都要进行其它计算。用户应该了解以读模式打开文件和 以编辑模式打开文件所用时间的比例，从而确定要减少的字段/计算。 如果文件经常读取，而不是编辑 在这种情况下，系统触发DbLookup和DbColumn公式，从 而字段包含这些程序公式在读模式下不要运行。例如，您可以在检查 IsDocBeingEdited 的IF语句中把这类公式用括号括起来。关键字字段 是这一程序的首要候选对象，因为它们经常包含DbLookup或 DbColumn公式，例如，一个称为Klist的关键字字段可能有以下公式 ： If(IsDocBeingEdited; DbColumn(“Notes“; “; ViewName; 1); kList) 如果文件经常读取，然后切换到编辑模式 如果用户将文件切换到编辑模式，使用postModeChange事件强 迫文件刷新。此外，选择关键性字段选项“文件刷新选项。” 在选定该选 项之后，当用户从读模式切换到编辑模式时，文件自动刷新一次并强迫 关键性字段重新求值。 如果文件经常以编辑模式打开 在这种情形下，您可以希望尽可能多的把昂贵(性能方面)的程序 转移到按钮中，从而频繁的编辑不会陷入困境。这假设即使在编辑文件 时，大多数用户不需要更改所有关键性字段。 计算字段 通过选择表单属性的自动刷新字段选项， 您可以设置字段值为自动刷新。 这样做会对您的性能产生负面影响，因为 每次用户把鼠标移到表格字段时所有以前 的字段都重新计算。这一繁重计算的目的 是首先检查Input Translation和Input Validation公式，但实际上所有程序都运行 。 选择关键字段属性的“当关键字改变时刷新 域”选项。这提供了胜过表单对话框中“自动 刷新域“选项的性能，因为文档只在关键字 字段中的值更改后才刷新，而不是任何值 更改后都刷新。 刷新字段值 在获得一组文档方面，谁是表现最好的最常使用的LotusScript 方法-我们比较以下常用的LotusScript方法： db.FTSearch db.Search view.GetAllDocumentsByKey view.GetDocumentByKey 在这类测试过程中，使用不同大小的数据库(10,000、100,000 和1,000,000份文档)来了解每种方法是如何很好地运行的。 LotusScript方法 db.FTSearch方法 在对数据库的全文检索后，db.FTSearch返回文档集合。它运行良好 ，但需要当前数据库进行全文索引。此外，根据服务器的Notes.ini 设置，可以对返回的文件集合的大小施加了限制。当然，如果您的 查找是基于多文本字段的内容，那么这是您唯一切实可行的选择。 db.Search方法 在使用视图选择公式进行数据库查找之后，db.Search返回文档集合 。对于大数据库中的小规模集合来说这是相对低效率的执行程序。 例如， 如果您的数据库中有100,000份文档并且您只需查找5或10份 文档，您可能希望避免使用db.Search。在另一方面，它不需要全文 索引和预先创建的视图，因此它是一种非常方便的查询方法。例如 ，如果您对几乎不能控制的数据库进行查询，这可能是您唯一可靠 的选择。 LotusScript方法 view.GetAllDocumentsByKey方法 这种方法一般是检索文件集合最快的方式。唯一的缺点是需要建立相关的视 图。但是，只要您精简了您的视图设计和不使用昂贵的时间/日期敏感的公式 ，这些视图对性能和磁盘空间的影响应可以降低以最小，程序使用 view.GetAllDocumentsByKey从这些视图获得文件集合的速度将非常迅速。 通常，当遍历使用任何这些方法检索到的大量文件时，您的程序应使 用 set doc = DocumentCollection.GetNextDocument ( doc ) 而不是 set doc = DocumentCollection.GetNthDocument 其中i从1增加到DocumentCollection.count。 对于小文档集合来说，性 能下降为最小；但对于大文档集合来说、或者许多用户同时运行的程序来 说会影响