class cmsApi {

//初始化url参数
 function  urlinit($app_url,$url){
  $ch = curl_init();
  curl_setopt ($ch, CURLOPT_URL, $app_url.$url); //REST地址 GET  
  curl_setopt ($ch, CURLOPT_RETURNTRANSFER, TRUE);
  curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, 15); 
  return $ch ;
 }
 
//JSON 数据格式 
 function xml_to_json($source) { 
 if(is_file($source)){             //传的是文件，还是xml的string的判断 
  $xml_array=simplexml_load_file($source); 
 }else{ 
  $xml_array=simplexml_load_string($source); 
 } 
 $json = json_encode($xml_array);  //php5，以及以上，如果是更早版本，请下载JSON.php 
 return $json; 
   }
 
//【CMS-HLD_0.011】获取billingcode
 function getBillingcode_011(){
     // Get method
    //$app_url = "http://IP:8081/";
    $app_url = "http://IP:9081/";
    $url ='conferenceReservManager/getBillingcode/' ;
  //print_r($post_data);
     $ch = $this->urlinit($app_url,$url);
  curl_setopt($ch, CURLOPT_GET, 1);   
  $file_contents = curl_exec($ch);//获得返回值
  curl_close($ch);  
  return $file_contents; 
 }
 

// getPasscode_012
 function  getPasscode_012($num){
  // Get method
    $app_url = "http://ip:9081/";
    $url = 'conferenceReservManager/getPasscode/'.$num;
    //echo $url ;   
  //初始化URL
     $ch = $this->urlinit($app_url,$url);
    
  curl_setopt($ch, CURLOPT_GET, 1);    
  $file_contents = curl_exec($ch);//获得返回值
  curl_close($ch);  
  return $file_contents; 
 }
//获取acquirePin
 function  acquirePin_014($billingcode){
       // Get method
    $app_url = "http://ip:9081/";
    $url = 'conferenceReservManager/acquirePin/'.$billingcode;  

  //初始化URL
     $ch = $this->urlinit($app_url,$url);  
  curl_setopt($ch, CURLOPT_GET, 1);   
  $file_contents = curl_exec($ch);//获得返回值
  curl_close($ch);  
  return $file_contents; 
 }
 
//reservConference
 function reservConference_007($billingcode,$pcode1,$pcode2){
  
   // Get method
    $app_url = 'http://ip:9081/cmsrest/rs/';
    $url = 'conferenceReservManager/reservConference/'; 
    
    $post_data ='{"xmlTemplateName":"/root/sme.xml","userId":"","applicationId":"SME-MEETING","value":{"2":"3,4","7":"23"},
    "conference":{"valid":0,"noticetime":0,"conferenceuservalues":{},"callout":false,
    "starttime":"2011-07-29T18:57:22Z","reservtime":"2011-07-26T18:57:22Z","conferencedesc":"","confscale":4,
    "billingcode":"'.$billingcode.'","password":"","product":{"productroles":{},"productid":3,"conferences":{},
    "conferenceservices":{}},"conferenceminutes":120,"pin":false,"roles":"4,5","conferencename":" tester 2011/7/30 01",
    "language":2,"realreserve":true},"pcode1":"'.$pcode1.'","pcode2":"'.$pcode2.'"}';
    
  //初始化URL
     $ch = $this->urlinit($app_url,$url);      
     $datatype ='application/json';
    $accepttype='text/plain';
     curl_setopt($ch, CURLOPT_POST,1); //设置POST方式
     curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); //发送的post值，目前已经放入url
     curl_setopt($ch, CURLOPT_HTTPHEADER, array (
          "Content-Type: ".$datatype."; charset=utf-8",
          "accept: ".$accepttype."; charset=utf-8"));  
  $file_contents = curl_exec($ch);//获得返回值
  curl_close($ch);  
  return $file_contents; 
 }
 
 
//【CMS-HLD_0.001】userJoin
 function userJoin_001($LshyID,$pinCode){
       // Get method
     $app_url = "http://IP:9081/";
    $url = 'conferenceBusiness/userJoin/SME-MEETING/'.$LshyID;
    
     $post_data=$this->xml_to_json('<userDTO><clientType>2</clientType><domain>1</domain><ipaddr>192.168.12.155</ipaddr>
    <isowner>true</isowner><pinCode>'.$pinCode.'</pinCode><rolemap><entry><key>4</key><value/></entry><entry><key>7</key><value/>
    </entry><entry><key>8</key><value/></entry><entry><key>9</key><value/></entry><entry><key>10</key><value/></entry><entry>
    <key>11</key><value/></entry><entry><key>12</key><value/></entry><entry><key>13</key><value/></entry><entry><key>14</key><value/>
    </entry></rolemap><tempuserid>4</tempuserid><userName>liming</userName><userStatus>0</userStatus></userDTO>');
      
     //初始化URL
     $ch = $this->urlinit($app_url,$url);
  $datatype='application/json';
  $accepttype='application/json';
  //设置POST方式
   curl_setopt($ch, CURLOPT_POST, true);
   curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); //发送的post值，目前已经放入url
   curl_setopt($ch, CURLOPT_HTTPHEADER, array (
          "Content-Type: ".$datatype."; charset=utf-8",
          "accept: ".$accepttype."; charset=utf-8"));
       
  $file_contents = curl_exec($ch);//获得返回值
  curl_close($ch);  
  return $file_contents; 
 }
 }

 备注几点:

1. GET 和 POST 提交是有区别的:

   其中get 请求的数据一般比较小的.POST提交的方法,可以提交比较大的数据量

2. POST 方法提交

   注意数据格式和接受数据格式:如果错了,提交也会失败的.

 

1.set error:320/55160=0.58%
2.get error:640/55160=1.16%      已测试过程中一次set对应两次get,因此get的错误率会比其他两个高一倍。
3.update error:320/55160=0.58%    更新前后比较不同

 

 

