关于性能测试的这点事，值得收藏！
static/image/hrline/line6.png
问：性能测试最好什么时候开始更好？需求阶段、设计阶段、还是测试阶段？
答：有些同事在测试几轮之后，功能稳定了开始介入性能测试，这时才发现性能根本支撑不了预期值。这个时候开发再回头进行系统调优，如果事先选的架构能支撑就好，如果不能达不到预期值，后面讨论或者请教高手发现原先的架构缺陷，再调整架构代价就非常大。基本导致前期的功能测试成果作废。其实各个阶段都有事情做。需求阶段可以整理，评审出性能需求，评审需求可行性时就考虑好数据量和用户量。设计阶段--对预估的需求做设计，举个例子。背景：我们现在使用的是mysql数据库（公司去oracle化），我们要从一个5000W的一个数据表的6个不同查询维度查询数据，比如说城市、行业、地址类型、爱好、性别、时间范围。这样对于mysql的查询常见的优化设计可能是分表、建立索引，但，对于这个场景就不好处理了。数据耦合强，没有办法分表。索引，组合索引太多。后面的处理办法是用mongodb、nosql的方法解决。对于编码和测试阶段可以这样去分不同阶段做不同事情。
编码阶段，可以提出需要，让研发通过单元测试（开多线程）的方式进行压力测试。进行一些单元压力测试测试阶段---测试阶段也有策略的，建议先做一下单一场景单一用户的性能测试。常常会遇到有些同事在没有压单个场景的情况下，就进行负载测试，到处定位瓶颈，最后发现单一用户单一场景都是问题。这就是绕了一圈回到了起点。对于不同类别测试后面会专门的chat介绍。
static/image/hrline/line6.png
问：文章有说通过数据分析识别瓶颈问题，能否稍展开，有没有具体的方法、流程步骤等，还是主要靠经验？性能测试刚入门，请大师指点。答：性能瓶颈分析有专场的chat，本次就谈一下瓶颈分析几大原则和几个关注可以参考：
[*] 逻辑极简化原则：就是去繁为简。
[*] 割据分段法：就是假设问题最可能出现在什么地方,分段分析，使用打桩的方法。
[*] 路由堵截法：就是从压力产生的数据流向开始分析。
[*] 资源监控法：资源监控
主要关注资源有：
[*] CPU（用户占用<通过算法优化等方法解决>、系统占用<堵筛>）
[*] 内存（页面失效（软页面和硬页面）可以剩余内存、可以缓存）
[*] 磁盘I/O
[*] 网络
[*] 进程（处理器时间、进程产生的页面失效、进程所分配的无法与其他进程共享的当前字节数量，看是否有内存泄露等）
[*] 存储，也需要关注。
static/image/hrline/line6.png
问：老师怎么看待js的性能，以及测试如何下手这个环节。开发认为js性能受终端配置影响严重且多数用户会自认为是不是我的网不好之类的，从而忽略掉这个环节的性能测试。答：首先，性能是设计出来的不是被测试出来的。这个文章中有提到。因此一个好的性能需要做好前期的性能可行性设计。没有这个流程的同学，建议研发流程中加入，性能可行性设计。给出现状（使用工具查看现状）：js性能工具: JSLitmus、jsperf、chrome浏览器的profile等。可以检查网页性能情况比如chrome的profeil，操作简单，录制+停止。
可以用工具看到js大小，加载速度等，还可以看看研发的代码。要让研发动起来就的找方法：js常见的优化方法：建议动静分离、建议压缩、建议缓存、建议版本标示、文件合并、方法抽象、避免全局、解耦html和css，具体方法很多。动静分离是常见的。就是把，js、图片、css等静态文件放到不同的服务器上。js由于是静态资源，可以做动静分离，来减轻服务器压力。js做缓存，js由于版本特征明显，需要做好版本标示，保证不会由于缓存带来功能问题。tags可以通过代码或设置中间件如gizp压缩（压缩登记等），其实不光js前台的图片等都有很多优化方法，后面的chat会提到。比如nginx中间件，设置nginx.cfg就能压缩。可以买一本js性能优化的书看看推荐《高性能JavaScript》。
谢谢分享
页:
[1]
