郭宝珠
作者郭宝珠·2014-04-17 16:10
技术经理·北京威克多制衣中心

基于Domino 8的OA系统性能调优解决思路

字数 6400阅读 9006评论 0赞 2
Domino问题解决思路

一、故障分析

通过一周的现场问题分析、故障重现,以管理员只读权限可以看到当前OA系统的性能问题比较严重,但是其计算机CPU/内存等资源占用率并不高,页面加载出现较长等待甚至无反应的状态,面对外部广域网宽带账户登录尤其如此,在部分页面中涉及到的图片及附件加载较多,这种情况下OA无法正常使用。可以确认当前故障是一个典型的由于外部接入、Domino配置、程序设计多种故障点累加造成的性能问题,由此造成的外网用户体验较差。

二、解决思路

1、优化Domino配置参数

此前用户方已经自行优化了较多的如HTTP线程,附件上传限制等参数,根据我们的连接使用分析,认为还有以下部分可以参数化配置调优:

1. 缓冲池参数配置:让Domino动态设置NSF_Buffer_Pool_Size变量。对于低内存的服务器配置,这一点特别重要,大的缓冲区会妨碍核心的内存管理。

2. 使用事务日志。它提供给您大批完整的数据,可以使服务器快速启动,将性能提高10%~20%。 适当地配置一个Domino 服务器运行在中档的WindowsNT机器上,每分钟能传输20,000条消息(每条消息平均 10K字节)

3. 在负载及页面加载测试调优中,我们可以为了提高响应时间,应尽可能优化与I/O相关的文件在磁盘子系统中分布的方式。 如果地址搜索很慢,可以使用户在自己的客户机上使用轻量目录,这样会减少服务器和网络的负载。我们也可以检查姓名搜索缓存(NameLookupCache)的命中率率,一个好的命中率值应该是85%。 如果问题是很慢的页面刷新率或不响应的Web服务器,检查HTTP线程的数量和磁盘使用时间的百分比。设置HTTP线程的数量为1:10(每十个用户使 用一个线程)。  如何来确定一个服务器没有被充分使用?对于当前Windows系统而言,指数是CPU的使用率低于50%,磁盘访问率低于50%,或者经常有多于200MB的可用内存。但是注意 新添加的用户所需要的资源可能不等于您当前用户的平均资源。例如,随着用户数量的增加,每个用户的内存需求会减少,因为固定的内存被分配给了更多的用户。

4. 其他HTTP配置及参数配置

platform_statistics_enabled=1

server_pool_tasks=80

server_max_concurrent_trans=100

Show_Server_Performance=1

NSF_DBCache_MaxEntries=6000

RouterDBCacheSize=6100

Schedule_NO_Validate=1

server_pool_tasks=80

CONSOLE_LOG_ENABLED=1

NSF_Buffer_Pool_Size_MB=256

NLCACHE_SIZE=15938552

CREATE_R8_DATABASES=1

2、改造现有Domino为群集及分区方式

1. 将现有单一Domino服务改造为3Domino群集服务。群集是Domino企业服务器的主要特征。群集能帮助您实现动态负载均衡,在群集中可以自动优化资源的使用。在群集中还可以实现邮件和应用的失效转移,对我们当前我们的OA应用来说,我们需要对Web应用进行ICM群集改造,同样可以实现动态负载均衡和故障切换。根据您的平台,一个分布式系统的群集能以较低的初始成本提供比一个单独庞大的服务器更好的可靠性。另外,群集大大减少了连接服务器失败的用户数量。例如,在Windows平台上,如果一个系统中激活的用户超过750个,我们推荐使用群集。

2. 将现有Domino服务改造为Domino分区服务器,分区功能能提高资源使用率和Domino系统的可靠性,也可以使您在进行开发部署规划的时候充分考虑上线的连贯性和功能分布,按部门或功能来分布服务器。一些组织甚至使用分区来创建“服务级选项”(即将一些重要的经理人员放在一个分区,其他人放在另一个分区)。对于远大的OA系统,分区的利用我的经验是遵循“读写分离,IO分区”原则,即在分区的Domino群集中,将部分查询多(读多)的应用模块和更新多增删改多(写多)的应用模块部署在不同的物理服务器上,各自使用自己的IO资源,有效避免性能问题,另外,基于远大OA的情况,我们可以把这些已经报有性能问题的模块剔除出来,单独部署在独立的群集节点Domino中,这样的分区是解决燃眉之急的有效措施。 

