上午10点接到电话，回家收拾了2件衣服地铁去火车站。火车晚上6点才发车，无奈汽车过往。出租车不认路，东北小伙很能想办法，在每个红绿灯都摇下车窗问路，感觉很不错。为解决问题使用上所能想到的每一个办法才是王道。

下午4点10分到达工厂门口，然后开始拨电话，无人接听。很纳闷。然后打电话给D，问同行工程师电话，D不知，电话助理，助理不知，电话原来呆过的ps，总算接通，才算是正式入场。

入场歇了会，然后组织人员开会，了解最原始的需求，硬件环境，软件环境，目前性能情况，项目架构。

会后开始干活。

第一天，把周边的邮件系统搞死了。

和在场工程师加床拼个房间。

小插曲：P同学订房没订上，前台大发脾气。我在想，要是能讹几份免费早餐会更好。

第二天，firewall +dns 死了。

小插曲：和客户人员聚餐，技术化的人沟通比较有意思。：）

第三天，数据量不大的情况下数据库deadlock。

小插曲，客户IT部头请吃饭，白话了技术的，管理的，经文很多玩意，不管是不是酒话，算是对客户的帮助吧。

第四天，定位死锁问题，

小插曲，IT部的头早上开车来接，晚上P同学请吃饭。发现最近自己的话忒多了点。

第五天，搞定死锁问题，召集性能结束会议。

eos+bps的性能还是不错的，如果有大的性能问题，一定是使用和架构的问题。：），说这句话，我很有底气。

下午，拎着客户送的礼品踏上回家的路。

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

1）就算是业务，客户不一定比自己更精通。

2）搞定问题的方式有很多，要学着全面看问题。

3）不迷信任何牛人，所谓愚者千虑亦有一得，多想想，那一得才是必须的。

如何把perfmon的性能数据导出到excel中？

在性能测试的过程中，由于客户的要求不能开放对应的服务。Remote Procedure Call(RPC)和Remote Registry Service。loadrunner连接不上windows资源进行监控。

那我们只能将性能数据导出到excel中，用excel强大的图表进行分析。

废话不多说，开始吧。

开始，运行，perfmon，打开性能监控工具。

点击计数器日志，右边一般会出现一个文件 system overview 的日志文件。

在右边空白处，点击右键，新建日志设置。

输入该设置名称。然后添加计数器。

主要监控processor，disk和memorry的状况，那就添加对应的计数器即可。

调整数据采样间隔，和loadrunner的数据采样间隔保持一致。

窗口头上，tab切换到日志文件。

选择文件类型，选择文本文件。

例如中就会出现C:\PerfLogs\PTest_000002.csv 类似这种值。

然后启动该日志配置。在工具栏中。

压力测试之后，用excel打开对应的csv文件。

查看对应的列，使用excel图标对应该列生成折线图即可。

bes是borland公司的应用服务器，此次测试基于aix 5.3 + bes6.7 + eos6.0测试。

本文档记录在测试中发现的问题和结果的过程。积累思路。

--------------------bes 安装------------------

borland的哥们给的安装包很智能，一个sh文件即可。通过host模块方式部署文档，war包无法加载。

打印出classloader，war包中的lib无法加载，

$jar -xvf  ***.jar  解开报错。

问题所在，ftp 上传，没有设置bin模式。

ftp>bin

设置bin模式，再次上传，用jar能解开，即可不是war包。

---------------------数据库----------------------

1）快照描述，大量性能损耗在日志轮换。

oracle的日志，redo.log，需要放在IO最好的磁盘中。

通过em或者命令行，添加redo.log文件，切换，删掉原有redo.log即可。

2）命令行模式安装快照。

sql>@C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\spcreate.sql

安装如出现not connecting

需在spcreate.sql 中加入连接字符串。

connect perfstat/&&perfstat_password@eos  即可。

-------------------服务器调优----------------

