Appstore优化历程与架构演变.ppt.ppt

Appstore优化历程与架构演变 Gaussgao 2012-2-23 从appstore发布到今日，小步前进，快速迭代，用户和访问量逐步攀升。这里叙述这个过程碰到的问题，优化的小招数，以及架构演变历程。appstore还在成长，这个过程仍在持续，期待大家参与一起探讨... 时刻关注性能 二分法定位问题 事前预知；事中监控；事后总结 合理设计读写模型 看问题本质，抓住主要矛盾 常用的工具通用化、组件化 柔性与有损服务 数据最可信 服务可治理 概述 2011-7 系统结构 需求 增加专区：热门推荐、游戏、工具、便民、黄钻 每个专区支持固定槽位设置 每个专区踢重 功能测试通过后的现象 平均响应时间：200ms左右 个别情形下，时间更久，并存在超时。 初步分析： Httpwatch 查看，在重启qzhttp之后第一次访问基本会失败 Qzhttp查看统计，看到qzhttp的平均响应时间为200ms 相比老版首页，新增了8次到mainsvr的交互 2011-09 首页优化 2011-09 首页优化 2011-09 首页优化 2011-09 首页优化 2011-09 首页优化 2011-09 首页优化 问题小结： 1.只考虑快速实现 2.总觉得这么一点小访问量，性能不成问题 性能任何时候都应该得到足够的关注 关注网络IO 对于经常同时访问的的接口要注意整理，合并 2011-09 首页优化小结 时刻关注系统性能 小 结 意识相当重要 起因 平台组应用内页放量 现象 模调告警不断：基本所有cgi都有告警 初步分析： 网站频繁出现超时现象 模调查看最多异常信息是MultiminiInfo接口 网管查看数据库负载超过极限，雪崩，造成服务瘫痪 2011-11 应用内页第一次放量 2011-11应用内页第一次放量 进一步分析 数据库卡死，重启后立即崩溃 存在大量慢查询，很简单的sql也执行几秒。 尝试了desc查看表属性,发现数据库常用的检索字段未做索引！ 2011-11 应用内页第一次放量 2011-11 应用内页第一次放量 优化数据库之后，性能有明显好转。 考虑到业务量还要递增。 做了如下对策 在逻辑层main svr做appinfo cache App的基本信息较少变更，但是访问频繁。App的基本信息尺寸不大，最大2k，平均900字节，目前app的总数小于2万，日增不足100。App也可能存在一定的热度，目前缺乏数据。 采用FIFO的淘汰规则 2011-11 应用内页第一次放量 优化之后 数据库仍然存在抖动 现象 Cache并未起到削峰作用 阶段性部分功能超时：热度、评分查应用列表告警 初步分析： 按热度查询应用列表接口过于缓慢 按评分查询应用列表接口过于缓慢 热度查询为默认，造成数据库卡死，存在大量慢查询 2011-11应用内页第一次放量 2011-11应用内页第一次放量 仔细分析main svr的热度排行查询接口后得出如下结论 热度排行实现需要优化 热度查询 全量cache热度排行的appinfo 没3500秒更新一次 优化 只查询需要返回的appinfo，并使用统一的appinfo cache机制 热度查询接口仅cache热度排行的appid 二分法定位，切实每一步，不要想当然 小结 起因 前台js逻辑bug，反复触发应用内页cgi的调用。 现象 应用内页，用户侧出现系统繁忙 另外有小范围模调告警 初步分析： 数据库访问量大增，性能下降 逻辑svr处于假死状态，每接口性能基本都要达到300ms以上。 2011-11 应用内页异常抖动 2011-11 应用内页异常抖动 结论 前台的bug也会冲击我们的业务。 合理的访问限制机制，很有必要！ 对策 高频率的读写需要采用新的数据层服务。 用tmem替换mysql 为了避免冲击逻辑server，直接cgi访问tmem 2011-11 应用内页异常抖动 数据库索引的重要性 常用的检索字段要建立索引 SQL不能无节制的加重 使用MYSQL时，注意关注公司《MYSQL优化》课程 Mysql是一个业务逻辑较重的系统，打开innodb更是如此 合理的查询值将小于5000次/s 大负载读应用场景，要考虑其他的组件，如TMEM 2011-11应用内页故障的小结 2011-11 系统结构 事前预知；事中监控；事后总结。 这里我们犯了如下三个错误 不知己 不了解目前的系统能支撑多大请求量 无预知 可能的业务增量，后台根本未知情 无监控 故障出现之前，大家都不知道 小结 功能需求 产品将appstore的首页，定义为portal 要引入视频数据 各个模块的数据来源要差异化 首页的热门推荐、必威体育精装版上线的分页也希望做到能够踢重 性能要求 页面要 30ms , 目前已经qzhttp看，已经接近临界值 随着