测试内容400个并发，执行10分钟。(单线程)

测试结果：

1.set error:40/29240=0.14% 
2.get error:120/29240=0.41%       已测试过程中一次set对应两次get,因此get的错误率会比其他两个高一倍。
3.update error:40/29240=0.14%     更新前后比较不同

总结：
1.memcache set ,get 在高并发情况下存在失败的情况
2.memcache 在多线程情况下，硬件资源都合理情况下，比单线程性能好，同时错误率也有相应的提升。

<?php
include 'SphinxClient.class.php';
header('Content-Type: text/html;charset="UTF-8"');
if ($_GET) {
    // 关键词
   
    $keyword = urldecode(trim(strip_tags($_GET['keyword'])));
    $keyword = "二手房" ;
    if ($keyword) {
        // 包含Sphinx的api文件
      //  require_once 'sphinxapi.php';
        // sphinx服务器地址
        $server = '10.115.12.78';

       // 端口
        $port   = 9312;
        // 索引名 为*时表示搜索所有索引
        $indexName = 'idx_sale_beijing';
        // 分页页码
        $page = intval($_GET['page']) > 1 ? intval($_GET['page']) : 1;
        // 每页显示的数量
        $pageSize = 30;
        $sphinx = new SphinxClient();
        // 建立连接
        $sphinx->SetServer($server, $port);
        // 连接超时时间(非常必要,比如sphinx服务器挂了等异常情况) 单位为s,秒
        $sphinx->SetConnectTimeout(3);
        // 最大查询时间 单位为ms,毫秒
        $sphinx->SetMaxQueryTime(2000);
        // 按分页取结果
        $sphinx->SetLimits(($page-1)*$pageSize, $pageSize); //第一个参数为offset,第二个参数为limit
        // 模式
        // $sphinx->SetMatchMode(SPH_MATCH_EXTENDED);
        // 取到的原始数据
        $orgDatas = $sphinx->Query($keyword, $indexName);
        // 调试用,如果有错误的话,可以打印$errors的值
        $errors = $sphinx->GetLastError();
        var_dump($errors);

       // echo '<pre>';
       // var_dump($orgDatas);
       
        $sp_error= $sphinx->Status() ;
        $sp_client= $sphinx->GetLastWarning();
        print_r($sp_client);
        /* // 下面是对结果的处理
        $datas = array('goods'=>array(),'total'=>0);
        if ($orgDatas['total'] > 0) {
            $datas['total'] = $orgDatas['total'];
            foreach ($orgDatas['matches'] AS $val) {
                $val['attrs']['goods_id'] = $val['attrs']['goods_id_new'];
                unset($val['attrs']['goods_id_new']);
                $datas['goods'][] = $val['attrs'];
            }
        }
        var_dump($datas);
        */
    }
} else {
    echo '<form. method="get"><input type="type" name="keyword"><input type="submit" value="商品搜索"></form>';
}
?>

 

 　 是日本人 平林幹雄 开拓的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。

　　 是由同一作者开拓的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议 ，也可以通过HTTP协议 举办数据交换。

　　Tokyo Tyrant 加上 Tokyo Cabinet，构成 了一款支持 高并发的散播式恒久存储体系 ，对任何原有Memcached客户妒攀? 唇玻?可以将Tokyo Tyrant当作 是一个Memcached，但是，它的数据是可以恒久存储的。这一点，跟新浪的性子 一样。

　　相比Memcachedb而言，Tokyo Tyrant具有以下上风 ：

　　1、妨碍 转移：Tokyo Tyrant支持 双机互为主辅模式，主辅库均可读写，而Memcachedb如今支持 类似MySQL主辅库同步的行动 实现读写星散，支持 “主理 事 器可读写、赞助 做事器只读”模式。

这里应用 $memcache->addServer 而不是 $memcache->connect 去毗连 Tokyo Tyrant 做事器，是由于 当 Memcache 客户端应用 addServer 做事器池时，是按照 “crc32(key) % current_server_num”哈希算法将 key 哈希到差别 的做事器的，PHP、C 和 python 的客户端都是云云 的算法。Memcache 客户端的 addserver 具有妨碍 转移机制，当 addserver 了2台 Memcached 做事器，而此中 1台宕机了，那么 current_server_num 会由原来 的2变成 1。

　　引用 memcached 官方网站和 PHP 手册中的两段话：

引用 http://www.danga.com/memcached/
If a host goes down, the API re-maps that dead host's requests onto the servers that are available.


Failover may occur at any stage in any of the methods, as long as other servers are available the request the user won't notice. Any kind of socket or Memcached server level errors (except out-of-memory) may trigger the failover. Normal client errors such as adding an existing key will not trigger a failover.

---

　　2、日记 文件体积小：Tokyo Tyrant用于主辅同步的日记 文件比拟 小，约莫 是数据库文件的1.3倍，而Memcachedb的同步日记 文件非常大，假如 不定期清理，很轻易 将磁盘写满。
3、超大数据量下示意杰出 ：

但是，Tokyo Tyrant 也有错误：在32位操纵 体系 下，作为 Tokyo Tyrant 后端存储的 Tokyo Cabinet 数据库单个文件不能高出 2G，而64位操纵 体系 则不受这一限定 。以是 ，假如 应用 Tokyo Tyrant，推举在64位CPU、操纵 体系 上安装运行。
　一、安装
　　1、起首 编译安装tokyocabinet数据库

wget
tar zxvf tokyocabinet-1.3.1.tar.gz
cd tokyocabinet-1.3.1/
./configure
make
make install
cd ../

　　2、然后编译安装tokyotyrant

wget
tar zxvf tokyotyrant-1.0.0.tar.gz
cd tokyotyrant-1.0.0/
./configure
make
make install
cd ../

---

　　二、设置
　　1、创建 tokyotyrant数据文件寄放 目次