3、通过官方修复的补丁程序解决Domino性能bug

作为一套商业化群件系统,Domino拥有广大的用户群,因此许多用户在使用过程中发现提交的性能问题经过IBM开发人员确认是性能bug,这样的性能缓慢往往通过常规上述方式均收效甚微。这样的情况下,我们就需要关注这些bug修复情况,以此解决目前的性能问题,经过和远大OA系统的版本对比,我们发现最新的bug修复中提供了补丁来修复一些web访问的性能bug,如下:

SPR# MKIN823SZZ - Improved network performance of the web server on W32 when using a high latency network. The web server needs to wait until all data is sent before calling EndRequest.

我们发现如上所述,可以通过Domino 8 Fix Pack 6 补丁修复这个web服务的网络性能问题。

考虑到应用程序的兼容性和升级风险,我们目前暂不考虑Domino升级到V8.5.3

4HTTP优化

我们发现当前OAHTTP线程设置较大,HTTP 线程不一定越多越好!实际上,如果定义的HTTP线程数量高于实际需要的数量,将导致性能递减,内存消耗增加。因此,您应该只定义服务器负载所需的最少 HTTP 线程数量。

针对给定用户负载确定最优 HTTP 线程设置的最佳方法是先运行与用户负载相符的 HTTP 线程设置。然后,在服务器控制台,输入以下内容检查使用的 HTTP 线程的最大数量:

show statistic domino.threads.active.peak

由于该值指示了使用的 HTTP 线程的最大数量,因此在 Server 文档中更适合使用该值设置 HTTP 线程。

如果您已经安装了 Domino 服务器并且大致了解它将支持的Web用户的数量,那么可以将 HTTP 线程的数量设置为Web 用户数的10%,这是一个很好的初始值。例如,如果您预期200Web用户,那么合适的初始HTTP线程的数量为 20。用户运行之后,您可以根据 “domino.threads.active.peak” 统计数据对设置进行 “调优”。如果您经常发现 Peak 值与您定义的值一致,那么应该增加 Server 文档的 HTTP 部分定义的线程的值。

我们建议HTTP线程的配置是:可以指定 Web 服务器所能处理的线程数,或者指定用户在到达服务器的单一连接上所能发送的请求数。通常情况下,指定的线程数表明了能同时访问服务器的用户数。如果活动的线程数已达到指定值,则 Domino 服务器会挂起新的请求,直到另一个请求处理完毕、线程变为可用为止。计算机的性能越好,应指定的线程数目就越大。如果计算机在处理日常任务(如交换内存) 上花费大量时间,则应指定一个较小的线程数。线程选项出现在“服务器”文档的“Internet 协议”“HTTP”附签中。单一连接的最大申请数——浏览器在同一时刻能发送到服务器的请求数。缺省值为1。如果该浏览器能向服务器发送多个请求而不需等待上一个请求的答复,则该设置会影响与 HTTP 1.1 或更高版本兼容的浏览器。

活动的线程数:希望在服务器上同时被激活的线程数。缺省值为 40

活动线程的最小数目:此域没有任何效果,仍存在于“服务器”文档以保持向后兼容性。

配置http线程活动性:当http服务在domino服务器上初始化时,定义的线程被创建,大约每个占用2040kb的内存。一旦改变线程数量,http服务必须重启。

测量线程可用性:在domino控制台上输入命令: show stat domino

  如果Domino.Threads.Active.Peak 值等于 Domino.Threads.Totalhttp请求可能在等待http服务提供空闲的线程。如果这样的话,应该在服务器文档中增加活动线程数量,使 其小于它。最好每次增加减少5个,找到最佳性能。

注意!修改了HTTP线程后就必须同步修改Web服务器的内存高速缓存!

