PDF《去哪儿网》

去哪儿网 机票实时搜索引擎的优化 2011.

12 简介 "去哪儿网"是中国最早的旅游搜索引擎,是目 前全球最大的中文在线旅行网站. 机票搜索是"去哪儿网"核心业务之?一. 实时搜索国内293个,国际265个代理商网站. 接口动态请求数 2亿次/天. 前端优化分享 第?一部分: 前端优化分享 前端优化分享 前端优化分享 前端优化分享 JS渲染, 到底做了什么? ?? 前端计算最低价、排序、过滤、分页 ?? 状态维持 ?? 实时更新列表区域(约1500个DOM元素) 前端优化分享 难题? ?? 如何更快? C? 首屏加速 C? 实时更新带来的重绘,让用户感觉不到 ?? 如何更易维护? C? 处理交互及状态维持 C? 数据实时展示 前端优化分享 丑陋的TrimPath页面模板 {var GROUP="normal"} {var loopData = getPureData(pureData,currentPage)} {var recordindex = 0} {for record in loopData} {var recordindex = recordindex + 1} {var bean = FlightList.getBean(record.key)} {if bean}${setPage(bean,currentPage,recordindex)}{/if} {if record.groupType == "av-onewayflight"} {var info = record.info} {if paper.quasipointrate} ${qu} {else} ${languageVars._NO_CORRECTNESS} {/if} …… 前端优化分享 模板的问题 ?? 不够快 C? 需要先被编译,才能使用(Parse Time) ?? 15k 模板文件需要编译约14ms,该时间内浏览器僵死 ?? 搜索结果页模板曾经到达70k,僵死时间为约65ms ?? 以上数据为firefox 7获取,IE6约400ms,用户感觉明显 C? 模板引擎使用eval, with, etc… (Apply Time) ?? 搜索结果页的Apply Time,每次需要约250ms,浏览器僵死. ?? 1分钟内,每隔3至8秒更新?一次 C? Dom Tree完成后,需要用选择器获取元素 ?? 未优化的选择器(如包括 逗号的多元素选择),响应时间高达200ms 前端优化分享 模板的问题 ?? 解耦/维护困难 C? 模板中包含大量逻辑,if / else / for … C? 模板可以嵌套使用,但是… ?? 在模板本身嵌套,很难将子模板组件化. ?? 以组件方式,必须在父组件完成渲染后嵌套. C? 使用id,必须手工维护,代码丑陋 ? foreach ?list}} ? li>${name} ? foreach}} ? 前端优化分享 XControl Qunar的模板解决方案 前端优化分享 XControl能够解决? ?? 够快 C? 实现代码仅3k C? 无需编译 C? Dom Tree 完成后,取得元素方法核心是document.getElementById C? 模板生成时,使用Array Join方式拼接模板片段及子组件 TrimPath或其它模板引擎 XControl Parse ?Time 决定于模板规模

0 Apply ?Time 决定于模板引擎生成的中间代码 join拼接 取得模板渲染后元素 决定于选择器的性能 最快 前端优化分享 XControl能够解决? ?? 解耦/维护容易 C? 易于理解的业务逻辑与UI混排 C? 支持子组件嵌套调用 C? 自动管理ID 前端优化分享 XControl能够解决? ?? 解耦/维护容易 C? 开发?一个 to do list (HTML) ? li>text ?1 ? li>text ?2 ? li>text ?3 ? 前端优化分享 XControl能够解决? ?? 解耦/维护容易 C? 开发?一个 to do list (模板实现) var ?template ? var ?t TrimPath.parseTemplate( ?template ? var ?html t.process( ?data ? document.body.innerHTML html;

? ? document.getElementById('itemXI32').innerHTML hello!';

$("li:?rst ?span").html('hello!');

前端优化分享 XControl能够解决? ?? 解耦/维护容易 C? 开发?一个 to do list ( 基于XControl 实现) func]on ?Item(){} ? ? func]on ?List(){} ? ? var ?list new ?List();