mkdir -p /ttserver/

　　2、启动tokyotyrant的主进程 （ttserver）
　　(1)、单机模式

ulimit -SHn 51200
ttserver -host 127.0.0.1 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 1 -rts /ttserver/ttserver.rts /ttserver/database.tch

　　(2)、双机互为主辅模式
　　做事器192.168.1.91：

ulimit -SHn 51200
ttserver -host 192.168.1.91 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 91 -mhost 192.168.1.92 -mport 11211 -rts /ttserver/ttserver.rts /ttserver/database.tch

　　做事器192.168.1.92：

ulimit -SHn 51200
ttserver -host 192.168.1.92 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 92 -mhost 192.168.1.91 -mport 11211 -rts /ttserver/ttserver.rts /ttserver/database.tch

　　(3)、参数阐发
　　ttserver [-host name] [-port num] [-thnum num] [-tout num] [-dmn] [-pid path] [-log path] [-ld|-le] [-ulog path] [-ulim num] [-uas] [-sid num] [-mhost name] [-mport num] [-rts path] [dbname]

　　-host name : 指定必要 绑定的做事器域名或IP所在。默认绑定这台做事器上的全部 IP所在。
　　-port num : 指定必要 绑定的端标语 。默认端标语 为1978
　　-thnum num : 指定线程数。默认为 8个线程。
　　-tout num : 指定每个会话的超时工夫（单位 为秒）。默认永不超时。
　　-dmn : 以守卫进程 行动 运行。
　　-pid path : 输出进程 ID到指定文件（这里指定文件名）。
　　-log path : 输出日记 信息到指定文件（这里指定文件名）。
　　-ld : 在日记 文件中还记实 DEBUG调试信息。
　　-le : 在日记 文件中仅记实 过错 信息。
　　-ulog path : 指定同步日记 文件寄放 路径（这里指定目次 名）。
　　-ulim num : 指定每个同步日记 文件的巨细 （譬喻128m）。
　　-uas : 应用 异步IO记实 更新日记 （应用 此项会镌汰 磁盘IO损耗，但是数据会先放在内存中，不会立即 写入磁盘，假如 重启做事器或ttserver进程 被kill掉，将导致部分 数据损失。一样平常 情况下不提议应用 ）。
　　-sid num : 指定做事器ID号（当应用 主辅模式时，每台ttserver必要 差别 的ID号）
　　-mhost name : 指定主辅同步模式下，主理 事 器的域名或IP所在。
　　-mport num : 指定主辅同步模式下，主理 事 器的端标语 。
　　-rts path : 指定用来寄放 同步工夫戳的文件名。

　　假如 应用 的是哈希数据库，可以指定参数“#bnum=xxx”来前进性能。它可以指定bucket存储桶的数量 。譬喻指定“#bnum=1000000”，就可以将最新最热的100万条记实 缓存在内存中：

ttserver -host 127.0.0.1 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 1 -rts /ttserver/ttserver.rts /ttserver/database.tch#bnum=1000000

　　假如 大宗的客户端拜访ttserver，请确保文件刻画 符够用。很多 做事器的默认文件刻画 符为1024，可以在启动ttserver前应用 ulimit下令 前进这项值。譬喻：

ulimit -SHn 51200

　　3、收场tokyotyrant（ttserver）

ps -ef | grep ttserver

　　找到ttserver的进程 号并kill，譬喻：

kill -TERM 2159

---

　　三、调用
　　1、任何Memcached客户端均可直接调用tokyotyrant。

　　2、还可以通过HTTP行动 调用，下面以Linux的curl下令 为例，先容 怎样 操纵 tokyotyrant：
　　(1)、写数据，将数据“value”写入到“key”中：

curl -X PUT -d "value"

　　(2)、读数据，读取“key”中数据：

curl

　　(3)、删数据，删除“key”：

curl -X DELETE

　参数很多，一般我们用 -c 和 -n 参数就可以了。例如：

　　./ab -c 1000 -n 1000 http://127.0.0.1/index.php

　　这个表示同时处理1000个请求并运行1000次index.php文件。

　　#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312

　　This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0

　　Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

　　Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

　　Benchmarking 127.0.0.1 (be patient)

　　Completed 100 requests

　　Completed 200 requests

　　Completed 300 requests

　　Completed 400 requests

　　Completed 500 requests

　　Completed 600 requests

　　Completed 700 requests

　　Completed 800 requests

　　Completed 900 requests

　　Finished 1000 requests

　　Server Software: Apache/2.0.54

　　//平台apache 版本2.0.54

　　Server Hostname: 127.0.0.1

　　//服务器主机名

　　Server Port: 80

　　//服务器端口

　　Document Path: /index.html.zh-cn.gb2312

　　//测试的页面文档

　　Document Length: 1018 bytes

　　//文档大小

　　Concurrency Level: 1000

　　//并发数

　　Time taken for tests: 8.188731 seconds

　　//整个测试持续的时间

　　Complete requests: 1000

　　//完成的请求数量

　　Failed requests: 0

　　//失败的请求数量

　　Write errors: 0

　　Total transferred: 1361581 bytes

　　//整个场景中的网络传输量

　　HTML transferred: 1055666 bytes

　　//整个场景中的HTML内容传输量

