（甄志会）PHP应用性能管理与实践
2020-02-27 182浏览
- 1.PHP应用性能管理与实践 听云 甄志会
- 2.目录 l 应用性能管理简介 l PHP应用性能管理的实现原理 l 与常规性能工具的区别 l 图表演示 l 案例实践 TINGYUN.COM
- 3.复杂的应用交付链 TINGYUN.COM
- 4.应用性能管理？ APM Application Performance Management 对软件应用的性能和可用性进行监控和管理， 致力于发现和定位性能瓶颈和故障， 以保证应用达到预期的服务水平（SLA） TINGYUN.COM
- 5.为什么需要APM ● 应用性能监测 • 应用运营阶段 • 复杂的生产环境 • 发布后 ● 应用性能测试 • 开发测试阶段 • 实验室测试环境 • 发布前 TINGYUN.COM
- 6.APM全景图
- 7.SERVER端关注点 l 运行性能 l 服务质量（异常，错误） l 应用拓扑 l 跨应用追踪 TINGYUN.COM
- 8.PHP应用性能管理实现原理
- 9.基本原理 Zend/Opcode/Extensions PHP有两大类模块：Zend引擎、扩展层 1. Zend引擎将PHP源文件解释为一系列操作码（opcode）， 然后循环执行操作码； 2. 扩展层是一组函数、类库和流，PHP使用它们来执行一些 特定功能的操作，例如数据库功能、网络功能。 TINGYUN.COM
- 10.Zend引擎http://www.php-internals.com/book/?p=chapt07/07-01-zend-vm-overviewTINGYUN.COM
- 11.PHP扩展 利用扩展机制，增加特定功能，跟踪PHP引擎执行过程 相关著名的扩展： xdebug / xhprof 听云的PHP APM功能也是一个扩展，实现了跟踪请求及各种 组件性能的功能。 TINGYUN.COM
- 12.嵌码原则 1. 可操作性：自动嵌码 2. 效率：只在必要的位置嵌入尽量简洁的代码 TINGYUN.COM
- 13.可能形成 性能瓶颈 的代码 可能诱发 性能问题 的服务 必要 的位 置 TINGYUN.COM
- 14.对应关系 关注点 名称 Http Request 性能 扩展 Rinit/Rshutdown 函数性能 内核 zend_execute 服务质量 内核/ 扩展 zend_error/ SAPI. http_response_code/ Mysql_query result/ Curl result/… 应用拓扑 扩展 Curl/Mysql/Memcahed/ Redis/Thrift/SOAP/… 跨应用追踪 扩展 Curl/SOAP/… TINGYUN.COM
- 15.与常规性能工具的区别
- 16.PHP-FPM SlowLog TINGYUN.COM
- 17.PHP-FPM SlowLog php-fpm.conf 配置 request_slowlog_timeout = 10 Ø PHP将执行时间超过10秒的脚本记录到慢日志文件 Ø 同时记录到日志中的还有在第10秒正在运行的函数 运行结果 TINGYUN.COM
- 18.APM慢过程跟踪效果 自动采集实际性能占比最高的函数 TINGYUN.COM
- 19.xhprof xhprof 听云APM 嵌码方式 手工嵌入代码或 auto_prepend_file 无需开发人员参与 异常追踪 仅采集代码的性能 除性能信息还包括执行异常，sql错 误等 函数归类 无 自动归纳为数据库、memcache、 redis、web-service等多个分类 数据展现 TINGYUN.COM 手工录入run id，或二次 各种性能报表和汇总数据：堆叠图、 开发汇总报表 曲线图、邮件警告、手机短信报警
- 20.APM图表
- 21.性能概览 TINGYUN.COM
- 22.应用过程性能 TINGYUN.COM
- 23.慢过程追踪列表 TINGYUN.COM
- 24.慢过程追踪详情 TINGYUN.COM
- 25.跨应用分析 TINGYUN.COM
- 26.数据库性能汇总 TINGYUN.COM
- 27.慢SQL列表 TINGYUN.COM
- 28.SQL详情 TINGYUN.COM
- 29.Web-service TINGYUN.COM
- 30.错误概览 TINGYUN.COM
- 31.错误列表 TINGYUN.COM
- 32.错误详情1 连接数据库 121.18.211.81:3306 失败 TINGYUN.COM
- 33.错误详情2 SQL语法错误 TINGYUN.COM where条件缺少borrow_nid数值
- 34.应用拓扑 TINGYUN.COM
- 35.案例实践 -某电商重大故障线索的快速发现
- 36.故障情况 l 某电商某一产品线在2016年3月大促期间出现应用性能缓慢的问题。 l 架构情况：所有应用均负载均衡到几台服务器，这几台服务器每台上 面均有所有应用的代码, 每个应用依赖多个服务。 l 由于业务逻辑关系复杂，存在多个应用相互调用的情况，无法直接定 位问题出现在哪个应用的哪个接口上。 TINGYUN.COM
- 37.分析过程 - 应用性能分解 瓶颈：Redis TINGYUN.COM
- 38.redis TINGYUN.COM
- 39.处理过程 l 通过性能分解曲线，21：00左右发现是redis是性能瓶颈 l 查看慢过程跟踪堆栈、代码及相应配置发现是商品在redis集群内分布 不均。虽然redis集群有十几台服务器，但大部分请求的商品集中在其 中某一台Redis上，导致Redis负载过高，响应变慢。 l 客户快速调整商品在Redis集群内的分配策略，并做Redis设备调整。 l 经过大约半小时的调整，解决了Redis问题 TINGYUN.COM
- 40.分析过程 - 应用性能分解 瓶颈：数据库 TINGYUN.COM
- 41.慢过程跟踪 数据库连接超时 TINGYUN.COM
- 42.总结 l 快速缩小问题范围 l 优化redis商品分布策略 l 优化数据库策略 TINGYUN.COM
- 43.听云免费测试账号申请交流群