? ? list.append( ?new ?Item( ? list.renderTo( ?document.body ? list.items[0] text ?1 .?nd('item').innerHTML hello!';

前端优化分享 前端优化分享 XControl如何工作? ?? 初始化 A.append(B);

B.append(C);

A.append("hello!") ?? 渲染 A.renderTo(document.body);

?? 触发事件 fire C.onInit fire B.onInit fire A.onInit hello! 前端优化分享 TrimPath与XControl性能对比(IE6) 性能提升73%

0 ?

1 ?

2 ?

3 ?

4 ?

5 ?

6 ?

7 ?

8 ? 首屏数据展示 ? TrimPath ? XControl ? 前端优化分享 小结 C?技术选型需要结合自身业务特点 C?优化需要重视细节 提纲 第二部分:后端优化分享 ?? 数据解析 ?? 内存占用 ?? 设计优化 后端优化 C 数据解析 RDF(XML)解析 ? Jena Dom Sax 避免过早、过度设计 Json? 后端优化 C 数据解析 不走寻常路 把XML当做字符串处理 1. 适合系统内部 2. 对性能敏感 长度72723的XML,Dom处理 335ms 长度72723的XML,字符串处理3ms 后端优化 C 数据解析 修改数据格式 ? ? 使用自定义文本压缩XML (由58k -> 11k,减少80%) 节省25%的CPU消耗 后端优化 C 内存占用 102e3a68ded,DLC,CGO,2008-12-23 112b82c6c1d,CKG,CAN,2008-11-20 class CacheKey { String wrapperId;

String depCode;

String arrCode;

String depDate;

} 1.?每个字段的范围都很小 2.?组合Key节约内存 后端优化 C 内存占用 102e3a68ded,DLC,CGO,2008-12-23 长度:(11 +

3 +

3 +

10 = 27) class String { char[] value;

int offset;

int count;

int hash;

} 在32位系统上,每个普通对象头大小为8字节,数组对象 头为12字节,?一个char类型占用2个字节,所以?一个长度 为27的String对象占用内存大小为:

8 +

4 +(12 +

27 * 2) +

4 +

4 +

4 = 90字节 后端优化 C 内存占用 class CacheKey { String wrapperId;

String depCode;

String arrCode;

String depDate;

} ?一个CacheKey对象的内存占用为:

8 +

4 +

4 +

4 +

4 =

24 字节 wrapperId集合范围约为300个,depCode, arrCode在同?一集合内, 范围约为200个,depDate的集合范围为366 , 也就是这些基础对象占用的内存总量约为:

58 *

300 =

17400 42 *

200 =

8400 56 *

366 =

20496 总计: 46296字节 后端优化 C 内存占用 在生产环境这些数据会达到1000万条,采用拼接字符串的方式占用内存为:

90 * 10M = 900M 新的方案占用内存为:

24 * 10M + 46k = 240M 优化后内存占用比优化前减少内存占用减少660M( 73%) 集群内有40台服务器,可以减少26.4G的内存占用

0 ?

100 ?

200 ?

300 ?

400 ?

500 ?

600 ?

700 ?

800 ?

900 ?

1000 ? 后端优化 C 内存占用 ?? 使用自定义CacheKey可以通过jmap等工具实时查看系统中 CacheKey对象的数量 ?? jmap Chisto $pid 后端优化 C 内存占用 Memcached优化 ?? Key是数据的?一部分 ? Key ? Data / submit=Test&codeBase=ttsgnd00164&codeName=Yoyod&required0= SHE&required1=PEK&required2=2011-12-11 (长度96) Flight_ttsgnd00164_SHE_PEK_2011-12-11 (长度37) 节省(61%) 后端优化 C 内存占用 Memcached优化 ?? 数据是按Slab保存的 C? 内存无法共享 C? 会浪费数据空间 100K ? ?Slab 200K ?Slab 300K ?Slab 后端优化 C 内存占用 Memcached优化 ?? 设置合理的过期时间 杜绝不设置超时的用法 ?? 优化回收过期数据策略 后端优化 C 设计优化 前端数据按需返回 后端优化 C 设计优化 前端数据按需返回 后端优化 C 设计优化 动态调整获取频率 返回数据比例 请求间隔后端优化 C 设计优化 避免不必要的计算 浏览器 服务器 缓存对象 处理结果 添加更新时间 后端优化 C 设计优化 数据闭环 去哪儿网 代理商 轮询模式 去哪儿网 代理商 数据闭环 定时查询 主动通知 感谢hao.lin@qunar.com ? ? lianchun.liu@qunar.com