性能优化不是某一个人的职责范围,也不是某一个开发阶段的工作内容,而应该是贯穿整个开发流程、每个人员都参与的活动。如果等到项目上线后再进行优化,会导致我们成为需求
的被动接受者。为了避免这种情况,我们应该主动出击,在项目初始阶段就将性能问题融入进去。
需求讨论阶段
开发人员分析实现方案,提出建议,在不影响产品目的的前提下,引导产品经理对需求做一些调整以获取更高的性能。
比如对于产品经理提出的一些实时性统计,可以酌情修改为准实时统计,将缓存利用起来;
对于初始就需要返回大量数据的页面,可以适当调整需求,减少数据量。
方案设计阶段
明确产品业务架构,挖掘潜在风险点;注重动静数据的分离,利用好缓存;根据不同的项目类型,选择合适的技术。
比如需要开机启动的页面(我们的页面是嵌入在公司的客户端内部的),那么尽量静态化或者采用其他支持大并发的部门的存储方案来实现(我们部门因为资源问题,对于大并发支持得还不是很好);
页面数据可以拆分的,只在首次请求中返回静态的缓存数据,然后通过异步加载的方式获取剩余的动态数据;
针对并发量大的内容,可用采用HandlerSocket、主从等支持高并发的方案。
前端模板制作阶段
对样式进行分类,利用CSS Sprite技术,将小图片,特别是一些图标类的图片,整合到一起,减少其数量。
特别是针对长期项目,随着后续需求的增加和修改,样式图片、样式文件的数量会大量增加。这是影响页面性能的一大因素,因为一方面这些资源太分散,会导致请求数增多;
另一方面这些东西大都是和页面可见性息息相关的,请求过慢会导致页面样式错乱。因此可以在模板制作阶段,和前端同事沟通,对图片、样式文件做分类,然后进行合并。
代码编写阶段
遵循一致的代码编写规范,互相codereview,同时借助工具进行代码性能分析,避免代码级别的性能问题。
目前统一采用Zend编码规范,并且有PHPMD工具会对代码进行静态扫描,发送邮件通知开发人员;
同时在测试环境和部分产品的正式环境部署了XHProf,用于代码性能的分析。通过这两个工具,可以排查代码中的逻辑嵌套过深、函数误用、递归等问题。
另外在代码编写完成后,一定要记得将图片、样式文件、JS脚本文件压缩整合后,上传到公司专门的资源服务器上。
一方面是因为资源服务器采用了和产品服务器不同的主机名,能够增加浏览器对资源的并行下载数;另外资源服务器上的文件都做了缓存,也能加快用户二次访问的速度。
切忌在正式产品中使用本地图片和脚本资源。
测试阶段
对于有并发量要求的接口和页面进行压力测试。
对于有并发要求的页面和接口做一个预估,然后主要采用JMeter进行并发测试,保证在预估值之上一定充分余量的情况下,页面或接口仍能正常使用。
上线后
通过线上日志数据,获取产品的正式表现,进行后续优化。
通过各种日志(Nginx日志、Mysql慢日志、XHProf日志等等),分析线上环境和测试环境之间差异导致的性能问题,通过用户端的真实数据来确定优化点,然后按照紧急重要程度进行优化。
转载与:http://www.cnblogs.com/zhouchangju/p/3179143.html