六、性能分析
星期一, 10月 6th, 2008六. 性能分析
诊断问题时，第一步将问题分为五种类别：
l DNS查找时间
l 连接建立时间
l 服务器停止时间
l 传输时间
l 连接关闭时间
这些步骤的顺序总是这样的。
1 通过自己编写脚本找出瓶颈
以下指导原则可以解决可能出现的五种瓶颈：
l 如果DNS是瓶颈所在，那么可能是测试脚本指定的local dns链路不好，或者是我们的域名的DNS链路不好。
l 如果连接时间是瓶颈，则一定是网络存在问题。可能是连接建立时，由于网路设备超载而丢失了一个数据包。路由器、交换机、线缆、网卡也都可能出现问题，都应该进行检查。
l 如果服务器静止时间是瓶颈，则服务器可能会出现某种程度的超载，更换为更好的硬件或使用更加优化的服务器应用程序或数据库即可解决这个问题。
l 如果传输时间是瓶颈，则问题在于客户端连接速度太慢，或者是要传输的内容过大所致。
l 如果连接关闭是瓶颈，则仍然是网络问题。
2 查看连接
另一种了解站点情况的不错的方法是在创建和断开连接时观察连接。可以在Web服务器、中间件或者数据库的某个回路中运行netstat。
3 日志分析
3.1 平均传输大小
3.2 响应大小分布
对服务器的响应大小的分布有一些了解是十分重要的。根据响应大小的分布信息，你可以决定使用多少台服务器、每台服务器针对不同的响应大小这种方式对你是否有意义。
4 点击率
4.1 可变负载和队列长度
4.2 究竟应何时记录访问次数
4.3 谁是访问率最高的用户？
通过日志的分析，就可以很快找到访问频率最高的用户的IP地址。
4.4 哪个进程是我的？
可以用哦个lsof -i:port来识别进程，
或者fuser 80/tcp
4.5 谁在使用该文件
fuser还可以用于找出谁在使用Linux上的特定文件。fuser filename，则可以报告除所有使用该文件的pid。
4.6 我的进程正在使用哪些文件？
只需找到进程ID，然后在/proc下查找该数字即可。在/proc下，将会找到名为fd的目录，在该目录中，每个文件描述符都是到一个真实文件的符号连接。如：我的Web服务器的pid是7428，则有：
# ls -l /proc/7428/fd
total 10
lrwx—— 1 root root 64 Sep 30 21:55 0 -> /dev/null
lrwx—— 1 root root 64 Sep 30 21:55 1 -> /dev/null
lrwx—— 1 root root 64 Sep 30 21:55 2 -> /dfs/web/nginx-0.5.35/logs/error.log
lrwx—— 1 root root 64 Sep 30 21:55 3 -> /dfs/web/nginx-0.5.35/logs/error.log
lrwx—— 1 root root 64 Sep 30 21:55 4 -> /dfs/web/nginx-0.5.35/logs/acc.log
lrwx—— 1 root root 64 Sep 30 21:55 5 -> socket:[7195389]
lrwx—— 1 root root 64 Sep 30 21:55 6 -> socket:[7195392]
lrwx—— 1 root root 64 Sep 30 21:55 7 -> socket:[7195393]
lrwx—— 1 root root 64 Sep 30 21:55 8 -> socket:[7195395]
lrwx—— 1 root root 64 Sep 30 21:55 9 -> socket:[7195396]
4.7 如果数据库挂起，将会出现什么情况？
要知道这个问题的答案，可以简单的将数据库中的一个关键数据表锁住并查看在Web站点上会发生什么情况。
这样做往往会出现以下几种原因：
l 一种原因是为了查看在点击该Web站点的用户达到一定的数量后，数据库中有多少用户请求在列队等待；
l 另外，你使用这种方法来模拟一个过于繁忙的数据库，查看有何影响；
l 还可以用来检验某个特定的页面是否是依赖数据库而存在。
5 更多提示
l 获取一份清晰详尽地标明了所有服务器和连接情况的拓扑结构图。
l 首先应当考虑改变最高层（即体系结构），找到那些可以省去的步骤和机器。最低层的优化应当留到以后再做，因为从低层的优化获得的收益较小，而且在低层优化时的任何变动都有可能造成体系结构的大幅度改变。
l 最有可能产生性能问题的是“自产”的应用程序、高级别的体系结构、数据库、网络和硬盘。
l 尽量在系统上没有其他用户或进程时运行负载测试，一般可能是在晚上，这样可以发现当前配置可能的最佳性能。这有助于清楚地了解差的应用程序和系统上的过渡负载之间的差别。如果在只存在一个没有网路负载的单独用户时性能很差，那么问题可能处在应用程序上。如果性能是间歇性地变差，则应当查找应用程序处理的低效率错误。
l 监控进程的大小，以查找内存泄露。
l 使用日志文件查找错误。
l 检查物理线缆的连接，查找是否因线路纠结或接口处的问题影响性能，比如过于接近荧光灯或无线发送装置。
记住，性能问题的产生即意味着引起某处的用户的不满，成功解决性能问题则意味着使这些用户满意，其满意程度甚至会超过替他们解决所有技术问题所带来的快乐。
6 惯性建议
l 去了解一下哪些工具可用于将活动映射为PID。
l 不要过分相信日志文件的正确性。
l 记住日志文件记录的是响应完成时的时间，而不是响应开始时的时间。