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