移动商品详情页性能优化总结

移动商品详情页性能优化总结Optimize Result：

RT: 240(ms) -> 100(ms)DB Invoke: 减少30次Cache Invoke: 减少50次Service Invoke：减少10次为公司目测节约至少5台服务器

Background information:

系统迭代非常，活动十分频繁，大量系统依赖Cache滥用DB压力大Action巨大，800行

Process

确定业务
确定数据来源（比如推荐系统、广告系统等等）确定数据实时性要求确定对应的数据，Client需要哪些xhprof分析整个App页面的调用耗时

耗时的API统计

总结需要优化的list

优化具体API

确定产品需求确定产品需求和代码逻辑是否一致删除无用代码（快速迭代会产生大量的无用code）确认是否依赖老旧（低性能）API，如果有，则更改确认依赖的API，是否有冗余数据产生，同时查看冗余的数据是否为系统需要确认DB是否存在循环调用，以及是否可以优化确认Cache用法是否正确，是否存在循环使用从宏观角度看，是否有重复调用，比如调用了两个不同API，但是数据结果一样确认条件判断是否正确，一些状况下不定需要调用，客户端可能会用不到O(n) -> O(1)，减少时间复杂度，空间换时间，多用map

其它优化

auto_load优化：通过Cache减少计算和网络I/O（通常是DB的）event优化：一些数据的搜集项能否异步，比如通过消息队列解耦，能够提升不少的性能，同时代码也更好维护逻辑切分：将巨大的Action进行切分，

Summaries

合并网络I/O（主要是DB和Cache以及Service）是最基础的，但是错误犯得最多的PHP的计算效率是很快的，但是时间复杂度依旧要考虑Cache的滥用很严重，Cache的正确使用应该是缓存API的计算结果，从而减少网络I/O、autoload、计算的时间产品迭代很快，很多以前耗时的操作，在新版本可能不需要了，所以对产品（业务）的理解，是优化业务系统的前提（往往效果很好）确定数据的实时性要求很重要，它决定了你是否应该用Cache以及Cache的生命周期HTTP不稳定，但是出现的概率比较小明确耗时很重要：Search > DB > Service（公共服务） > Cache，它让你知道你应该用什么工作做优化Event的通知一定能要异步，它不但提升性能，而且解耦了系统以上的优化方式，使用于任何PHP的业务系统