dorado 5 性能指南 v10.docx
《dorado 5 性能指南 v10.docx》由会员分享，可在线阅读，更多相关《dorado 5 性能指南 v10.docx（76页珍藏版）》请在冰豆网上搜索。
dorado5性能指南v10
DORADO5
性能指南
V1.0
BSTEK
2007年6月
1概述3
2系统设计和分析4
2.1确定设计目标4
2.2避免不合理的设计7
2.3Dorado页面的初始化过程8
2.4GZIP压缩10
2.5客户端缓存11
2.6实例与参考数据13
2.6.1网页大小与响应速度的关系13
2.6.2初始化耗时与CPU的关系13
2.6.3网页复杂度与网页大小的关系13
2.6.4实例分析16
2.7调整开发规范17
3开发技巧18
3.1发掘性能隐患18
3.1.1通过观察现象来定位18
3.1.2利用Dorado的Debugger功能21
3.1.3检查页面大小22
3.1.4消灭垃圾数据和对象24
3.2数据库相关25
3.2.1选择高效的JOIN方式25
3.2.2配置正确的数据库方言26
3.2.3使用分页查询27
3.2.4精简非必要的字段28
3.3Dorado的服务端技巧29
3.3.1把业务逻辑代码留在服务端29
3.3.2避免LookupField的过度使用32
3.3.3用好ViewModel的实现类34
3.3.4正确的使用EL表达式36
3.4Dorado的客户端技巧37
3.4.1利用布局技巧改善操作体验37
3.4.2哪些逻辑代码应该放在onDatasetsPrepared事件中37
3.4.3如何遍历Dataset38
3.4.4disableControls（）和enableControls（）39
3.4.5disableEvent（）和enableEvent（）42
3.4.6警惕主从绑定带来的连锁反应44
3.4.7利用dataset的autoLoadPage属性改善操作体验49
3.4.8为部分下拉框热身50
3.4.9谨慎使用下拉框的mapValue特性50
3.4.10通过copyRecord（）复制记录52
3.4.11利用insertRecords（）批量添加数据52
3.4.12提高查找记录的效率53
3.4.13使用异步操作54
3.4.14利用UpdateCommand的数据感知特性减少flushData（）57
3.5其他客户端技巧59
3.5.1利用setTimeout（）、clearTimeout（）减少调用次数59
3.5.2检查IE内存泄露61
3.5.3如何利用JavaScript代码生成界面元素61
3.5.4innerText和innerHTML63
3.5.5如何高效的拼装字符串63
3.5.6把自定义的JavaScript放入到包含文件中65
4部署和维护66
4.1配置数据连接池66
4.2利用Dorado控制台定位性能瓶颈67
4.3升级Dorado70
4.4其它常见的注意事项70
1概述
本文主要讨论在使用Dorado的过程需要注意的一些与性能相关的要点和技巧，其中也会涉及到小部分Dorado之外的知识，如HTTP、Java、SQL等。
一般而言，当Web应用的性能出现问题时，可能与Dorado的使用方式相关外部资源的主要有5点，按照的他们对于整体性能影响的关键程度排列如下：
●数据库–数据库服务器的负荷过高可能是由于低效的SQL引起的；或者是由于应用当中的运算逻辑设计不当，导致数据库被频繁访问或死锁。
可能导致的响应速度差异：
10倍数量级
出现的几率：
高
●客户机CPU–由于Dorado的客户端主要通过HTML+JavaScript构建，因此Dorado应用的界面相应速度与客户机CPU的运算能力直接相关。
并且由于JavaScript本身是一种“解释型”的语言，不同的编程技巧可能导致迥然不同的性能表现。
可能导致的响应速度差异：
10倍数量级
出现的几率：
较高
●网络带宽–当客户端页面的界面设计不够合理时，例如在单个页面中堆放了过多的组件；包含了大量不可缓存的JavaScript；未被清理的垃圾数据都有可能造成单个页面的体积过大，从而导致网络传输环节的性能瓶颈。
可能导致的响应速度差异：
2倍数量级
出现的几率：
较高
●服务器内存–当Dorado中的部分环节设计的不够合理时可能导致对服务器内存的过程使用，最终造成JVM频繁的执行垃圾回收甚至停止响应。
可能导致的响应速度差异：
2倍数量级
出现的几率：
一般
●服务器CPU–服务器CPU的负荷过高可能是由于低效的算法或不良的编程习惯导致的。
可能导致的响应速度差异：
2倍数量级
出现的几率：
一般
由于Web应用的性能优化是一个很大的课题，而本文的讨论重点是Dorado的使用技巧，因此对于其中的部分内容只会做简要的叙述。
要了解更多关于Dorado之外性能优化细节请参考下列文献：
●《Oracleperformancetuning》
●《EffectiveJava》
●《Web性能优化》
2系统设计和分析
2.1确定设计目标
在开始着手规划应用之前，首先应该了解一下应用最终的运行环境。
系统的最终响应时间往往是这样构成的：
服务端处理的耗时+网络传输的耗时+客户端处理的耗时。
因此，影响响应时间的关键因此应该包括以下6点。
●用户对系统响应速度的敏感程度
不同的用户对于系统响应时间的忍耐极限是不同的，甚至是在同一个系统中用于对不同功能的忍耐极限也是不一样的。
这主要跟用户是否需要频繁的使用某功能相关。
对于那些不常用的界面，例如每月才操作一次的报表或查询类界面而言，用户完全可以为它等上半分钟而没有任何怨言；可是对于那些每天要点击上百次的提交按钮，即使是3秒钟的延时他也无法忍受。
开发人员需要根据与用户的交流和自己的经验来确定那些常用功能的最大响应时间，这一点甚至应该写进需求设计文档，强迫开发人员在开发时对各个功能点的响应时间进行基本的测试。
尽管在开发阶段得到的测试结果很有可能跟最终应用上线时的结果存在差异，但这样做仍可以避免相当一部分性能问题的出现，特别是那些由客户端导致的性能问题。
●在线用户数量
需要掌握将来有多少用户可能同时在线使用系统、某些最常用的功能有多少在线用户。
在分析网络因素对响应速度的影响时，在线用户的数量是一个非常关键的指标。
同时，在线用户数量对于将来的如何进行压力测试也有着指标性的意义。
在进行性能测试时我们常常会提到一个并发用户数的概念，需要特别注意的是并发用户与在线用户是完全不同的概念。
一般而言，我们习惯以20-50的比率来推算并发用户与在线用户之间的关系。
例如：
当系统存在2000个在线用户时，测试时可以以40-100个并发用户作为测试基准。
●网络状况
了解服务器与客户机之间的网络带宽、带宽的分配方式、各服务器之间的连接状况。
一般而言，我们需要结合在线用户数量来做一个综合的分析，以此推测出单个用户可使用的实际带宽。
有时，我们很难通过主观判断来确定用户实际享用的网络带宽，或者即使我们通过分析得到了一个数值，它也有可能与实际情况有所差异。
那么这时利用专业的网络监视工具来进行测试才是更加务实的做法。
可选择的工具有:
BySoftNetworkMonitor这是一个完全免费但有点简陋的小工具，可以用于检测网络实际带宽、上行和下行的流量等。
图表1BySoftNetworkMonitor
BWMeter（是一个非常专业的网络监视分析工具。
利用BWMeter可以完成很多有关网络带宽的测试和分析。
我们甚至可以用它来限制网络带宽，以便测试在低带宽下应用的响应速度。
图表2BWMeter
●客户端的硬件配置
此处的客户端的硬件配置注意是指客户机的CPU。
与传统的BS应用不同，基于Dorado的应用的界面响应速度与客户机的CPU运算能力有着直接的关系。
由于浏览器中的主要运算量来自于解析HTML/XML以及执行JavaScript，并且一般而言，浏览器本身所耗用的内存不会超过100M，因此界面响应速度与客户机的内存和硬盘等的配置基本无关。
CPU的运算速度与界面响应速度（特指纯客户端运算）之间是线性相关的。
按照推测，P41.8的系统的处理时间基本是P43.6系统的一倍。
●服务器的硬件配置
服务器的运算能力和IO吞吐量可能直接影响到应用系统最终的响应速度和最大并发量。
不过一般而言，服务器的运算能力不是影响表现层响应速度的最关键因素。
●客户端的软件配置
这里主要是指浏览器的版本和种类。
目前主流的浏览器大都只有IE和Mozilla两种核心，其中IE又占有绝大部分的市场份额。
想常见的MyIE、Mathon、GreenBrowser、腾讯等都是以IE作为核心的。
而FireFox、NetScape是以Mozilla作为核心的。
这些浏览器的性能各不相同，主要由使用的核心决定。
以IE7的核心为参照依据，假设一个Dorado网页在IE7中打开需耗时1秒（此处不考虑网络传输的时间）。
他们之间的性能对比情况大致如下：
浏览器核心
耗时（秒）
IE7
1.0
Mozilla
1.4
IE6
1.6
由此可见，最新推出的IE7有着较明显的性能优势，特别是相对与IE6而言。
另外，在目前的网络环境中各种浏览器插件、工具栏、流氓软件也是一个不个忽略的因素。
在大部分的客户机系统中或多或少的都会安装一些插件。
这些插件的品质良莠不齐，有些会导致浏览器的运行速度极具低下，甚至一些带有JavaScript拦截功能的插件还会阻止Dorado页面的正常运行。
对于这一点，我们目前还没有有效的解决办法，因为有些流氓软件像病毒一样难以卸载，有时可能不得不重新安装系统才能让浏览器恢复工作。
或许随着像瑞星卡卡之类的“流氓软件查杀工具”的逐渐成熟，此问题会逐步得到缓解。
2.2避免不合理的设计
性能问题的发生并不总是与技术和技巧相关。
事实上，现实中碰到的相当多的性能问题并不是开发人员的问题导致的。
最常见的设计问题表现为以下两个方面：
●在单个页面中堆砌过多的控件和逻辑。
●提出一些对于BS应用而言难以实现的功能要求，最终导致开发人员使用不合理的实现方式。
造成这种设计问题的主要原因往往是来自与设计人员不能很好的区分CS应用与BS应用的不同点。
尤其是对于那些从事了多年CS应用开发的设计人员而言，这个问题往往更加突出。
由于dorado的出现使得Web客户端的开发变得越来越简单、功能越来越强劲。
于是很多设计人员开始将越来越多的CS界面的设计模式照搬到BS应用当中。
这其中最常见的大概就是多页标签式的界面了。
对于部分复杂的界面还会出现多页标签的嵌套使用。
为了编程方便这些标签中的内容往往都是直接放置在一个网页当中。
这样，单个网页的尺寸就有可能超过300K。
如下图：
CS应用与BS应用的运行环境和机制存在着巨大的差异，在表现层体现的尤为明显。
Web界面毕竟不同于CS应用的界面，它的执行速度与CS应用不可相提并论。
尽管这样设计的界面在操作效率可能确实高于传统的BS应用界面，但是在界面初次打开这个环节上的响应速度肯定是大大的降低了。
用户可能无法充分感觉到整体效率的提高。
相反，他们会觉得界面的响应速度变慢了。
虽然Dorado在性能方面已经做了很多优化，但无论如何，他都不能改变BS应用的本质，不能逾越BS应用的诸多限制。
因此，认为有了Dorado就可以完全按照CS应用界面风格和操作风格来开发BS应用的想法是完全不可取的。
尽管新型的表现层框架允许我们将客户端界面设计的更加复杂。
但是，考虑到浏览器的运行速度和网络带宽等因素。
我们仍然应当在重构界面时把握好复杂度的分寸。
根据经验我们大致划定了一个复杂度的警戒线，当您发的自己设计页面可能已经逾越了这条线时，那就是时候考虑一下应该如何重新规划你的设计了。
●编辑框总数超过300个。
●标签页总数超过10个。
●数据表格数超过8个。
●单个表格中的列数超过100个（这样的表格一定很难用）。
●以上条件中有任意3个您已经越过了警戒线的一半。
2.3Dorado页面的初始化过程
Dorado页面的初始化过程大致包括下面的一些环节（从主页面下载完毕后开始）：
1）浏览器解析HTML和XML
2）Dorado客户端引擎构建页面中所有的Dataset（数据集）
3）构建页面中所有的非可视化控件（包括下拉框、命令对象、菜单）。
4）构建页面中可视化控件的可见区域。
5）刷新已构建好的数据敏感控件（数据敏感控件都是可视化控件），以便正确显示出Dataset中的数据。
上述五个步骤当中，前三个步骤中没有什么需要特别注意的要点，并且他们也不是初始化过程中最耗时的部分。
第四个步骤是需要我们好好理解的，它对于如何设计高效的页面有着重要的意义。
Dorado并不是向我们想象的那样，会在初始化阶段就把所有的可视化控件都构建起来。
对于部分在页面乍一打开时肯定不会显示出来的控件，Dorado是不会去处理的。
只要当用户进行某些操作时，需要显示某个控件了，Dorado引擎才会去处理它。
以下面的TabSet（多页标签）控件为例：
在页面的过程中，Dorado引擎只会初始化“员工信息维护”中的可视化控件，而跳过其它两个标签页中的控件。
当用户点击“部门信息维护”时，Dorado引擎会标签页切换之前初始化好“部门信息维护”中所有的可视化对象。
尚未被初始化过的Dorado控件，处于不可用的状态。
如果此时通过JavaScript代码调用“分公司信息维护”中某个编辑框的方法，很有可能会得到错误提示。
Dorado中除了TabSet（多页标签）由此特性之外，GroupBox、SubWindow、OutlookBar也都具有这样的特性。
图表3GroupBox
图表4SubWindow
图表5OutlookBar
第四个步骤会直接影响到第五个步骤的耗时，因为第五个步骤只会刷新那些已经在第四个步骤中被初始化好的那部分控件。
而刷新控件操作是所有这些操作中最耗时的部分。
因此这部分工作量的降低可以直接带来的初始化速度提升的好处。
Dorado的这种处理机制，从总体上并不会减少初始化所有控件的总耗时，但是它可以把这些时间分散到用户的操作过程当中，这对于提升页面的操作体验非常有效。
有时，为了减少在初始化阶段要处理的控件数量，我们可以考虑刻意将那些不是第一眼就必须看到的控件隐藏起来。
例如：
把他们放在一个收缩起来的GroupBox当中。
由此可见，Dorado的页面在一定程度可以承受多个标签页的复杂页面，将较大数量的控件分布到多页标签的各个标签页中，并不会导致Dorado初始化过程的耗时急剧增加。
不过，随着控件数量的增加网络传输和浏览器解释过程的负荷将呈线性上升的趋势。
要观察一个Dorado页面的初始化耗时，可以在页面中按下CTRL+SHIFT+ALT+F12调出一个调试窗口，切换到其中的“Log”一栏就可以看到下图中的信息：
注意，图中所说的DORADO初始化耗时是不包括步骤一（浏览器解析HTML和XML）的。
2.4GZIP压缩
除了缓存之外，GZIP是否开启对于网络传输的效率也有着不可忽视的作用。
GZIP是指将数据压缩之后在经由网络进行传输，而后利用浏览器原生的GZIP支持对数据进行解压缩的技术。
目前的主流浏览器已全部支持了GZIP算法。
对于HTML这种类型的信息，GZIP的压缩算法非常有效，它的压缩比例基本可以保持在80%左右，即100K的HTML信息经过GZIP压缩后可以缩小到25K，这意味这GZIP可以为我们节省75%的网络开销！
有点可惜的是，GZIP算法目前还不支持上传数据的压缩，但毕竟BS应用所占用的大部分网络带宽来自于数据的下载。
因此，综合数据的上传和下载，在进一步的考虑系统底层的网络开销，启用GZIP应当可以为整个应用节约50-65%的网络带宽。
（目前的Dorado默认已启用了GZIP压缩）。
对于那些网络环境不是特别好的应用，GZIP带来的性能提升将是非常显著的。
另外，不必担心GZIP的压缩和解压缩带来的运算量。
因为对于目前计算机的配置而言，对几十K的数据进行压缩和解压缩，这些负荷实在算不上，我们根本感觉不到这些运算工作本身带来的变化。
使用Fiddler工具可以很容易的观察到GZIP所带来的传输量变化。
Fiddler可以模拟发送支持或不支持GZIP算法的请求，来测试两种情况下得到的响应。
实测http:
//61.151.239.187/dorado5/new-feature/new-table.jsp页面。
当GZIP关闭时，响应的数据量为19,668bytes
当GZIP打开时，响应的数据量为5,080bytes
压缩率为74.2%
经过对大量Dorado页面的测试，我们基本可以认为GZIP的压缩率可以稳定在70%-85%之间。
其中对于HTML+JavaScript较多的页面，压缩比率一般较高，可达到80%-90%。
对于XML数据较多的页面，压缩的比率稍微低一些，在60-75%之间。
这是因为Dorado的页面中对于XML数据的输出，本身就已经采用了一种比较紧凑的格式。
例如我们在Dorado页面的输入内容中可以看到类似下面的信息，这是一种比标准的XML更加紧凑的输出方式。
BAIXIAOBO,%u767D%u5C0F%u6CE2,D12,true,true,295113600000,2034.0,%u7855%u58EB,chenbo%40mailServer%2Ecom,www%2Echenbo%2Ecom,
2.5客户端缓存
客户端缓存是否已建立对于此处的结果有着至关重要的影响，因为对于一个Dorado的网页而言，除了能够在主页面中看到的HTML之外，还依赖于一些外部的资源文件，例如：
CSS样式表、JavaScript库文件、图像文件等。
这些外部文件的容量有可能大大超过主页面本身。
不过幸好，这些资源文件都是支持客户端缓存的。
它们只在用户第一次访问这个站点时，才会真正的被从服务端下载到客户端。
在之后的使用过程中，如果这些资源文件被使用到，浏览器会在发起请求时在头信息中包含该资源的客户端缓存的描述（包括是否存在这样一个缓存和该缓存的文件时间戳）。
服务器在接收到这个请求后会将客户端缓存的时间戳与服务端的相应资源进行比对，如果发现客户端的缓存已经是最新的版本了，那么服务器只会向客户端返回一个状态码（StatusCode=304），告诉客户端可以直接使用本地的缓存。
需要提醒的该缓存是与具体的页面无关，即如果有两个页面同时引入了同一个资源文件时，他们在客户端是共用同一套缓存的。
而且缓存是否失效只跟资源文件的时间戳有关，网络重新连接和应用服务器的重启都不会引起客户端的缓存失效。
因此，对于Dorado的应用而言，只有当用户第一次访问这个应用中的任何一个Dorado页面时才会引起CSS样式表、JavaScript库文件等资源的下载。
以Dorado为例，一个普通的Dorado页面中包含下列一些资源（由Dorado5.0070108.1209分析后得出）:
URI
大小
GZIP压缩
说明
skin.css
17.00K
2.50K
Dorado皮肤的CSS文件
preferences.js
1.50K
0.35K
Dorado皮肤的配置文件
const.js
3.10K
1.10K
Dorado自身使用的国际化资源
utils.js
15.50K
4.40K
Dorado的核心JS库文件
base.js
59.80K
14.80K
Dorado的核心JS库文件
control.js
315.00K
72.60K
Dorado的核心JS库文件
411.90K
95.75K
除此之外，Dorado的皮肤中还包含一些图片资源，这都是一些非常小的图片，用以显示界面上的圆角和背景。
以Dorado的默认皮肤为例：
其中共包含有62个图片文件，共计只有22K。
Dorado没有对图片资源启用GZIP算法，因为像GIF、JPG等文件本身已经采用了高强度的压缩格式，对这些资源启用GZIP事实上不能起到什么压缩效果，有时反而会让文件变得更大。
不过，在页面的打开过程中并不是所有的图片资源都会被下载下来，大部分图片只有在真正的用到时才会下载，有些甚至是极少被用到的。
例如表格的列标题中的背景，只有当用户单击将鼠标移动到列标题上时，其深色调的背景图片才有可能被下载。
对于普通的界面，假设上面有按钮，表格，多页标签等元素，在页面打开时只有下列16个图片会被使用到，共计约8K。
datatable_header.gif
scrollbar_btn1_vert.gif
scrollbar_btn2_vert.gif
scrollbar_slider_vert.gif
scrollbar_btn1_hori.gif
scrollbar_btn2_hori.gif
scrollbar_slider_hori.gif
tab_blank_top.gif
tab_2_top.gif
tab_3_last_top.gif
tab_1_first_top.gif
tab_1_current_top.gif
tab_3_current_top.gif
tab_2_current_top.gif
tab_1_top.gif
tab_3_current_last_top.gif
由上面的分析可见，当用户第一次访问Dorado的应用时，客户端除了需要下载主页面本身之外，还需要下载额外的95.75K的CSS文件和JS库文件，以及8K的图片文件。
即需要额外下载不到104K（95.75K+8K）的文件，考虑到这些文件相对比较零散，浏览器需要发出较多次的请求，这会付出一些额外的通信成本。
但最终总的消耗不会超过150K。
同时，上面提到的所有这些资源都是支持客户端缓存的，包括CSS、JS库、图片等。
这意味着刚才提及的150K额外消耗只会在客户机第一次访问应用时才会发生。
由此可见，这些资源不会对应用在网络传输环节的性能表现产生大的影响。
特别是对于应用MIS类应用而言，用户群是相对固定的，我们完全可以假设在系统日常的运行过程中绝大多数用户的系统上都已经建立好了客户端缓存。
以此，评估这些可缓存资源的网络流量对与分析系统的整体性能而言意义不大。
对于一套系统而言，在日常使用过程中，真正的带宽消耗来自于那些动态内容。
这包括JSP或Servlet产生的输出内容以及数据的提交。
因此对于Dorado应用而言，带宽消耗来自与JSP产生的输出内容、动态数据下载/查询、数据提交操作。
而这三个部分中除了数据提交是上传操作，无法使用GZIP之外，JSP和动态数据下载都启用了GZIP算法。
因此绝大部分单个操作的数通信量都在15K-50K之间，极端情况下可能达到100K。
2.6实例与参考数据
2.6.1网页大小与响应速度的关系
网页大小/网络带宽/传输耗时对照表：
带宽（Bit）
128K
256K
512K
2M
数据流量
16K
32K
64K
256K
页面大小
GZIP压缩
50K
12.5K
升级会员 