自己机器的wiki已经完成了架设的过程，并已经启用了，我会把自己的工作过程和遇到的问题作为tip记录下来，积累和提高。

---------------eos for weblogic的默认安装-----------------

访问console，默认的用户名/密码为  system/eosversion

--------------强制杀进程-------------

kill -9 pid

--------------too many open file 文件句柄超出-------------

在使用linux服务器做web应用服务器时，linux默认的对外file连接数量为1024. 也就是说，如果做压力测试的话（偶就是搞这个的），一定需要修改对外的tcp链接数量。

一般这种错误，对应的是日志中的too money open file.

在Linux下，我们使用ulimit -n 命令可以看到单个进程能够打开的最大文件句柄数量(socket连接也算在里面)。系统默认值1024。对于一般的应用来说(象Apache、系统进程)1024完全足够使用。但是如何象squid、mysql、java等单进程处理大量请求的应用来说就有点捉襟见肘了。如果单个进程打开的文件句柄数量超过了系统定义的值，就会提到“too many files open”的错误提示。如何知道当前进程打开了多少个文件句柄呢？下面一段小脚本可以帮你查看：

lsof -n |awk '{print $2}'|sort|uniq -c |sort -nr|more 在系统访问高峰时间以root用户执行上面的脚本，可能出现的结果如下：

# lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more

131 24204   
   57 24244   
   57 24231   
   56 24264

其中第一行是打开的文件句柄数量，第二行是进程号。得到进程号后，我们可以通过ps命令得到进程的详细内容。

ps -aef|grep 24204 即可查看对应的进程。

但是如果系统并发特别大，尤其是squid服务器，很有可能会超过1024。这时候就必须要调整系统参数，以适应应用变化。Linux有硬性限制和软性限制。可以通过ulimit来设定这两个参数。方法如下，以root用户运行以下命令：

ulimit -HSn 4096 以上命令中，H指定了硬性大小，S指定了软性大小，n表示设定单个进程最大的打开文件句柄数量。个人觉得最好不要超过4096，毕竟打开的文件句柄数越多响应时间肯定会越慢。设定句柄数量后，系统重启后，又会恢复默认值。如果想永久保存下来，可以修改 /etc/profile 把上面命令加到最后。

当然，也不建议过多，会对资源有所损耗。 由于我是上的300虚拟用户，我直接给当前连接窗口给开到了10240。

----------------------远程连接相关----------------

用 nohup ./startServer.sh启动服务，可以断掉链接，服务存在。

----------------load runner相关设置--------------

巧用参数生成123456000000到123456150000的编号。设定如下：

图中的100对应着我的100 vuser的并发。这样设置的意思，到最后就能100并发，生成123456000000到123456150000并且不重复。

-----------------web service压力测试注意------------------

听GZ说起，一个注意点。

获取连接的时候，应该把获取连接的方法提取到静态方法中，不能每次动态获取连接。

不然压力上去，性能就下来了，做个笔记。

---------------------------------------------------------

破解的8.1，100 vuser，一个controller能管理多个clinent，但是并发用户总数还是不能超过100，还需要手工合并压测数据，真晕。

---------------------性能测试培训--------------------

惦记了一个多星期的为期2天的培训结束。培训讲师是段念，一个工作11年的小伙。对于性能测试，写就一本《软件性能测试过程详解与案例剖析》，参与了Google API大全——编程·开发·实例》，对于此次培训，我倒还真是有了一些认识。工具这种东西，只要你去用，去摸索，怎么着都能学会。有一些思路，思想，还有一些经验的分享，也估计只能花钱去买咯。

做些笔记：

1）需求决定性能好坏。

举例说明：一个报税系统，需要填写2个多小时的数据，然后报送的时候需要12分钟，性能是好是坏？

客户反馈：性能不错，能接受。

