自己机器的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，还需要手工合并压测数据，真晕。

有这么一个关于跳蚤的故事：

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

曾经有人做过这样的一个实验：把几只跳蚤放在密封的玻璃瓶子里，在最初的时候，跳蚤试图逃出去，每次都跳的很高，但每次都要撞到瓶盖。
在几次失败碰壁之后，为了不至于撞疼脑袋，跳蚤开始调整策略，虽然它仍旧在跳，但是跳跃高度已经不足以触及瓶盖。
这个时候，即使你把瓶盖打开，他也不会跳出瓶外去，因为它已经把自己的跳跃范围限制在自己所设定的范围内。其实他只要稍微跳高一点，就可以自由，但是他没有。

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

第一次听到自我设限的这个名词，来源于DLHUNTER的说法。听说来源于另外一个人，具体就不再深究。今天打完了羽毛球，和同事走路回家，第一次见面的同事，虽然我们同在一个公司好几年。我和他不停的说话，分析公司，分析公司的部门，分析房价。我不喜欢冷场。呵呵，可能说的有点多，他和我说，他觉得我应该去做销售。我笑问，为什么？他说，直觉如此。我问，为什么你不能去做呢?他说，我偏内向，只能在公司研发部门呆着。我突然想到DLHUNTE给我提起的自我设限，是这样的么?

做销售，为什么你不能去做销售？是我自己自我设限，是搞技术的，不能去搞销售的事情，还是什么其他的呢？我一直在想为这个问题找到答案。特别是最近有空来想这些问题的时候。

为什么不能去做销售？难道头上顶着好几个透明的玻璃瓶盖么？

我从ps，换部门到rd性能组。我相信这就是我的一次对自我设限的挑战。在做项目最迷茫的时候，我一直不停的在问自己一个问题。除了做项目，开发，管理项目，你还能做什么？是不是一辈子就是做项目的命？

如果有一天，ps没有项目可做了，你去做什么？还是会失业么？做项目总是个很失落的过程。比如，在上一个项目的过程中，需求变更的问题，到了下一个项目，这些问题依然出现？难道我就不能去解决这些问题？我也尝试着去解决，去沟通这些问题，想彻底根除这些问题，在保证客户满意度的前提下，去除这些问题，很难，或者说，不可能。

我对这次部门的转换叫做华丽的转身。开发了一年的项目，带了一年的项目，我相信，就做项目方面，我还是能做一些事情出来的。那么，难道我的命运就是如此？一辈子的和人扯皮？肯定不能这样。那么我就去做些有积累的事情。

于是我就转换到了性能组，就这么简单。如果这次华丽的能转身成功，我相信，总有一天，我会变成一个商人的，不管是不是软件行业的销售，我有足够的冲劲和能力来做这个事情。

分析上面的一段话，有三个玻璃盖：

1. 在ps一定要做项目么？
2. 在保证客户满意度的前提下，真不能解决需求变更的问题么？
3. 这次的华丽转身关后面的计划什么事情呢?

对应的问题：

难道呆在ps一定要做项目?还有咨询啊，售前啊，架构啊，能做的事情多呢。是自己能力不够或者经验不够才做这些事情做的少。努力的蹦跶一下，落在瓶外了，你就能去做其他的事情，就是如此简单。

当自己觉得沟通的够了，应该离真正的沟通够了差很多，不可辩驳的是，ps所参与的绝大多数项目都是有特殊性的，比如一般是销售由于工期的原因才送你们到一线。销售希望你拼命干活，给他多创造利润，这是作为剥削阶层的最终目的，既然他要利用我挣钱，我为什么不能把这个关于需求变更的问题抛给他去处理?

其实不管此次转身能不能成功，后面的计划还是要执行，走一步看一步是正常的做法，但是最主要的是，大的计划不能改变，如此。

其实跳蚤不可悲，因为他已经尝试过很多次。

如果不去尝试，就算一直在瓶子里面蹦咋，也不会很开心。

我想说的是，合适和不合适是一个方面，为什么不尝试呢？折腾有理，折腾无罪，折腾万岁。

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

写的有点乱七八糟，自我设限真的是很恐怖的东西，等偶战胜他了，再来写清楚点的文字。

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

惦记了一个多星期的为期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在本地跑着，记录了他的工作过程，也方便查找，我决定学习了。

-----------------思想转变-----------------

事情只是自己的，一定要去自己去推动。并且邮件是推不动的，最好是当面1对1把话扯清楚。遇到任何问题，你可以组一个team，也就是说把他人involve进来。团队的力量是巨大的。

刚来着实蒙了好几天。老大不在，一个组的哥们一个劲的编码，其实就算不编码，也只能陪我扯淡，完全是新的区块。于是我一边看着wiki，一边想着将来要做的事情。日子倒是逍遥自在了几天。

后来KQ就布置任务了。我想的是，以这个任务来试着走下来这个流程，熟悉人头，熟悉工具。后来就发现了，前前后后都需要找人扯皮。

以后系统组的String就回来管硬件了，谁要用写书面申请。

PS的过程积累模式我要带到研发部门来，我知道，基本上程序员都是属于闷骚型的，缺的就是那个火星。

-----------------工作方式------------------

早上9点15之前必须到，打卡上班。中午吃饭休息一个小时，晚上6点半左右下班。我一般会右一点，因为我实在是很不习惯这么早下班。

有点不太习惯，不过到今天基本上就习惯了。

我整理了好几天的书，信件，衣服，还有我的电影，音乐。

翻起来那些姐姐写过来的信件，手指头和信纸接触，那种感觉很好。

我租了新的住处，一个人住，我换了工作岗位，换了作息时间。换了常驻称城市，换了平常工作的同事。

其实变动也挺大的，不是么？

----------------加油加油--------------------

对我来说应该算是全新的区域，本周末，也就是明天，有一个收费5K8的培训，可能一张白纸的培训会更有意思一点。好期待。

运气也是实力的一种，而我更相信是贵人在主导。

我又回到了下班可以看技术的年代了。感觉真好。

同学们和我说话的时候，我自己都能感觉自己嫩的有点过分了。这7分熟的牛排装熟都装不像啊。

不过呢，我很放心我自己能在一段时间内赶上来。

哼哼，全速跑，追上那群丫的。

面对我前面的人啊，我得穿过且得潇洒。

看到华南的数据统计，汗流浃背。

再一次的表示不爽，十分不爽，超级不爽。

还好，我已经自己开掉了我自己。

不然，我真不知道该怎么面对这丑陋的数据，呃，和人心。

历史总是惊人的相似，但却不尽相同。

过去没有什么好遗忘的，只有不断的翻起，才能不断的进步。

欠的，我总会还上，该收回的，我一定会要回来。

为什么客户满意了，而领导不满意？

这个问题值得思考。

其实我一直不想在数据后面加上人心的，因为这样总是在打击一个面，虽然我想表达的只是一个点。

肆意的漫骂和牢骚满腹一样，不能解决任何问题。

但是我爽了，就是这么回事。

其实我也不想再写关于华南PS这个团队的任何事情，以此为界。

过去的，就让他过去。