为了优化响应时间,Domino 使用内存高速缓存(又称命令高速缓存)来存储有关 HTTP 命令、数据库和用户的信息。映射有关命令和数据库以及验证用户的信息要花费时间。内存高速缓存存储了这类信息,使得 Domino 能够快速访问该信息。

命令: sh stat domino

domino.cache.design.count应略小于domino.cache.design.maxsize值,参数在服务器文档中修改

  其它domino优化推荐:

internet protocols——http——run web agents concurrently设为enable

basics——optimize http performance based on the following primary activity——_both mail and appliticationns

5、代码优化及重构

此步骤简单的说就是进行代码复审,一般的原则如下:

1) 视图的数量和复杂度:尽量使用少量视图,去掉不必要的和相似的视图,视图列的公式等尽量简单化。

2) 尽量不要用@Today@Now在视图的选择条件或是列公式上.

3) 数据库的文档数量不要太多:要及时做归档。

4) 文档中域的数量:过多的域会影响索引视图时的性能,即使该域没有在视图使用也会。

5) 正在修改的文档数量:会降低视图索引的性能。

6) 删除文档的数量:文档删除后会留下一个删除存根。当复制数据库时,Notes 会使用删除存根识别并删除复本中的该文档。 为了节省磁盘空间,Notes 会根据复制设置“删除最近 [ ] 天内未修改的文档”,从文档删除中清除余下的删除存根。如果 Notes 清除了尚未复制过的删除存根,则在下次复制后已删除的文档将再次出现。此选项位于 Notes 客户机的“文件”“复制”“设置”对话框中的“节省空间”面板上。有很多时候数据库中删除存根的数量比文档的数量还多,这种情况一般发生在比如有一个定时代理,他做的工作是删除该数据库中的文档并从外面的数据源创建新文档并存于该数据库中,我们尽量不要做这种动作。

7) 读者域:会影响视图性能。

对于代码重构的建议,那就是重新开发这些性能不好的应用模块,当前的Domino支持Java开发方式和LotusScript方式,我个人建议,对于外部网络,包括分布式外网用户VPN/宽带拨号等方式的用户,特别是国外用户的情况,建议采用成熟的J2EE方式开发,此方式可以规避许多涉及到业务流程、附件、页面AJAX等造成的页面重定向,寻址转发的耗费时间。相对Domino公式方式来开发,J2EE具备廉价成熟的Web服务,附件及图片Cache缓存服务,业务逻辑WebServices封装高可复用性的优点,和其他开发方式(如:ASP.NetPHPDomino)相比,J2EE具有许多成熟开源的高性能framework框架,有效避免可能产生的新的应用兼容、数据库JDBC性能等问题,特别是对于国内电信网通南北互通的广域网访问有成熟的CDN设计,CDN设计也是成熟的用于接入多样,内容分发的设计之一

CDN的全称是Content Delivery Network,即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。

CDN分发解决方案解决了与静态网站相关的性能和可靠性问题,而在当今在线OA业务体验中,与分发静态和动态元素和应用相关的独特挑战,则由Edge ServerDomino Web ServerCache ServerCDN Server来解决。

至于代码重构,这一块,我初步咨询了国内顶尖的CRM开发商及Domino专业开发服务供应商:XXX。他们给出的报价以项目总包及人天核算计价,每人天约6000元人民币,成本较高,开发质量很高。我也和他服务过的用户取得联系,XXX电信公司OA基于Domino即是他们开发,效果很高,XXXX电力公司OA系统也是他们基于Domino + J2EE开发,在线用户5500人,分布在全省17个分支机构,采用内部局域网核心万兆/千兆到桌面(省电力公司)20M光纤专线(地市电业局)及4M ADSL连接(乡镇供电站)连接,报表及数据内容较多,每个字段公式的计算量较大,页面flashAJAX JavaScript特效较多,OA附件及图片较多,有的原图如招标采购模块:资质复印件、发票复印件、高清图片较多,单一附件平均为30M。此情况和OA的表现形式及性能较接近,具有参考性,XXX开发效果让用户满意,建议瞿总可以适时沟通,技术上我个人推荐此公司。商务上您可以直接接洽。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

2

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关问题

相关资料

X社区推广