思考：开始的时候忒不能理解，12分钟在等待计算机响应，是不是太恐怖了点。后来发现，有个前提，需要填写2个多小时的数据。报送12分钟。来平均一下我们的数据，2个多小时，算2个小时。也就是1个小时要对应6分钟提报时间。再次拆分，10分钟对应的是1分钟报送时间。再次拆分也就是10秒的填写，对应1秒的报送时间。那我们在模拟一下系统的用户，填写30秒，等待3秒。嘿，按照258理论。这个完全还是可以接受的。所以结论是性能还不错。

换句话来说，做性能也是为了客户而做，客户都满意了，自己何必再吹毛求疵？

2）响应时间

响应时间分为两段：a）服务器响应时间    b）客户端响应时间

在目前我们所面对的大部分的应用中，以web应用为主。客户所感觉到的时间为：网络传输时间+服务器响应时间+客户端响应时间。目前的多ajax应用中，客户端响应时间反而成为了一个不确定的因素。

3）虚拟并发的估算

一般系统为同时在线的10-20%之间。

在选定的时间段，用户行为基本稳定，有相对固定的行为模型。业务并发数用于模拟用户的真实负载情况。这是一个时间段的概念，具有业务意义，体现的是用户的视角；而服务端的并发数表明软件在同一时刻受到的用户请求，这是一个时间切片的概念，体现的是应用本身的压力，一般用于查找并发引起的问题，比如死锁，内存溢出等所用的概念。利用正态分布来计算并发峰值。

4）性能诊断过程

大胆设想，小心求证。

举例：医生看病，比如一个人发烧来到医院，说自己发烧，让医生给诊断，医生也不知道是怎么回事啊，就把常见的发烧病因列举一下，然后在一一检查，最后定位出来。

同样，做性能测试和分析也是如此，要能知道大概是怎么回事，才能定位出来问题。

用福尔摩斯话结尾：One should always look for a possible alternative and provide against it. It is the first rule of criminal investigation。

你必须寻找各种可能解释事情的方法,然后想办法看看能否试图推翻它。 其实就算是让你看到内存分布有能如何呢？

性能测试和调优也莫过如此。

5）短板效应

一个系统能承受多少压力，不是取决于服务器的配置什么性能最优，而是服务器的最弱的那块硬件性能。

举例：人大学生选课系统，2台数据库服务器，负载均衡。由于2台服务器的硬件配置不一致，一台CPU一直保持在100%，而一台CPU一直就没上过50%。这时候，那台一直100%的就会导致压力脚本运行失败。变成了整个系统的短板。

6）测试分类

1. 性能测试。（performance testing）
2. 负载测试。（load testing）
3. 压力测试。（stress testing）
4. 配置测试。（configuration testing）
5. 并发测试。（concurrence testing）
6. 容量测试。（volume testing）
7. 可靠性测试。（reliability testing）
8. 失败测试。（failure testing）

明确目的，才能做好测试。

7）响应时间和并发数的关系

由线性转为非线性。

举例：理发店举例。

一个理发店4个理发师，理发一次需要30分钟，来小于等于5个人的响应时间都为30分钟。等来了8个人，平均响应时间就是一个小时。如果来的人越来越多，时间的变化曲线应为抛物线型。

8）从需求中获取和性能相关的指标

1. 在约定的时间内完成的业务数量。
2. 和时间相关描述
3. 和速度相关描述

关于性能的需求，2个盲点：a）二义性。b）不可测试性。碰到这种问题，需迭代回需求状态，确认需求。

9）确定目标确定的风险考虑

似乎所有的和风险相关的事情，都会有以下2种。

1. 严重性。
2. 可能性。

举例：车祸，不做赘述。

--------------------------------TIPS---------------------------

1）测试数据分为负载数据，探测数据。

2）时间戳的使用需配合ntp协议做测试服务器和客户端的时间同步

3）开源用的最多的测试工具 jmeter。

4）http1.1协议规定不能同时发起超过2个的请求。js需单独占用线程下载。

