下载  >  开发技术  >  Javascript  > web前端性能优化

web前端性能优化 评分

一本讲述web前端性能优化以及实践经验分享的书籍,非常不错,值得学习
第12期 王成等:We前端性能优化方案与实践 91 结果,以保证客户端能够区分出每次请求的响应内容,这样也显 因此,应通过适当增加域名来提高同一页面的并行连接数、 著地减少了整个下载过程所需要的时间。 在域名解析、同一域下并行连接数和最大连接数之间适当的 基于 Httpi.1协议的客户机与服务器的信息交换过程如半衡。 图1所示。 在浏览器对服务器进行页面请求的过程中, Javascript的加 速连援一 载会影响其他资源的加载。CSS的加载虽然不会影响其他资源 发出孀1次读求 出次请求一 的加载,但是由于其与浏览器的渲染有关,囚此加载会影响浏览 回送第请求 一进第5次请求 器呈现和用户体验。资源加载方面,浏览器还会限制资源加载 发出关连援请求 的并行连接数和最大连接数。 審户机 服务器 1.2服务器端优化 图1基于HTTP1.1客户机与服务器信息交互图 (1)域名优化 此外,HTP也有状态码和一些缓存的机制。HTTP缓存可 浏览器限制并行连接数使得在同一个域名下加载的资源数 以简单地理解为:当Wcb请求抵达缓存时,如果本地有“已缓存量及其有限。对于页面请求很多的页面来说,页面加载速度必 的”副本,就可以从本地存储设备而不是从原始服务器中提取然受到限制。 采用多域名加载资源,可以提高同一时间内加载资源的数 器的负担,大大提高了网站的性能,从而加快了客户端加载网贞量,最大限度地利用有限的带宽。同时,采用多域名的另外一个 的速度。在H!1.0中提供了一种简单的缓存机制,即客户好处在于,当HML资源携带的Co过大时,将HTL规划 端根据获取文件中的日期和时间与在硬盘上缓存的HTP文件到单独的域名,避免其他资源的请求来回传输很大的 cook ie,从 相对比。如果要获取的文件存在客户端缓存屮,则客户端发送 而避兔了HTP请求大小,提高Web前端性能。 带有If-Modified-Since字段的头部信息的HTTP请求。服务器 局限性:采用多域名不得不面临的问题是域名查找DNS的 程序若发现该文档没有发生改变,则返回304响应,不发生请求 开销,DNS解析可能需要几秒的时间,因此如何在域名解析时 文件,此时客户端接收304响应后直接使用缓存中的文件11。 间消耗和多域名提高并行连接数折中,是采用多域名优化加载 ITP1对缓存进行了加强,并使用了复杂的算法以及机制资源的考虑因素之一。 来实现缓存(过期验证模型和有效性确认模型),对与经常访问 (2)设置缓存 的客户端的请求响应产生的数据流量大大下降,降低服务器上 浏览器使用缓存来减少HTTP请求的大小,避免重复加载 拥塞的产生,同时大大缩短了响应时间,提高了服务器和Web 资源,提高资源的利用率、减少服务器压力、提高前端性能。在 服务器与Web浏览器之间可以设置 Expires, Cache- Control(Max 前端的性能。 在服务器响应请求发送的过程中,浏览器与服务器可以进 Age)、 mod_expires、Etag头部信息等方式进行缓存。 行gzip等约定的双方的压缩协议。 设置Expires头部是最常用的方式之一,通过指定HTTP头 (3)浏览器方面 部的 spires字段一个过期时间来验证是否使用缓存数据。其 在B/S结构结构中,Web浏览器作为客户端最主要的应用局限性在于, Expires头部指定的时间,需要服务器与浏览器进 行时间同步。 软件,客户端统一化,将系统功能实现的核心部分集中到服务器 设置(ache- Conlrol的max-ε来进行缓存,可以避免与服 上,简化了系统的开发维护和使用。Web浏览器可以对页面务器进行实践同步。不过其只支持HTP.1通过同时没置这 资源进行并行加载,但是对同一个域名下会有并行连接数的限两个宁段,可以在HTP1.1时使用 Cache-Control,其他使用 制,同时对浏览器的总连接数也有所限制。不同的浏览器有着 Expires头部进行缓存。 不同限制,图2是国外的社区驱动型项目 Browserscope浏览器 此外,ETag用于检测浏览器缓存中的组件是否与服务器上 对比的结果 的组件一致。设置或移除ETag头部信息,可以有很大的作用, Top Browses F Connect ions 比如Etag对于 Cachecgl页面很有用。特别是论坛,论坛有办 nae score PertTiming Hostname Connections 法为每个帖子页面生成唯一的Etag,在帖子未改变时,查看话题 12/13 属性比较ag就能避免刷新帖子,减少CGI操作和网络传输, □ Fire18→ 13/1多 减少论坛负担。适时移除ETag将有利于提升性能,避免数据存 ie 8+ 7/15 在于缓存时进行不必要的和低效的下载。但它也有一定的局限 □IE 12/13y6 性:ETag降低了代理缓存的效率,用户与代理之间的ETag经常 IE10→ 12/13y 不匹配。而通常Last- Modified与ETag是可以一起使用的,服务 □ Opera12.11 1u/15 器会优先验证ETag,一致的情况下,才会继续比对Last-Modi atar 11/1 fied,最后才决定是否返回304。且在一般情况下, Cache-Con □ Chrome 20 12/1 trdl/ Expires会配合Iast- Modified/ETag一起使用,因为即使服务 Chron26→ 器设眢缓存时间,当用户点击“刷新”按钮时,浏览器会忽略缓 □ Firefox19 13/15 16 存继续向服务器发送请求,这时last- Modified/lag将能够很好 12 利用304,从而减少响应开销。 Firefox 21 11/15 Pes (3)使用CDN 10/15 静态内容(比如图片、CSS、 JavaScript、以及其他 cookie无关 图2常见浏览器的并行连接数与最人连接数 的网页内容)都应该放在一个不需要使用 cookie的独立域名之 计算机应用与软件 2014年 上。因为域名之下如果有 cookie,那么客户端向该域名发出的才继续对所在页面进行解析,这样的空链接使得情况更糟。 每次HTP请求,都会附上 cookie内容。这里的一个好方法就 (3)减小 Cookie的大小 是使用“内容分发网络”( ContentDelivery Network,CDN)。 浏览器对同域下的每个HTP请求都会发送与该域有关的 CDN系统能够实时地根据网络流量和各节点的连接、负载 Cookie数据,因此在 Cookie比较大时HTML页面采用独立域名 状况以及到用户的距离和响应时间等综合信息将用户的请求重有利于提高Web性能。 新导向离用户最近的服务节点上。CDN正是出于缩短资源服 表2为HTML页面 Cookie对响应时间的影响的实验结果。 务器与用户之间的距离而出现的,提高了资源的加载速度。 从该表中可以看出:在慢网速下,一个3000byte的 Cook ie或者 (4)启动Gzi压缩 所有 Cookie的容量为3000 byles将会增加近1s的延迟等待时 在发送文本内容之前可以对内容进行压缩,浏览器支持间。这个结果进一步说明我们应该尽最大的可能减少Coke Gzjp、Deflate等压缩技术,而HTTP协议上的GzP编码是一种的大小,从而较少其对页面响应时间的影响。 用来改进Web应用程序性能的技术。大流量的We站点常常 表2不同的C0okie大小对响应时间的影响 使用GZP压缩技术来让用户感受更快的速度。Gip开启以后 Cook ie size 会将输出到用户浏览器的数据进行压缩处理,因此通过在服务 Waiting Receiving 器压缩再发送给浏览器,可以减少文本资源的大小,提高响应速 0B 679ms 140ms 500B 876ms 143ms 度和加载时间。表1为 YSLow对htp://join.qcom测试有尢 Gzip的结果。 1000B 138ms 1500B 141ms 表1使用YSLow对http://join.qg.com的测试有无Gzip结果 2000 B 141ms TYPE SIZE(KB) GZIP(KB) 2500B 1.44s 41 ms doc(1) 6.0 3000B 1.73s 144ms doc 6.0 2.0 6 131.1 1.4 JavaScript优化 3.7 (1)压缩 Javascript文件大小 Js l1.4 4.0 与压缩HTML文件类似, JavaScript通过去除所有的注释以 s 30.8 15.5 及不必要的空白符达到精简,缩小 JavaScript文件大小的目的。 18.4 除此之外, Javascript还可以通过混淆,改写代码,将函数和变量 Js 2.0 7.1 的名字转换成更短的字符串,增加了反向工程的难度,同时大大 44.4 13.6 减小了代码的大小。精简和混淆可以使用 JSmin工具。 (2)将J 置于底部 17.1 4.1 JavaScript脚本会阻塞浏览器的并行下载(某些高级版本的 15.8 浏览器会有所优化,不会造成该现象),阻塞后续组件的下载和 对其后面内容的呈现。将脚本放在底部可以避免阻塞对页面的 局限性:一般对于ITYM、CSS、 JavaScript等文本内容为主旱现和辟免阻寨资源加载,提高网页响应速度和加载速度,并且 的文件,Gi算法的效率比较高,而图片、pd等二进制文件使可以让代码更加的干净,有利于蜘蛛的抓取。 用Gzp的成效就不明显。而且Gzip压缩需要消耗服务器的资 (3)采用无阻塞Jav 源,而解压缩需要消耗浏览器的资源,对于比较大的二进制文件 使用Ajax加载脚本资源,加载完成后可以evl或者创建 具有非常大的性能消耗。过小的文件(通常小于150个字节)个scp的DOM元素,然后把响应的资源加入scmt元素内,然 不宜进行Gz压缩。 后嵌入head。 1.3HTML优化 通过 JavaScript动态创建 script的DOM元素,设置其src并 (1)减小HTML的大小 附加到 HTML DOM树上。该方法优于上述方法,该方法可以跨 HTML中存在着不少的空格字符,如果能去除这些空格字域获取脚本。 符,就可以减小HTML文件大小。HTML文件缩小的工具有 (4)最小化重排和重绘 HTMLTid或者自己用动态语言去除多余空格、制表符、换行、 最小化重排和重绘可以通过合并dom操作和样式的修改: 注释,以达到压缩HTML文件的减少文件的大小,直接提高了网 a:通过 eteXt或 class Name一次性修改多个样式。 页的加载速度。减少HTMI大小,可以通过代码级压缩,去除空 b:通过设置CSS属性 display,隐藏元素,应用修改,然后重 格字符或注释等无关的字符。精简代码,减少HTML元素的数新显示 量,注重HTML语义化,避免嵌套多层,在减少HTML文件大小 c:使用代码片段( documentf'ragment)在当前DOM之外构建 的同时,还提高了页面渲染速度,提高了网页性能。 个DOM子树,DOM操作完毕后,将其带回文档中。 (2)检查不存在或链接不到的资源 d:将元素用于DOM操作的元素拷贝到一个脱离文档的节 HTTP请求、响应都需要耗费浏览器、服务器的性能,发出点中,DOM操作完毕后,将其带回文档中。 不带任何益处的请求降低了网页的性能。如果请求一个不存在 (5)取消依赖库和按需加载 的 JavaScript文件,并且请求的服务器返回一个错误页面而不是 在开发项目当中,有时为了提高开发效率,引入了很多 JavaScript文件,那么浏览器会等待错误页面的内容下载完毕后 JavaScript类库,而项目中只使用了其中非常少的部分。这造 第12期 王成等:We前端性能优化方案与实践 93 成过大的 JavaScript下载,形成不必要的资源浪费。可以考虑使 用精小的 Javascript库代替或者使用原生的 Javascript代替。 2Web性能优化实践 JavaScript的加载会阻塞浏览器UI线程。如果将还未用到 的 Javascrip封装走来,但需要用到的时候再进行调用加载。或2.1指尖点餐系统 者进行预加载,有利于提高网页性能。 指尖点餐系统是信息化移动生活中,将智能平板联合HT 1.5CSS优化 MI5技术的发展用到点餐流程中,节约了餐厅的人力,提高餐 (1)精简CSS 厅的工作效率、经营收益和顾客满意度。该点餐项目基于Web 解析CSS的过程中会忽略文件中空格、制表符、换行符、格新技术HTMI5搭建,取代本地应用,缩短开发周期,更新周期 式化、注释等字符。除此之外,对部分CSS(比如fort、bak-短,维护成本低,硬件配置低等优点。 ground、 margin等)。同时在项目中经常会遇到写完CSS后没用 但其面临性能优化问题,在恻速较慢的情况下,贝加载速 到造成不必要的CSS代码,这时可以通过 Chrome的 Collect度很慢,极大制约了该系统的使用和降低了顾客的满意度,这也 CSS Selector Profile进行检查,并在代码中去除。 是普遍HTMI5应用相对于本地应用的弱势之一。 (2)CSS位置 2.2性能检测工具及测试环境 CSS应该避免行內样式,采用外部样式。外部样式有利于 1)网络层面上性能检测工具 维护、组件重用以及缓存,同时缩减HTML文件大小,在不采用 (1)采用各个浏览器的开发工具(如 firebug)查看代码,元 样式的情况下,加载速度更快。 素、加载情况以及清除缓存等 需将样式表放在HEAD标签中。浏览器是根据CSS结合 (2)利用 YSLOW、 pagespeed等工具香看网络层面上的性能 OM Tree进行渲染的。CSs的加载影响网页渲染,置于HEAD缺陷。 开头有利于浏览器在解析BODY内容时,加载CSS以便达到逐 (3)利用 Webkit浏览器内置开发工具查看网络 network、 渐呈现的效果,提高用户体验。 Timeline (3)避免耗费性能的CSS写法 (4)利用 Fidder2来限制网速,以及查看 Http请求信息、 在屮使用CSS表达式,它可能会被执行成千上万次,导请求汇总报告。 致页面变慢。 2)浏览器层面上性能检测工县 在CSS的规范写法中,不同的选择器的解析性能是不一样 (1)利用 Webkit浏览器内置开发工具的 profiles监测cpu、 的。样式系统从最右边的选择符开始向左边匹配规则。只要当页面渲染、 JavaScript执行、CS利用率等。 前选择符的左边还有其他选择符,样式系统就会继续向左移动, (2)利用 Speed Tracer浏览器性能监测工具来监测浏览器 直到找到和规则匹配的元素,或者囚为不匹配而退出。根据这 线程、渲染重排、布局板面以及 javaScript执行效率代码进行 个匹配的规则。应该避免使用通配符、相邻兄弟选择符、子选择级别优化等。 符、后代选择符和属性选择符等低效的选择区,更多考虑使用 (3)使用 Spirent测试工具,采用平均事务响应时间、待测 ID选择符、类选择符,规则越具体越好。 系统资源利用率和每秒事务数作为主要测试指标,综合评测 web应用的软硬件性能,并快速定位Web应用系统的性能 1.6图片优化 瓶颈。 (1)减少小图片 3)测试环境 在导航栏或按钮中,常常关联多个带有超链接的图片,这时 (1)清空浏览器缓存。 可以考虑使用 ImageMap,而 CSSSprites将一个页面涉及到的所 (2)清空DNS缓存( confi/ lushan) 有零星图片都包含到一张大图中去,当访问该页面时,载入的图 (3)慢网速下测试(使用 Fiddler工具设置512KB带宽), 片就不会像以前那样一幅一幅地慢慢显示出来了。对于当前网10M网速下测试 UI Thread。 络流行的速度而言,不高于200KB的单张图片的所需载入时间 (4)关闭不相关网页,开启监测T具( Speed Tracer) 基木是差不多的,所以无需顾忌这个问題。利用 CSSSprites能2.3性能评测系统设计与实现。 很好地减少了网页的HTP请求,从而大大的提高了页面的性 (1)Web应用评测过程 能。而且 CSSSprites能够使图片之间更加紧凑,减少图片字节。 在Web应用评测中,每 场景 所以,对于小图片,可以通过 Image Map、 CSSSprites、使用内联图进行一轮测试时,需针对测 片等方式合并多张小图片,来减少HTP请求,减少网页加载时试目标设计测试场景,通过 测武 系统 间,从而提高网页前端性能。 Spirent实施一次负载测试 生成 报告 (2)避免加载过大的图片 统计分析各项指标,生成测 在HTML中,如果需要加载的图片尺寸过大或者过小,都可试报告,根据需要分析查找 以通过前端HTML对其进行缩放。如果图片过大,使造成」不系统性能瓶颈,对相关瓶颈 结果 瓶颈 必要的图片下载开销。其次,可以选择提前将图片进行压缩到进行优化,如图3所示。根 同比例的大小(可以通过图片工具或者在服务器端利用后台代据需要和代价选择测试、优 图3Web应用评测过程 码),从而选用适当比例的图片,有利于节省流量、减少下载开化的迭代次数,选择符合用户需求的最佳迭代方案。 销。另外,选用适当的图片格式有利丁提高网页质量和前端 (2)测试场景设计和选择 性能。 性能测试应该是个全面的测试,测试目标系统各项能力、 94 计算机应用与软件 2014年 发现系统的问题、定位系统瓶颈。如何设计测试用例,实现以最问题如表3所示。 少的测试用例,最大发现系统的性能瓶颈,为优化提供指导。因 表3点餐页面优化前首次加载的 Timeline结果分析 此,既要从事务中的选取具有业务代表性的事件进行单独测试, 现象 乂要对综合业务进行测试,防止因综合业务间事务或数据的相 分析 关性发生读写锁等待,并且设计测试用例时应尽量减少用例间总体页面加载时间超过50秒 512KB带宽下(2G)的加载时间 过长影响推广使用 的重叠,同时又无遗漏。 在指尖点餐系统中,最复杂的页面为点餐页面,该页面使用 jquery单脚本文件加载超过 资源过大,脚本阻寒加载 最频繁,结构最复杂,页面操作多,UI交互多等特点。因此对该 秒 页面进行优化实践,对该系统最具现实意义。图4为该点餐系 脚本加载执行导致页面渲染 面空白时间长达41秒 统的点餐页面截图。 之后 点 资源并行加载上限6个 资源多,并行加载数量少 [定 脚本文件差距较大,最大差距加 载时间达36秒 脚本文件不合理 国位消 ★★★ ★大★真★ 0元糖 已判人应 脚本执行为39ms占据UI在网速较好、非首次加载时,优 Thread比例10%,10M网速下化提高、提高响应速度具有重大 制三〓l ★★★★六 占据19% 意义 150元的 页面渲染时间占据U现存其余页面渲染时间过长,DOM树的 操作综合的1~2倍 重排重构过于频繁 图4自助点餐点餐界面 个空请求, favicon.ico图片找 (3)负载测试流程设计 不到 浪费性能,请求等待的时间更长 Spirent负载测试主要流程如图5所示,其核心是如何配置 所以针对页面渲染采取一定的性能优化措施尤为重要 参数使测试能完成测试目标和对测试日志的分析,找出系统的2.5性能优化 瓶颈;负载由 Spirent工具自动生成。 (1)服务器端优化 设备初始化 虚拟用户 施加负载 设置缓存后的二次加载后的二次加载如图7所示 应用模型生成器 创建复杂模型 负载生成器产生日志 控制机设定负载配置 控制叽获取测试日 和被测系统相关参数 控制机调度 垞制机整理口志 负载生成器施加负载 生成测评报告 负蜚生成器 创建虚拟用户 结束 图7设置缓存期后第二次加载的 Timeline 图5 Spirent负载测试的主要流程 开启Gip压缩后的首次加载 Timeline如图8所示。 2.4寻找性能优化瓶颈 采用H1Ml5点餐应用项目中的点餐页面进行的测试,图6 如活 为点餐页面优化前首次加载的 Timeline。 toan omoi N anoeta 油 中 [.9% UI Thread Available(E72s)'I a 0.8c Pant,55ms 0.6% JavaScript Callback (39m5 图8设置Gzip后首次的 Timeline 0,5 Garbage Collecton (35Ts ■01% Larou (oms) 00.1. Dem Event(Ims) 开启Gzip后加载时间较少了约54%,总资源大小减少了约 Mpf =0. 'e sase real ams) 42%,HTML/ JS/CSS等文件减少了70%左右 (2) JavaScript优化 图6点餐页面优化前首次加载的 Timeline和 UI'Thread 针对该项目进行的 Javascript优化,主要精简代码,去除 图6为点餐页面采用 Fiddler和 SpeedTracer所检测到的 j Query依赖。使得 JavaScript文件大小从82.9KB变到3.8KB。 Timeline和 UI Thread拼合的测试数据。从该图中可以看出的加载时间从22s提高到1ls,减少了50%的加载时间;脚本的 第12期 王成等:We前端性能优化方案与实践 95 执行时间从296ms变为132ms,减少了54.5%。 调整尺寸后,图片总量减少了124.1KB,缩减了81%。网 同时通过优化DOM操作使页面渲染 Paint减少了34%页加载速度提高了接近2s。如图12为优化图片尺寸后的 (19ms),DOM事件响应时间减少」71.5%(10ms)。相应 Timeline,由此可见适当的时机对图片的尺寸进行优化,有利于 Parse html增加了12ms,这是由于采用 innerHTML添加元索提高网页性能,提高加载速度,避免加载过大资源造成浪费。 需要解析成DOM导致的。但是整体来说U线程减少了20ms 左右。图9为进行 JavaScript优化后的测试结果图。 SSeSE 截气醉 市园 图12优化图片尺寸后的 Timeline 图9 Javascript调整后的 Timeline和 UI Thread (5)细节调整 (3) JavaScript、 HTML CSS组件优化 从图12的 Timeline中可以看出,页面中含有一个错误请 从项目之前的 Timeline可以看出CSS的一个文件大小都比求。该错误请求为 favicon favicon可以让浏览器的收藏夹中、 较小,分别为1、1.4、2.6KB。因此考虑将三个CSS小文件合页面上方除显示相应的标题外,还以图标的方式区别不同的网 并,以减少HTTP请求,提高加载资源速度。合并后的大小为站,很多网站并没有添加favicon,因此造成了错误请求,浪费了 3.9KB。文件大小减少了1.1KB,同时减少了2个HTTP请求,资源。 页面加载时间减少了约1秒 2.6优化前后对比 对 JavaScript、 HTML CSS5组件进行代码级别压缩,去除可以 从表4点餐页面优化前后的对比数据分析中可以看出,加 去掉的字符以及对 JavaScript进行混淆。页面大小减少了1.8KB 载时问的减少、页面渲染时间的减少极大提高了应用页面的呈 左右,页面加载时间缩短了约0.5秒,图10为操作后的效果图。 现速度,页面脚本执行时间的降低提高了该应用的响应速度和 整体性能。 哈御 表4点餐页面优化前后的对比的数据分析 页面加载时间页面渲染(Pan时间页面脚本执行时间 优化前 约50s 55 ms 39 ms 园 优化后约85s 37 ms 12 ms 降低了约83% 约32% 约69% 图10页面资源组件压缩后的 Timeline 3结语 (4)图片优化 图片优化采取无损压缩,无损压缩后总体图片的大小减少 本文研究了与Web前端相关的理论,归纳影响Web前端性 了8.8KB,缩减了5%。各个图片的无损压缩效果不一,比如能的因素,并对这些因素进行分析提出整体性、通用性的解决方 Sp. png压缩缩减了26%,其余均为3%左右。页面整体加载速案,具体如下 度提升了40ms左右。相对于不同图片以及图片很多时,进行 (1)首先对于Web前端相关的环境以及技术作为起点,矸 无损压缩可能带来意想不到的效果,不过对于本网页来说效果究与前端性能相关的机制或坏境的原理,并分析其对We前端 一般。图11为图片进行无损压缩后页面的 Timeline 性能的影响有哪些以及如何影响 (2)针对分析与Web前端性能有关的因素造成的影响,提 出整体性(服务器方面、 JavaScript、HTML、CSS、图片)的解决方 案。归纳多种解决方案,并适当分析优劣、使用场合建议。有利 于实际项目开展过程中针对不同方面提前进行优化。 (3)Web前端性能不能仅仅局限于理论和测试,而且与业 写 务密切相关。木文实现一个基于HTMI5技术的Web移动应 四四 用,通过具体分析该项目的性能瓶颈,运用以上分析的理论和解 决方案对其进行性能优化。使用性能以及网络检测工具检测通 2园 过具体解决方案进行优化前后的对比,并进行分析,从而提高了 本文前端优化方案的可行性、真实性,丰富了Web性能解决方 案的具体实施。 图11页面图片资源优化后的页面 Timeline (下转第147页) 第12期 许佳等:个险再保险信息管理系统的设计与研究 147 其中,α称为原保险人的自留比例;是险种的协方差矩阵;为Jav应用基础为核心,搭建了一个完整的个险再保险信息管理 附加保费;"v代表保险公司的总风险;c代表原保险公司分系统,完成了个险再保险计算和业务管理等服务,形成了具有自 保之后经过一个阶段期望达到的收益。通过调节参数A>0的主知识产权的个险再保险信息化产品 大小求解如式(1)的非线性方程组。 在嫡一均值一方差优化模型中,用嫡函数和方差共同作为 参考文献 风险的度量指标,也就是模型的目标凶数,与均值一方差模型相[1]丁慧莹·医疗保险管理系统的矶究与实现[D]·吉林大学,2012 比,这个模型具有明显的不同,把嫡引进了风险度量领城中,使2]胡炳志,陈之楚再保险[M]北京:中国金融出版社,2006 风险的度量更加合理化。。 「31龙文,杨海珍,李晶,等.从国际比绞的视角看中国再保险市场发展 前景[J].统计与决策,2010(13):108-111 3相关设备性能容量评估 [4]付晓宁.银行保险信息管理系统的设计与实现[D].大连理工大 学,2008 [5]杨依华. Webservices技术在保险业务集成系统中的研究与应用 3.1性能评估 LD].电了科技大学,2012 每日数据接口批量性能:数据接口主要包括从统一系统管6]王正宏,李小平基于JEE架构的五层Web开发模型研究[J]现 理平台(UMP接收个险保单数据。考虑公司未来三年业绩增 代商贸工业,2008(3):272-274 长,估算个险保单数第三年每日增量约400笔数据,数据量约[7]何楠楠再保险的最优自留模型分析[D],山东大学20 [8]赵秀菊.再保险的信息熵方法[D].大连理工大学,2006. 为40MB,预估数据接收时间约在10分钟内,于次日上午4点 前完成数据接收,符合业务要求。 每日个险再保险计算批量处理性能:考虑公司未来三年业(上接第95页 绩增长,估算第三年每日需再保计算保单约4000笔数据。由于 参考文献 不同业务种类的再保计算依赖其复杂度和处理方法,故具体计 算时间存在差异。假设采用2CPU,4GB内存的数据库服务器 1 Softpedia. The Average Web Page Loads in 2. 45 Seconds Google Re- veals[Eb/oL].http://news.soflpedia.com/news/the-average-web 考虑再保计算中数据获取、计算和结昊返回等全部处理环节,预 Page-Loads-in-2-45-Seconds-Google-Reveals -265446 shtml 估每个再保计算处理时间约为0.5秒,预估每日处理总时间为[2] Marketinglan. Top retail Websites Not Getting Faster: Average Web 0.5s×4000=2000s,约34分钟,于次日上午8点前完成计算, LoadTimeIs7.25Seconds[Eb/Ol].http://marketingland 符合业务需求。 com/retail-website-load-times-continue-to-decline-with-a-22-decrease- 3.2容量评估 during-the-last-year-37604 3 Onlinegraduateprograms Instant America Network Search EB/OL J 数据量年增长趋势:公司现有存量需再保的个险保单约10 http://w 万笔,考虑公司未来三年业绩增长,预估个险保单数第一年日增[4] Kiss metrics. How Loading Time Affects your bottom Line[EB/OL] 量约100笔,第二年日增量约20笔,第三年日增量约4000 http://blog.kissmetrics.com/loading-time/?wide=1 笔,三年增量约185万笔。参考现有个险保单再保比例,预估再[5] netcraft.Apri2013 Web Server Survey[EB/OL].htp://news.net 保数据第一年日新增约500笔交易,第二年日增量约1000笔交 craft. com/archives/2013/04/02/april-2013-web-server-survey 易,第三年日增量约2000笔交易,三年增量约92万笔。 存储空间年增长趋势:本系统需移行公司存量个险保单、存 6]李成银.百度前端性能监控与优化实践[EB/OL].htp:/ww 12 forum or 量再保险数据和产品信息,存量再保险保单约10万笔,存量再7]操秀英,唐婷中国互联网为何“跑”不出世界的网速[N]科技日 保数据约20万笔,总数据量约3GB;增量数据约为 报,2010,10(3):1. 1)系统三午目均接收新增个险保单约2350笔,数据量约[8]刘斌HML5未来网络应用的核心技术研究[门.自动化与仪器仪 23.5MB; 表,2010(4):30-33 2)系统每日处理约1170笔再保数据,预估日增数据量约[9] Steve sounder. High performance Web sites[M].2007:1-170. 11.7MB。故每日数据增量约35MB左右,年数据增量约9.2GB[10] Steve sounder,etal. Even faster Web sites: Performance best practices 左右。 for Web Developers[ M. O'Reilly Media, 2009: 1-250 本系统用户为公司精算用户、核保用户和系统管理员,目前 [1]张紫微.Web前端性能优化的研究亐应用[D].成都:电子科抆大 总用户数约20人,年用户增量约1人。最大在线用户效20人 学,20 (100%使用),最大并发数5人。 [12]高克立.Web性能的相关技术分析和研究[J].现代电信科技, 2003(11):46-5 [13]周鹏,周海鹰,左德承,等.基于 Spirent的Web应用性能评测[J] 4结语 计算机工程,202,38(24):57-61 14]聂应高.基 Page Speed的网站前端性能优化分析[J].现代图书 经过测试,本设计已经实现了个险再保险信息管理系统的 情报技术,2009(11):69-73 基本功能,系统平均响应时间不超过3秒。本设计的创新点在 15连志刚web系统性能测试过程模型研究|D.西安:西北大学,2012. 于直接面向保险行业,提出了再保险业务的网络化和信息化管[16]赵佳佳Web性能测试与瓶颈分析的研究[D].长春:长春理工大 2012 理的一种技术解决方案充分考虑到公司现有统一系统管理平17]高洁璇,W管理信息系统性能优化研究[D].武汉:华中科拉大 台(UMP)、个人保险管理平台(PIMP)、财务核算管理平台 (FAMP)的独立性和特殊性,通过公司内部平台技术框架,以[18] Browserscope[EB/OL].htp:/w. bIowserscope.or

...展开详情
所需积分/C币:6 上传时间:2018-06-16 资源大小:1.88MB
举报 举报 收藏 收藏
分享 分享