background image

load

 

、网络流量、每类请求在总的请求中所占的百分比等)。

对于新系统而言,要评估出具体的性能相对来说稍微好做一点,因为此时系统通常较为
单纯,数据量的增长也不可能是一夜之间增长的,因此基本可以按照一种正常的方法在
测试环境评估出其正式运行的性能。

而对于已运行的系统而言,则较为麻烦,因为通常来讲要在测试环境中模拟正式运行环
境基本是不太可能的,因此这个时候通常要采取一些模拟的方法或更高压力的方法来尽
量更为准确的评估出系统的性能。

 

在测试系统性能时,通常可采用的方法有:
1

 

、单元测试;

可借助单元测试来测试某个请求的性能;

2

 

、压力测试;

压力测试无疑是测量系统性能中最常采用的方式,根据定义的性能目标对系统进行压力
测试,以确定系统是否满足性能要求,同时也可以根据压力测试的结果来分析系统的瓶
颈,进而进行对应的调优,可用于做压力测试的工具还是不少的,像 loadrunner、jmeter 等
等,不过压力测试这个话题实在太大了,不在这里展开去讲了,不过我也不怎么懂就是 ,

 

呵呵。
分析系统性能瓶颈

根据测量系统性能的结果,多数是可以分析出系统性能的瓶颈,同时还可以结合像 jvm
堆栈、jprofiler、系统日志等来进行进一步的确定,另外也可以根据性能调优人员的经验,

 

例如可以去了解开发人员是否采用了不适合的数据结构等。
简单说一个线程分析的例子:

借助 kill -3 pid 来获取到目前 jvm 的线程堆栈信息,特别需要关注的是里面 wait for 
monitor 这样的线程,这种线程是指在等待锁的线程,等待一两分钟后再次 kill -3 pid,看
看这些 wait for monitor 的线程的变化情况,这对于分析线程中是否存在不合理的竞争过
高的锁的分析是非常重要的。

这一步无疑也是性能调优过程中最难的一步了,分析系统性能瓶颈这种基本只能结合实
际例子来讲了,正确在后续抽取一两个例子来进行讲解。

性能调优

在分析出系统性能的瓶颈后,其实这一步相对来说还好做些,当然,需要建立在对软硬
件知识都有很好的深入了解的基础上,在这里列举一些比较常见的性能调优的手段,多
数是抄来或 google 来的,自己在这方面的经验还不多,希望大家多加指点,:)

Redhat Linux 内核