　　Requests per second: 122.12 [#/sec] (mean)

　　//大家最关心的指标之一，相当于 LR 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值

　　Time per request: 8188.731 [ms] (mean)

　　//大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值

　　Time per request: 8.189 [ms] (mean, across all concurrent requests)

　　//每个请求实际运行时间的平均值

　　Transfer rate: 162.30 [Kbytes/sec] received

　　//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

　　Connection Times (ms)

　　min mean[+/-sd] median max

　　Connect: 4 646 1078.7 89 3291

　　Processing: 165 992 493.1 938 4712

　　Waiting: 118 934 480.6 882 4554

　　Total: 813 1638 1338.9 1093 7785

　　//网络上消耗的时间的分解，各项数据的具体算法还不是很清楚

　　Percentage of the requests served within a certain time (ms)

　　50% 1093

　　66% 1247

　　75% 1373

　　80% 1493

　　90% 4061

　　95% 4398

　　98% 5608

　　99% 7368

　　100% 7785 (longest request)

　　//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093毫秒，60％的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒。

　　由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数。

测试时间	发现问题	解决办法	效果
2011-04-26-优化-apache	web cpu资源不足	1cpu->4cpu	解决问题
2011-05-10-性能优化	性能优化
2011-05-12-性能优化	sphinx 压力过大	1.调整后端数据流向 2.走memcache缓存	良好
2011-05-24-memcache长链接不释放	php.ini 参数做如下调整            session.save_path = "tcp://10.1.71.29:11211?persistent=0&weight=2&timeout=1&retry_interval=15"   以前是=1 现在调整成 = 0 ,         现在线上链接数量在10个左右,基本上解决持久链接不释放的问题. 0 代表不持久链接 ; 1 代表持久链接   最后修改了本参数,链接问题解决了.	persistent=0 持久链接失效/	良好

优化系统	具体优化点	优化意见
客户端	１.本地缓存技术	1.要求实现
	２.CSS,JS压缩处理	1.要求实现
	３.代码压缩技术	1.要求实现
函数优化	１如loadsucha方法:在卖房 ； 租房 ；小区列表； 小区检索中出现。本方法在这几个功能模块中不应该存在，它会自动加载本页面，造成大量的无用的请求和网络带宽	1.减少无用函数重复的调用，删除这个方法。
后端数据调用	１.小区列表	1.要求走memcache
	２.小区房价	1.要求走TC
	３.小区相册	1.要求走TC
	４.小区详情	1.要求走TC
	５.房源详情，比较慢	1.要求走TC,不走DB
SQL语句优化	１.SELECT *  FROM `t_rent` WHERE `house_id` =  '256'   AND `status` =  '1'  order by refresh_time desc  LIMIT 0,6;  最新出租房源	1.要求只取需要的字段，不要用* 2.速度比较慢，建议走缓存
	２.u SELECT count(*) as count FROM `t_rent` WHERE `company_id` =  '101'   AND `agent_id` =  '1'   AND `status` =  '1'; 公司门店有效出租房源量	1.要求只取需要的字段，不要用* 2.速度比较慢，建议走缓存
	３.SELECT count(*) as count FROM `t_sale` WHERE `status` =  '1'； //出售房源	1.修改成sphinx获取数据
	４.u SELECT count(*) as count FROM `t_rent` WHERE `status` =  '1';  //出租房源	1.修改成sphinx获取数据
首页优化	１.外部服务器慢 http://cms.xxx.com/upload/js/jquery.js?_=1304393380272	1.要求修改，客户端要求添加缓存
	２.google 统计	1.放到body 最后面
	３.首页－房价走势	1.默认值：城市，直接走缓存取数据，具体的flash还没有处理方法
	４.您可能感兴趣的房源	1.数据要求缓存　1小时缓存
系统安全	１.VIP,ADMIN 增加验证码
不确定优化方法	１.sphinx CPU使用率达　１００%
	２.CMS　系统比较慢（可能是网络的原因）

 

 

优化工作:

  对自己在公司做的工作做如下的总结:

1.优化方面1:业务调整,过度或是频繁调用程序都会造成软件的使用不合理

2.memcache 长短链接测试,其中false代码是短链接的.马上释放.

3.js ,jpg ,css 在网站的优化也相当的重要的

 memcache 性能测试:对于memcache 版本V1.4.5 针对不同的参数进行了如下的测试测试结果如下:

 

场景名称	参数	响应时间	PV	CPU	CONN	TCP
100user-m-2024	-m-2024	0.071	1368	70-80%	20-31	5800-6000
200user-m-2024	-m-2024	0.138	1387	80-90%	40-60	5800-6006
300user-m-2024	-m-2024	0.207	1391	80-90%	50-70	5800-6000
400user-m-2024	-m-2024	0.271	1380	85-92%	60-80	4400-5100
300user-m-2024-t-1	-m-2024-t-1	0.203	1410	80-92%	40-60	4900-5200
300user-m-2024-t-1-c-2048	-m-2024-t-1-c-2048	0.202	1412	80-92%	40-60	4900-5400
300user-m-2024-t-64-c-2048	-m-2024-t-64-c-2048	0.215	1304	80-92%	240-260	5000-6000
300user-m-2024-t-2-c-2048	-m-2024-t-2-c-2048	0.204	1393	80-92%	40-70	5000-6000
300user-m-2024-t-1-c-5000	-m-2024-t-1-c-5000	0.198	1420	80-92%	40-60	5000-5800
300user-m-2024-t-1-c-5000-f-1.1	-m-2024-t-1-c-5000-f-1.1	0.202	1415	80-92%	40-60	5000-5800

 

 从图中可以发现,在本环境中,单个线程比多个线程的效果更了,根据官方的资料显示,memcache对多线程的支持不是太好的.

   如果并发量不是很大的话,建议采用单线程进行.

Browser emulation 实验
实验一：
　　１.默认设置　
　　结果
　　１.数据量为：
　　　123784 body bytes, 4956 header bytes 　
实验二：
　　１.设置为　simulate a new user on each iteration 去掉对钩
　　　　　　　　　clear cache on eache iteration
   　结果
　　　１.数据量为：
　　　　107159 body bytes, 4953 header bytes 
实验三：
　　　１.设置为：
　　　　　download non-html resources 去掉对钩　其它默认值
　　　结果
　　　１.数据量为：　2254 body bytes, 428 header bytes
结论：
　　　１.默认设置是请求数据是最大的，也就是每一个用户都是一次新的请求，没有做过处理，是用户真实的操作行为
　　　２.　实验二：将部分的页面缓存起来,但是还要进行下载的。
　　　３.　实验三：不下载图片资源，其它的资源都在缓存中已经存在的。所以下载的数据量比较小的。只下载html的资源　

action and step 区别
实验一：
  1.一个脚本中两个 web_url aaa ,bbb
  2.放置在一个action　中
  3.选择　define each action as a transaction
结束分析中：
　sum tps: 16.2
　hits: 240 左右
实现二：  
  1.一个脚本中两个 web_url aaa,bbb
  2.放置在一个　action 中　
  3.选择　define each step as a transaction
结果分析中：
　sum tps : 32　左右
　hits :240　左右
实现三：
　1.一个脚本中两个 web_url aaa,bbb
  2.放置在一个　action 中　
  3.选择　define each action as a transaction
  4.给　aaa 增加事务为：　aaa-trans
结果分析中：
　sum tps : 32　左右
　hits :240　左右
实现四：
　1.一个脚本中两个 web_url aaa,bbb
  2.放置在一个　action 中　
  3.选择　define each step as a transaction
  4.给　aaa 增加事务为：　aaa-trans
结果分析中：
　sum tps : 48　左右
　hits :240　左右
　总结：loadruner会自动将用户自己定义的事务和脚本的事务相加后，得到一个总共的sum tps　其实这样就会重复计算里面的事务数量。
　但是loadrunner有一个过滤的功能，可以将这一部分自己定义的事务去掉，提到真实的TPS，也是我们平时说的　PV/S 。
　其实真正反映服务器的性能转点是　HITS，通过它我们可以直接看到服务性能的容量。我一般都会看这个指标，但是有一个问题，就是它会统计：js ,css,jpg等等这也算是一个请求，这样的请求其实对服务器的压力比较小的，如果算一个PV　其实也是不准确的。
　　所以我们现在测试，就按每一个web_url web_submit_form　按步来进行计算这样更真实的反映我们服务器的PV值。
　　这个也是自己以前不太清楚的地方，今天做了几个实验，验证了自己的想法。高兴。。。

上周末看到asktom上的一个帖子，其中有人提到session_cached_cursors和cursor_space_for_time对library cache gets&pin的影响，帖子的url为
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:465420331879

其中tom还为我们展示了session_cached_cursors和cursor_space_for_time对library cache gets&pin在9i和10g中的影响是不同的。

先让我们来了解一下session_cached_cursors，cursor_space_for_time，library cache gets，pin

session_cached_cursors:
设置pga端的cache list的长度，当session_cached_cursors设置为0时，pga的cache list长度为0，这时候当sga中的cursor关闭的时候它相关的library cache handle的lock位被清0，从v$open_cursor里看不到这个被关闭的cursor，它服从于shared pool的lru机制，当shared pool需要新的buffer空间时，它将会被flush出shared pool。当session_cached_cursors设置为非0值时，pga的cache list长度为session_cached_cursors值的大小，同时pga cache list将会保留一份拷贝，这时候即使sga中的cursor关闭的时候它相关的library cache handle始终被加了null mode lock，当shared pool空间紧张时library cache handle始终将会被保留在shared pool中.而新的应用访问这个cursor的时候会直接去自己的pga cache list里面搜索。

cursor_space_for_time：
当设置了session_cached_cursors为非0值后，如果cursor_space_for_time值被设为false，那么当shared pool空间紧张时，虽然library cache handle不会被flush出去，但是它指向的library cached object(lco,其中包含了handle和children handle的地址，权限，类型，状态，指向kgl block的指针，其中kgl block包含了真正的代码段和执行计划等内容）将会被flush出去而不管它相关的cursor有没关闭，如果需要lco的时候将要reloads。
如果cursor_space_for_time值被设为true，那么当cursor在打开状态下，handle指向的lco将不会被flush出shared pool，这样就可以降低reloads出现的频率。不过对于sql共享做的不好的数据库，设置
cursor_space_for_time将会带来一些问题，share pool可能会出现04031的错误。

gets:
当试图parse一句sql时，oracle要先获得一个handle，在handle上加载一个lock，gets表示handle request times。

pin：
当获得handle后，定位到lco，然后pin住lco使它在被执行的时候不被flush出去。

既然理解了以上一些概念，那么我们可以通过一些代码演示session_cached_cursors,cursor_space_for_time对pin，gets的影响

在9i和10g中两个参数对pin,gets的影响也不一样

9i：

vi 1.sql

set wrap off
set linesize 100
set pagesize 0
set verify off
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;
select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’ ;

执行10次sql

SQL 9I>show parameter cursor
NAME TYPE VALUE
———————————— ———– ——————————
cursor_space_for_time boolean FALSE
session_cached_cursors integer 0

SQL 9I>@$HOME/1.sql
NAMESPACE GETS GETHITS PINS PINHITS
————— ———- ———- ———- ———-
SQL AREA 2942908 2939105 75218597 75211231
SQL AREA 2942909 2939106 75218600 75211234
SQL AREA 2942910 2939107 75218603 75211237
SQL AREA 2942911 2939108 75218606 75211240
SQL AREA 2942912 2939109 75218609 75211243
SQL AREA 2942913 2939110 75218612 75211246
SQL AREA 2942914 2939111 75218615 75211249
SQL AREA 2942915 2939112 75218618 75211252
SQL AREA 2942916 2939113 75218621 75211255
SQL AREA 2942917 2939114 75218624 75211258

可以看到gets每次增加1，pin每次增加3

修改session_cached_cursors＝100；

SQL 9I>alter session set session_cached_cursors=100;
SQL 9I>@$HOME/1.sql
SQL AREA 2942935 2939123 75218728 75211344
SQL AREA 2942935 2939123 75218730 75211346
SQL AREA 2942935 2939123 75218732 75211348
SQL AREA 2942935 2939123 75218734 75211350
SQL AREA 2942935 2939123 75218736 75211352
SQL AREA 2942935 2939123 75218738 75211354
SQL AREA 2942935 2939123 75218740 75211356
SQL AREA 2942935 2939123 75218742 75211358
SQL AREA 2942935 2939123 75218744 75211360
SQL AREA 2942935 2939123 75218746 75211362

gets不再增加，pin增加2

SQL 9I>show parameter cursor
NAME TYPE VALUE
———————————— ———– ——————————
cursor_space_for_time boolean TRUE
session_cached_cursors integer 100

SQL 9I>@$HOME/1.sql
NAMESPACE GETS GETHITS PINS PINHITS
————— ———- ———- ———- ———-
SQL AREA 932 508 3561 3159
SQL AREA 933 509 3563 3161
SQL AREA 934 510 3565 3163
SQL AREA 934 510 3566 3164
SQL AREA 934 510 3567 3165
SQL AREA 934 510 3568 3166
SQL AREA 934 510 3569 3167
SQL AREA 934 510 3570 3168
SQL AREA 934 510 3571 3169
SQL AREA 934 510 3572 3170

cursor_space_for_time改为ture后，pin变成每次增加1

10g：
SQL 10G>show parameter cursor
cursor_space_for_time boolean FALSE
session_cached_cursors integer 0

SQL 10G>@$HOME/1.sql
SQL AREA 3328 98 23112 21363
SQL AREA 3328 98 23113 21364
SQL AREA 3328 98 23114 21365
SQL AREA 3328 98 23115 21366
SQL AREA 3328 98 23116 21367
SQL AREA 3328 98 23117 21368
SQL AREA 3328 98 23118 21369
SQL AREA 3328 98 23119 21370
SQL AREA 3328 98 23120 21371
SQL AREA 3328 98 23121 21372

gets不变化，pin每次增加1

SQL 10G>alter session set session_cached_cursors=100;
SQL 10G>@$HOME/1.sql
SQL AREA 3513 98 28456 26335
SQL AREA 3513 98 28457 26336
SQL AREA 3513 98 28458 26337
SQL AREA 3513 98 28459 26338
SQL AREA 3513 98 28460 26339
SQL AREA 3513 98 28461 26340
SQL AREA 3513 98 28462 26341
SQL AREA 3513 98 28463 26342
SQL AREA 3513 98 28464 26343
SQL AREA 3513 98 28465 26344
设置了session set session_cached_cursors后没有变化

SQL 10G>show parameter cursor
NAME TYPE VALUE
———————————— ———– ——————————
cursor_space_for_time boolean TRUE
session_cached_cursors integer 100
SQL 10G>@$HOME/1.sql
NAMESPACE GETS GETHITS PINS PINHITS
————— ———- ———- ———- ———-
SQL AREA 1038 24 4404 3488
SQL AREA 1038 24 4405 3489
SQL AREA 1038 24 4406 3490
SQL AREA 1038 24 4407 3491
SQL AREA 1038 24 4408 3492
SQL AREA 1038 24 4409 3493
SQL AREA 1038 24 4410 3494
SQL AREA 1038 24 4411 3495
SQL AREA 1038 24 4412 3496
SQL AREA 1038 24 4413 3497

设置cursor_space_for_time为true后也没有变化

但是当设置cursor_space_for_time为true后pl/sql block将会使pin也停止增长

看tom的例子

ops$tkyte@ORA10G> create or replace procedure p
2 authid current_user
3 as
4 l_ns varchar2(4000);
5 l_gets number;
6 l_gethits number;
7 l_pins number;
8 l_pinhits number;
9 l_sgets number;
10 l_sgethits number;
11 l_spins number;
12 l_spinhits number;
13 begin
14 for i in 1 .. 1000
15 loop
16 execute immediate
17 ’select namespace, gets, gethits, pins, pinhits
18 from v$librarycache
19 where namespace = ”SQL AREA” ‘
20 into l_ns, l_gets, l_gethits, l_pins, l_pinhits;
21
22 if ( i in (1,1000) )
23 then
24 if ( i = 1 )
25 then
26 l_sgets := l_gets; l_sgethits := l_gethits;
27 l_spins := l_pins; l_spinhits := l_pinhits;
28 end if;
29 dbms_output.put_line
30 ( l_ns || to_char(l_gets,’999,999′) ||
31 to_char(l_gethits,’999,999′) ||
32 to_char(l_pins,’999,999′) ||
33 to_char(l_pinhits,’999,999′) );
34 if ( i = 1000 )
35 then
36 dbms_output.put_line
37 ( l_ns || to_char(l_gets-l_sgets,’999,999′) ||
38 to_char(l_gethits-l_sgethits,’999,999′) ||
39 to_char(l_pins-l_spins,’999,999′) ||
40 to_char(l_pinhits-l_spinhits,’999,999′) );
41 end if;
42 end if;
43 end loop;
44 end;
45 /

Procedure created.

sys@ORA10G> alter system set session_cached_cursors=100 scope=spfile;

System altered.

sys@ORA10G> alter system set cursor_space_for_time=TRUE scope=spfile;

System altered.

sys@ORA10G> startup force
ORACLE instance started.

Total System Global Area 171966464 bytes
Fixed Size 777956 bytes
Variable Size 145760540 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
sys@ORA10G> @connect /
sys@ORA10G> set termout off
ops$tkyte@ORA10G> @login
ops$tkyte@ORA10G> set termout off
ops$tkyte@ORA10G> REM GET afiedt.buf NOLIST
ops$tkyte@ORA10G> set termout on
ops$tkyte@ORA10G> exec p
SQL AREA 1,181 373 4,828 4,171
SQL AREA 1,181 373 4,828 4,171
SQL AREA 0 0 0 0

PL/SQL procedure successfully completed.

可以看到10g的pl/sql引擎也有了变化。

再来看一下设置session_cached_cursors后handle的dump

BUCKET 110279:
LIBRARY OBJECT HANDLE: handle=9df283a8 mutex=0×9df2845c(1)
name=select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’
hash=f1deb637acf7a42dd55d86a8ae3baec7 timestamp=08-30-2005 17:07:35
namespace=CRSR flags=RON/KGHP/TIM/KEP/PN0/MED/KST/DBN/MTX/[500100d4]
kkkk-dddd-llll=0001-0001-0001 lock=N pin=0 latch#=7 hpc=0002 hlc=0002

而不设置的话
BUCKET 110279:
LIBRARY OBJECT HANDLE: handle=9df283a8 mutex=0×9df2845c(1)
name=select namespace, gets, gethits, pins, pinhits from v$librarycache where namespace = ‘SQL AREA’
hash=f1deb637acf7a42dd55d86a8ae3baec7 timestamp=08-30-2005 17:07:35
namespace=CRSR flags=RON/KGHP/TIM/KEP/PN0/MED/KST/DBN/MTX/[500100d4]
kkkk-dddd-llll=0001-0001-0001 lock=0 pin=0 latch#=7 hpc=0002 hlc=0002

如果执行alter system flush shared_pool 那么没有加载null mode lock的handle将被flush出shared pool。

/*单个测试类 进行测试*/

import static org.junit.Assert.*;

import org.junit.Test;
import junit.framework.TestCase;

public class JiaFaTest extends TestCase {
 
 @Test
 public   void testJiafa() {
  //fail("Not yet implemented");
  JiaFa t=new JiaFa();
  assertEquals(-2147483639,t.jiafa(2147483647, 10));
 }

}

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

增加测试suite

import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests1 {

 public static Test suite() {
  TestSuite suite = new TestSuite("Test for default package");
  //$JUnit-BEGIN$
  suite.addTestSuite(ParameterTest.class);
  suite.addTestSuite(JiaFaTest.class);
  suite.addTestSuite(JianFaTest.class);
  suite.addTestSuite(DivTest.class);
  suite.addTest(AllTests.suite());
  //$JUnit-END$
  return suite;
 }

}
----------------------------------------

[被测试类

public class JiaFa {
 public int jiafa(int a ,int b){
  return a+b;  
 }

}

   几天的捉摸都算是明白了junit的基本用法,但是如果复杂的测试,这种代码就很可怜了.. 根本不够用的.

   还在不停的学习中...

 

  
 
import static org.junit.Assert.assertEquals;  
 
import java.util.Arrays;  
import java.util.Collection;   

import junit.framework.TestCase;

import org.junit.Test;  
import org.junit.runner.RunWith;  
import org.junit.runners.Parameterized;  
import org.junit.runners.Parameterized.Parameters;   
 
/** 
 * 参数化设置 
 *  
 * 1 测试类必须由parameterized测试运行器修饰 
 * 2 准备数据，数据的准备需要在一个方法中进行，该方法需要满足一定的要求 
 *   1)该方法必须有parameters注解修饰 
 *   2)该方法必须为public static的 
 *   3)该方法必须返回Collection类型 
 *   4)该方法的名字不作要求 
 *   5)该方法没有参数 
 *    
 *   int.class == Integer.TYPE != Integer.class 
 */ 
// 测试运行器  
@RunWith(Parameterized.class)  
public class ParameterTest extends TestCase {  
    private int expeted;  
    private int input1;  
    private int input2;  
      
    @Parameters 
    @SuppressWarnings("unchecked")  
    public static Collection perpareData() {  
        Object[][] bjects = { {3,1,2}, {0,0,0}, {-4,-1,-3} };  
          
        return Arrays.asList(objects);  
    }  
      
    public ParameterTest(int expected, int input1, int input2){  
        this.expeted = expected;  
        this.input1 = input1;  
        this.input2 = input2;  
    }  
      
    @Test
     public void testAdd() {  
        Calculator cal = new Calculator();  
        assertEquals(expeted, cal.add(input1, input2));  
    }  
} 
===========================================

被测试类
public class Calculator {

 public int add(int a,int b){
  
  int c ;
  c= a + b;
  return c;
 }
}

 

晚上八九点钟的太阳

   —献给软件测试和质保人员

 我更喜爱晚上八九点钟的太阳，

虽然人们都已把他遗忘，

但他还是艰难地悬挂在天上。

我更喜爱晚上八九点钟的太阳，

因为他将奏出黎明的交响。

没有他

又怎会呼唤出一片明亮？

第一小结　　library cache 的内存结构



Library cache的作用，最主要的就是存储已解析的SQL声明，避免硬解析。我们可以通过一个视图V$librarycache来了解Library cache点中率，已此来评估SQL声明的解析情况。应时时注意此视图中点中率情况，好及时发现并解决问题。
一、Library cache中所存储的信息：
1. 按对象类型分类：
共享游标（SQL and PL/SQL objects）、数据库对象（tables, indexes, and so on）
2. 按存在时间分类：
存贮对象：如表、索引、视图等（老化后 磁盘上还有 所以叫永久存储 并不是永久存储在LIBRARY 中）
瞬时对象：如游标（老化后就没有了）（简单了解在Library cache中数据库对象的信息是什么）
二、Library cache中如何存储信息 
了解Library cache的简单原理，对于理解一些调优概念，是十分必要的。 
共享池内存的结构，是计算机中常用的哈希表形式的扩展。常用的哈希表形式，总是先有一个哈希表，保存对象地址（或句柄），然后，根据对象地址（或句柄）访问对象，计算机中常以这种方式组织数据。其基本形式如下：


[attach]292840[/attach]

注意地址和句柄的区别，一般来说，地址只是一个位置信息。而句柄，除了位置，还包含一些其他信息。
还要注意“堆（Heap）”的概念，程序开发者在程序员使用系统函数分配的内存。
注：此处补充一点概念，除了堆之外，还有栈，也是内存中比较常见的名词。开发者在程序中定义的各种变量，就在栈中分配。
上图每一组哈希值、链表头，叫做一个哈希桶。简单的说就是：哈希桶（Hash Bucket）指向对象句柄（Object Handles），对象句柄存有对象所占的堆内存的地址。由于对象的堆往往不只一个，Oracle习惯称这些堆为子堆。通常，对象句柄中存有0号子堆的地址，而0号子堆中存有其他各个子堆的地址，而Library cache中所存贮对象的信息，就在从0号开始的各个子堆中。


第二小节 Library cache的PIN与LOCK


一、详述Library cache lock与Library cache pin
1.
Library cache lock与Library cache pin的模式。
       所有在Library cache中的对象，都由两部分组成，一个句柄、至少一个子堆。这一点可以参考上面的图。
句柄中记录的有对象的名字、命名空间、Lock的持有者和等待者、Pin的持有者和等待者、一些标志信息，最重要的，句柄中记有堆的地址。
在Library cache中寻找对象时，先计算HASH值，在HASH表中找到句柄，再经由句柄，找到对象实际的内存地址。在这个过程中，有两个重要的数据项需要被锁保护起来。一个是对象句柄、另一个就是对象的内存堆。在对象句柄上加的锁就是Library cache lock，在内存堆上加的锁，就是Library cache pin。
下面先讨论一下Library cache lock。
（1）。 Library cache lock
Locks 除了阻止不相容的对句柄的访问，以保护句柄中数据的完整性外，获得Locks也是在缓存中定位对象的唯一方式，即：进程在对句柄上加锁的同时，完成在内存中定位堆的操作。
在句柄上获得Lock、并在内存中定位到堆后，对象可以Pin自己的堆。如果对象相关信息不在内存中，Pinning一个对象将导致它和它的的子堆被装载（此种情况时，如果是多个对象Pin一个对象，将可能会造成Pin等待）
Lock 有三种模式
  · Share(s) : 读对象
  · Exclusive(x) : 修改或创建对象
  · Null(n) : 专用于为会话持续
注意： 存贮对象可以被锁在以上任意一种方式，瞬时对象只能被锁在Null方式。
Null 锁在执行SQL声明的解析阶段被获得，此后一直持有。它不阻止任何DDL。也用术语“易碎解析锁”称乎它（breakable parse lock）。
在以下两种情况下Null锁被打碎：
· 当锁所在对象有一个独占Pin时
· 锁所在对象的任何依赖对象有一个独占Pin时
（2）。Library cache pin：
Pin有两种模式：
· Share (s) : 读一个对象堆
· Exclusive (x) : 修改一个对象堆
无论存贮对象还是瞬时对象，都能被Pinned在Share或Exclusive模式。当修改对象时，进程首先会以Share模式Pin对象，进行错误和安全检查，然后在以Exclusive模式Pin住对象。Pin的解除将会导致相关对象上的易碎锁Break
不同类型的操作所需要的不同类型的lock/pin：
1).
所有的DDL操作都会在需要处理的对象上放一个Exclusive(排他)类型的Lock和Pin(仅仅当执行的时候加上)。
如:重编译,截断表,给对象授权,等等
2).
所有对对象的使用都需要一个null类型lock和shared类型的pin(仅仅当执行的时候加上)。如:使用视图,执行过程,等等。
以上规则，也同样应用于对象所有依赖的对象。如:一个依赖于其他视图的视图,一个依赖于其他包的包。

下面我们用一个例子，来验证一下Library cache lock/pin。
例10：观察Library cache lock/pin 的状态：
先建立一下如下过程：
create or replace procedure jj_cur is
cursor aa is select kglhdlmd,kglhdpmd 
from x$kglob where kglnaobj='select * from aa_1 where id=1' and kglhdadr<>kglhdpar;

kk number:=5;

kk1 number:=5;

begin

for i in 1..2000 loop

kk:=5;

kk1:=5;

open aa;

fetch aa into kk,kk1;

dbms_output.put_line(kk||'-'||kk1);

close aa;

end loop;


end;
/
Kglhdadr是游标句柄，而Kglhdpar是父游标句柄，条件中的kglhdadr<>kglhdpar ，目的是只显示子游标。Kglhdlmd是Library cache lock的模式，为0时表示没有锁，1是NULL锁，2是共享锁，3是独占锁。Kglhdpmd是Library cache pin的模式，0是没有Pin，2是共享Pin，3是独占Pin。
另外，我们作为测试用的SQL声明select * from aa_1 where id=1，要保证只有一个子游标，这样做的目的，就是让过程中的游标AA只选出来一条记录。在过程执行完毕后，最好再执行声明：select kglhdlmd,kglhdpmd from x$kglob where kglnaobj='select * from aa_1 where id=1' and kglhdadr<>kglhdpar一次，看一下能选出来几行，如果多于一行，说明声明子游标的数量多于一条，应该换一条声明再试。
在会话A中：
spool e:\oracle\aaa.txt
exec jj_cur;
在会话B中：
select * from aa_1 where id=1;
在会话A中：
spool off
查看e:\oracle\aaa.txt，可以看到，在会话B的声明执行时：Library cache lock先是1，然后是0。而Library cache pin先是3，后是2，然后是0。会话B中的声明是第一次执行，这是硬解析，所以会有很短时间的独占Pin。上面的例子，可以再试一次，这次，就是软解析了。试验过程同上，结果是，Library cache lock仍是1，然后是0，而Library cache pin则是2，然后是0，不再有3了。
       我们可以再用上面的方法，测试一下父游标上的锁的情况，这里就略过了。
       我记得有资料上说，声明在解析时，在父、子游标上会有独占锁的，但是在上面的测试中，却没有看到。有可能是我的过程执行速度不过快，无法捕找到句柄上的独占锁。 library.GIF (17.71 KB)