5）loadrunner的使用中，如果是web页面ajax的应用较多，录制脚本请选用url的选项进行录制。

6）在脚本中，如果值能确定，请用参数。如果值不能确定，需从服务器上获取，用关联。

9）fiddler，调试工具，可模拟http请求。

10）用loadrunner监视器他的机器，如果是*nix系列的机器，必须要保证rstatd的进程在运行才能进行监视。

11）页面缓存，用版本来指定文件夹存放静态需缓存数据，可以把静态时间设置比较长。来源于http头的 expired来设置。

12）firefox的插件yslow，firebug的使用。

13）推荐网站：www.testingreflections.com

课后扯淡：最怕领导说要加入项目组了，加入一个（人）死一个（项目），深以为然。比如第一个报税的举例，自己人能把自己人掐死。

----------------------dokuwiki-----------------------

见到了上次性能测试这一块的一哥们，用dokuwiki在本地跑着，记录了他的工作过程，也方便查找，我决定学习了。

loadrunner7.51 license AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB

问题：同一个页面，不加入图片，载入时间比加入图片时间慢一个数量级。原因如何？

分析该页面，其中共有六处应用了自定义标签的include，在cms的应用中，需要app先到标签库查找标签，然后根据调用的页面到一个页面配置文件中寻找相应的jsp文件名。跟踪页面进去，发现其中有2个页面需要权限验证，通过session操作。还有4处，一处为左边连接页面，一处为右边查询页面，一处为一个内容列表页面，还有一处也就是bottom页面。先用loadrunner压力测试。10并发。（先给测试机器把图片全部加上！）

loadrunner测试过程如下：

在Virtual User Generator中选择创建一个新脚本，选择Single Protocol Script，选择Web(HTTP/HTML)，点击OK。点击" "开始录脚本，在URL中输入http://192.168.1.22/*****/index.html，点击OK。（不带端口的原因是因为俺用apache＋weblogic做了一次小的负载均衡，所有的serlet的请求由apache转发到weblogic，原文见手把手教你集成Apache+weblogic）因为仅仅对首页做一次压力测试，那么不用打开其他的页面，也就是只有2次event，一次打开index.html，一次是自动提交到servlet的转发。

执行一次TOUPPER操作，停止录制。在此处需要点击保存，就是那个软盘一样的按钮，保存到scripts的目录下面。（可以打开安装目录，在scripts目录下寻找你命名的文件夹，action.c就是该测试用脚本。）
打开控制器（Controller），创建一个新的Scenario，选择刚才录制的脚本，点击"OK"，弹出Scenario调度界面，如下图所示。在"Quantity"中输入10，表示使用10个虚拟用户，点击"Edit Schedule"来编辑压力调度。选择"Runtime settings"来作运行时设置，在Pacing的设置中，"Number of Iterations"用于设置Vusers的Actions被执行的次数；"Start new iteration"用于设置调度器在什么时机迭代执行Vusers的Actions。"Think Time"用于设置Vusers的反应和思考时间，以尽量做到和正常人一样来施压。"Ignore think time"表示忽略思考时间，这是理想状态，一般不使用。"As recorded"表示按照录制时的实际操作时间。"Multiply recorded think time by"表示Vusers的思考时间是实际录制时间的若干倍。使用进程模式进行压力测试。ok，设置完毕，开始测试。

返回avg时间：9.564s。（好像是不是太大了一点，貌似偶也不大清楚这个avg的单位是啥，但是一个页面的10用户并发，就达到了9.564秒，是不是太夸张了点？）

第一次分析的结果是标签引入的原因，ok，我全部用jsp的include来试试。

返回avg时间：7.634s。提高了20％多。

得出一个结论：

页面的载入，如果过多的试用标签include，就不如使用jsp自带的include，让速度快一些。不推荐使用iframe。最好的结果是把所有的内容写入一个页面，虽然会让源文件有些大，但是载入的速度一定比多个页面的include要快很多。