查找瓶颈时按以下顺序，由易到难。

    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
   
服务器在不受压情况下，内存占用率最佳为25%，多了影响服务器性能；
压力负载测试中也需要注意：
1、注意区别内存泄露和动态内存分配问题；
2、注意压力端和服务器端的网络流量，一般来说目前的网络不会是系统的瓶颈，但是也需要注意；
3、单机的压力用户数不要过多，否则会影响测试结果，最好不要超过300；
4、分不同的组来运行不同的事务脚本，应真实的模拟系统情况；

-----------
网络时间是从发出第一个http请求到收到ACK的时间。
服务器时间是从收到ACK到第一个字节返回的时间。
ACK是TCP首部中的确认标志，对已接受到的TCP报文进行确认。

-----------
压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个 Web 服务压力测试需要一次模拟多个客户机。Web 服务（或者任何多线程代码）通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件）执行时才会被发现。把这个原则与重复原则结合在一起，您可以应用许多代码路径 和定时条件。

-----------
频率*时间=端口数
这个公式可以延伸到很多额定的场景内。

-----------
应用服务器都通过线程去处理相应的请求，不管容量规划也好，不管做性能测试也好，都要找到比较根本的源头，这里指出的是：线程数（端口）。 

-----------