性能分析

用户登录说起来只是一个很普通的功能，不过它的逻辑一点也不简单。因为登录过程要对个人的信息进行对比验证，验证过程中又要调用相应的加密算法，而加密算法是对性能要求很高的一种功能。

用户登录说起来只是一个很普通的功能，不过它的逻辑一点也不简单。因为登录过程要对个人的信息进行对比验证，验证过程中又要调用相应的加密算法，而加密算法是对性能要求很高的一种功能。

对于性能工程师来说，常见系统的性能数据量级需要烂熟于心，记住这些数字的好处是，每次看到一个性能相关的数据的时候，我们立刻就能知道这个性能数据有没有问题。

在性能行业中，并发用户数、并发峰值如何估算一直是争论的焦点。在之前我发过Eric的《Method for Estimating >the Number of Concurrent Users》的译文。

为了进行容量计划和性能管理，通常需要在实际投入生产之前估计系统的并发用户数，这是因为许多系统资源的消耗与并发用户数直接相关。

如果分析思路方向是正确的，对于 Java 应用和 C/C++ 应用来说，也是几个命令就可以跳到代码行了。前提是要能看得懂堆栈信息。所以一直以来我在讲课的过程中都有画过这样的一个分析思路的图。

对于做性能分析的来说，快速定位的能力非常重要。层层剥离，不要跳跃。 最近在项目中看到不少人做性能问题的解决是全靠蒙的。比如疯狂加线程数什么的。

在创建模型时，需要将相关的参数考虑进来，以确定对模型的影响。不管是在宏观分析，还是在微观分析上，只要思路清晰，都可以用排队论来分析性能，前提是要理解如何用。不要乱用。

这会想聊一下性能分析中的趋势分析。 性能分析首先是全局趋势分析，然后层层细化的过程。 如果只是为了报告的报告，那就另当别论了。

请大家在以后的工作中不要再拿响应时间要遵循 258 原则来说事，因为它实在是离我们太遥远了。 其实性能的工作复杂在很多层面，这只是一个层面而已。 人类在进步，科技在发展，知识要更新，可是人生又苦短

在考虑压力工具中的用户数（有些工具中称为线程数，本文后续都用“用户数”来说明）、响应时间、TPS 三者之间的关系时，想到之前也有人问起过这样的问题，就是他们三者之间的共生的关系到底是什么样呢。

今天在压力过程中，一兄弟说压力上不去了，TPS 随着用户数的增加居然没有一点上升的趋势，响应时间倒是乐呵呵的上去了。

在对一个挡板系统进行测试时，遇到一个由于 TCP 全连接队列被占满而影响系统性能的问题，这里记录下如何进行分析及解决的。

今天记录一个小问题。问题不大，也没什么分析的逻辑可以讲的。但是想着比较典型，所以就写一写。一个 Java 应用,从 visualVm 这里看，有 10 个 new I/O worker 线程。

通常情况下，性能报告中只说 CPU 使用率高的时候，并不能帮助定位问题。因为 CPU 高会有多种不同的情况。

性能分析吧，在每一个细节的事情里，几乎都是要关注的。但是耐心还是很重要的，要不然就会像老司机一样开车不看路了。

Java 应用怎么通过方法定位到代码的具体步骤，快速通过线程 dump 分析知道程序目前处于什么状态，就知道怎么下一步如何下手分析。

在性能分析中，响应时间的拆分通常是一个分析起点。因为在性能场景中，不管是什么原因，只要系统达到了瓶颈，再接着增加压力，肯定会导致响应时间的上升，直到超时为止。

在性能场景的运行周期前启动 MySQL ，在性能场景结束后生成 mysqlreport 会比较有用。