bes的服务器，接入端包装的为tomcat。

可以通过修改 /bes/BES6.7/var/domains/base/configurations/BPS6.0/mos/standard/adm/tomcat/conf

目录下的server.xml来做调整。

比如连接池，超时时间，更改此文件，可以参考tomcat的更改方式。

压力测试需要调整log的级别。

/home/bes/BES6.7/var/domains/base/configurations/EOS6.1/mos/standard/adm/logs，日志相关配置可以通过修改/home/bes/BES6.6/var/domains/base/configurations/EOS6.1/mos/standard/adm/properties/

logConfiguration.xml来完成。

如果日志量很大，可以考虑调低日志级别

--------------------应用调优------------------

通过调整应用中的业务逻辑，省掉数据库操作，来调整。

-------------------loadrunner脚本验证-------------

在压力测试中，loadrunner脚本变量设置，可能会出现变量越界的情况。

和数据库配合统计，来保证测试结果的正确。

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

一次性能测试，涉及的因素可能有以下几个方面：

1）硬件，包括app服务器，database 服务器，loadrunner client，网络等。

2）软件，包括app 应用服务器，database应用服务器，loadrunner 设置等。

3）测试案例。

4）测试脚本。

隔离问题，才能解决问题。

3月3号下午3点到。在那里工作了20个小时，具体工作如下：

   3月3号，工作时间，3小时。

1.       了解需求，客户提出按照他们的开发场景，按照通用测试方式测试，根据word版本的要求，开发测试用例。

   3月4号，工作时间，9小时。

1.       更改用例，录制脚本；

2.       windows2003 应用服务器宕机，查明原因是因为没有补丁，打补丁。

3.       本地压力试跑，压力100，本地网络使用99%，重新创建windows2003 虚拟机，在千兆网段。

4.       表空间不够，新建100G的表空间。

5.       容量测试完成，并发压力测试，windows2003的操作系统内核参数调整失败，无法接受到大于1600的集合点并发请求。

3月5号，工作时间，8小时。

1.       由于app server操作系统的问题，在aix上重新安装weblogic10.3，eos 6.1。

2.       并发压力测试压力机不够，联系系统部门安装分配新的虚拟机3台。

3.       完成最大并发测试。由于网络流量和loadrunner 虚拟机数量的限制，并发用户到了5000，没有错误。

4.       基于windows2003的应用服务器完成容量测试。

5.       和多方沟通关于版本测试的问题。下载不到weblogic923for aix的版本，没有做关于1.5JDK的测试。

6.       和对方沟通关于EJB远程部署，交接测试的环境。

定的3月5号晚上11点半回到上海。

这次住的地方貌似还不错，是原来的驻马店酒店。

一起工作的小伙是85年的，年轻有为，也挺好。

虽然是私企，但给人感觉国企的氛围十分重。一些领导三句落不到关键点上，拿客户忽悠。不太靠谱。

当然，这些都不关我的事情。

-----------------TPC---------------

TPC为非赢利性国际组织，事物处理性能委员会（TPC，Transaction Processing Corp）。

-----------------TPC-C--------------

TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。

-----------------TPM-C--------------

TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。

-----------------TPC-C规范概要----------------

TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
该系统需要处理的交易为以下几种：
  New-Order：客户输入一笔新的订货交易；
  Payment:更新客户账户余额以反映其支付状况;
  Delivery:发货(模拟批处理交易);
  Order-Status:查询客户最近交易的状态；
  Stock-Level:查询仓库库存状况，以便能够及时补货。
对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。

-----------------之间的关系------------------

TPC-C使用三种性能 和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是transactions per minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是，在处理新订单的同时，系统还要按表1的要求处理其它4类事务 请求。从表1可以看出，新订单请求不可能超出全部事务请求的45％，因此，当一个 系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。价格是指系 统的总价格，单位是美元，而价格性能比则定义为总价格÷性能，单位是＄/tpmC。