• 对场景进行设计后，接着需要对负载生成器进行管理和设置。Load Generator是运行脚本的负载引擎，在默认情况下使用本地的负载生成器来运行脚本，但是模拟用户行为也需要消耗一定的系统资源，所以在一台电脑上无法模拟大量的虚拟用户，这个时候可以通过多个Load Generator来完成大规模的性能负载;

  1、添加负载机器之前需要开启代理运行时设置；

  注意：默认选第一项后，在这里点击OK，可能开启不了小雷达，目前在我们实际的工作中已经出现了这样的问题，后来我们找到了解决的方法。开启不了小雷达，我们选择第二项，点击OK，发现会报运行时错误，报错后我们点击报错中的退出，然后进入开始-所有程序-LoadRunner-Advanced Settings,找到Agent Configuration，点击后弹出如下界面，我们勾选第二项后，点击OK，发现小雷达出现了。

  2、设置完成后添加负载机器：

  　　● “New Rule”：在该应用下新建规则，规则中包含字符串或者字符前缀和后缀。

  　　● “Set as Default”：默认情况下，当前所作的更改只适用于当前的脚本，如果想让更改适用于本机所有脚本的话，单击该按钮即可。

  　　● “Import/Export”：利用该按钮可以把定义好的规则导入和导出。

  　　其他的标签设置采用默认值即可，这里不再详细地介绍。

• 1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

  
  2. 查找瓶颈时按以下顺序，由易到难。

  
  服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器瓶颈（参数配置）-〉中间件瓶颈（参数配置，，服务器等）-〉应用瓶颈（语句、数据库设计、业务逻辑、算法等）
      注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

  
  3 分段排除法 很有效分析的信息来源：
  1 根据场景运行过程中的错误提示信息
  2 根据测试结果收集到的监控指标数据

  1．最大并发用户数：应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
  在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
      如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

  
  2．业务操作响应时间：
       分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
      细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
    如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

  3．服务器资源监控指标：

  1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
  bytes计数器的值持续降低，则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆:很高的换页率(high pageout rate);进程进入不活动状态;交换区所有磁盘的活动次数可高;可高的全局系统CPU利用率; 内存不够出错(out

  utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL

  
  1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
  Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 
  3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
  4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

   性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比较复

  杂、需要具备很多相关的专业知识，因此常常会感觉拿到数据不知从何下手。这也是我性能

  测试过程中感觉比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特作了以下笔

  记，这里只是书中第4章WEB应用程序性能分析的一

  部分，贴出来希望和大家共同讨论：

  一：性能分析的基础知识：

  1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS（每秒钟处理的交易数）、点

  2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB服务

  器、数据库服务器、操作系统四个方面。

  3.常规、粗略的性能分析方法：

     当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统

  基本稳定；若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是

  网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。

  4.作者提出了如下的性能分析基本原则，此原则本人十分赞同：

      应用此原则，分析步骤具体可以分为以下三步：

     第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；

     第二步：比较Tn（网络响应时间）和Ts（服务器响应时间）可以确定瓶颈发生在网络还是服

     第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。

  二：以WEB应用程序为例来看下具体的分析方法：

  失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。若失败的事务非常多，则

  说明系统发生了瓶颈或者程序在执行过程中发生了问题。

  测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务

  的最大值、最小值和平均值。通过它可以分析系统的性能走向。若所有事务响应时间基本成一条

  曲线，则说明系统性能基本稳定；否则如果平均事务响应时间逐渐变慢，说明性能有下降趋势，

  造成性能下降的原因有可能是由于内存泄漏导致。

  秒中，每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务

  负载。若随着测试的进展，应用系统在单位时间内通过的事务数目在减少，则说明服务器出现瓶

  每一秒中，通过、失败以及停止的事务总数。若在同等压力下，曲线接近直线，则性能基本趋于

  稳定；若在单位时间内通过的事务总量越来越少，即整体性能下降。原因可能是内存泄漏或者程

  最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求（重点关注事务平均、最大

  该图可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性

  图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发，若可能事务的最大响

  应时间很长，但如果大多数事务具有可接受的响应时间，则系统的性能是符合。

  图显示了测试过程中不同响应时间的事务数量。若系统预先定义了相关事务可以接受的最小和最

  大事务响应时间，则可以使用此图确定系统性能是否在接受范围内。

        分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入

  的分析。没有贴图，看起来有点费劲，如果你对这些图都比较了解，应该是比较简单的.

• 1,把rstatd文件解压到要监控的机器上。

  2,打开终端，定位到rstatd文件夹下：查看文件夹中的内容如下：

  这之后可以执行:make check检查一下。

  命令。启动rpc服务。

  命令。检查rpc服务的状态.

  1,若RPC服务没有成功启动。

  2,若目标主机上开启了防火墙，阻挡了RPC服务。

  在LR中添加时可能会出现如下错误：

• 首先，telnet以root用户的身份登录入系统，在命令行提示符下输入：

  进入编辑文件页面后，输入：

  （命令解释：在打开的文档中查找“rstatd”）接下来继续输入：

  （命令解释：删除当前字符，在这里为删除rstatd命令前的“#”）继续输入：

  （命令解释：保存并退出，注意前面有个冒号）

  
  接着在命令提示符下输入：

  （命令解释：重新启动服务）

  这样使用loadrunner就可以监视AIX系统的性能情况了。

• 在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。  
  　　前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：  
  　　通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：  
  　　看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。  
  　　事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。  
  　　因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角，中国自学编程网， 。  
  　　对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义： “要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )  
  　　面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。  　　因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。  
  　　最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。

• 如何在Loadrunner中监控服务器资源使用情况

  一．监控需要进行的配置：

  在LR控制台设置监控Windows服务器的资源比较容易，直接添加Measurements即可。

  但是大多情况下面服务器的操作系统是Linux或者Unix，这时想监控系统的资源使用情况就需要进行一些设置：

  1．由于LR是通过rpc.rstatd进程获得系统的性能数据，因此首先查看进程中是否存在该进程，或者能否通过运行./rpc.rstatd启动该进程，如果可以，恭喜你，你可以直接在LR的控制台添加

  理论上info为7个进程（前面共有两次start），如果各位有

  兴趣可以自己使用rpcinfo来查看前后的服务对比。

  关于之上的那段Shell程序，偶还灭有研究过。待研究过以后，在放上来与大家一起分享。

  本帖后上传了两个中间文件分别为：

  Average Load:上一分钟同时处于“就绪”状态的平均进程数

  Page-in Rate:每秒钟读入到物理内存中的页数

  Page-out Rate:每秒钟写入页面文件和从物理内存中删除的页数

  Paging Rate:每秒钟读入物理内存或写入页面文件中的页数

  Memory:内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始： 
  MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

  
  page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

  Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

  
  Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 
  

  
  Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

  Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。 
  Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。 
  Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。

  Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。 
  %Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。 
  %User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 
  %Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。 
  % DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

  (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

  %Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘

• 说一下oracle的性能测试。 oracle的性能测试主要是模拟大量的sql语句操作，来对数据库服务器进行加压。在测试前，需要准备以下要模拟的sql语句，测试脚本，并将测试控制机、测试加压机、被测数据库服务器准备妥当。

  将脚本放在控制机上，就可以开始加压了，注意的是，被测数据库服务器的各个参数配置要记录下来，以便修改参数调优时能分析清晰。记录下数据库的iops，time，tps和响应时间，结果汇总出报告。

• 　　一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同，其数据报文的结构也有所不同。协议是有层次的，一般我们从ip层开始，往上有TCP协议层，UDP协议层，而TCP和UDP协议层上又有http协议层，ftp协议层，smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子，本来IP协议的数据报文是无序，不是可靠传输的，在其数据报文外面增加了报文序号，报文状态等数据段就构成了TCP协议层。所以我们很多网络应用，没有找到合适的协议，就用winsock来录制，那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的，而socket正是这一级上的概念。但是由于socket协议级别太低，你录下来的东西是很难理解的，都是 socket，port，data之类的东西。所以，我们尽量用高层协议来录制，我们就能看懂了。

  　　话要再说回来，解决一下具体的问题。我们看到一个软件体系架构，应该怎样选择录制协议呢？说到这里，我要说一下自己对lr录制机理的理解（我没有接触过lr内核，只是凭猜测和推断）。在录制时，lr应该会对你从本机发出去的数据进行截包，并拆包。因为我们知道协议的不同就是体现在数据包的结构不同，lr应该通过对包结构的分析，判断是不是它支持的协议，对包数据的分析，来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作，那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包，都是http协议格式的包，它不认，当然就是一个录制为空的结果了。现在我们弄懂了这个事情，就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的：

  　　1、首先弄清mysql协议和其他数据库协议的关系，看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议，sqlserver也是一样，而mysql又与这几大产品又不是隶属关系，其脚本录制的可能性很小。

  　　2、mysql协议的底层是基于什么协议的，如果直接构建在tcp协议上，lr又不支持mysql协议，那只能考虑用低一点的协议录录看，即socket。如果mysql协议是构建在odbc协议上的，那么就可能用lr的odbc api来写。

  　　很多时候一提到不是基于浏览器的应用，很多人就会想到用WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此，不是所有的程序都是适合WinSocket协议的。实际上，那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以参考录制的结果。所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前，要先和开发人员了解一下他们在开发过程中都用了些什么技术，数据流是用什么协议封装的，还要了解我们要测试的系统的网络结构，服务器的配置等问题；还有就是要知道系统客户端和第一服务器间的协议，这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则（都是自己遇到过的，呵呵，没遇到过的就不知道了）：

  　　1、一般情况下b/s构架的只要 选择WEB（Http/Html)协议就可以了，如果有中间件的则选择中间件服务器的协议 ；

  　　2、C/S结构，可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用；MS SQL Server协议用与测试后台数据库为 SQL Server的应用；

  　　3、一般不是基于浏览器的，对于一些没有数据库的Windows应用，我们在测试的过程中都会选择WinSocket协议来录制，理论上来讲我们这样选择是正确的，但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包，如果我们选择错误了，将会捕获到一些无用的数据包。

  cs结构是比较复杂的，在这里我要提醒大家，一定要搞清楚cs是client-database还是client-server-database结构的，只有这样我们才能够决定是选择WinSocket协议还是sql协议，或者说选择多个协议；当然协议的选择也是一个探索的过程，只要能够得到我们想要的结果，那就是正确的。还有一点，我们在做性能测试的时候应该是有测试重点的，呵呵。

  　　4、关于单协议和双协议，我只知道IE6内核的浏览器在录制脚本的时候要选择单协议，而IE7内核的浏览器在录制脚本的时候要使用双协议。

  　　 　 C/S （第二种）客户端以ODBC方法连接后台数据库 ODBC

• 现在好多网站系统为了防范，恶意访问系统，在登陆口进行限制，使用验证码登陆。

  　　验证码是随机产生的，并且验证码在页面上显示为图片。此时想通过直接获取服务器发送过来的参数，肯定是不可行的。

  　　在进行的时候，有两种办法进行此类系统的测试。

  　　1、将验证码暂时屏蔽，待完成性能测试后，在恢复。验证码屏蔽一定不会给性能测试带来影响，这是肯定的。

  　　2、如果要测试系统是在用的系统，屏蔽验证码会带来不安全因素，不能屏蔽验证码。遇到这个问题当然也有办法解决－－添加一个页面将验证码的输出到页面，然后用loadrunner获取到。

  　　验证码页面（a.jsp）

  在iframe中放入的c.jsp页面就是 获取验证码的页面。 　　这儿加了一个c.jsp 页面链接，主要是用在loadrunner录制脚本的时候，a.jsp 和c.jsp在B页面上加载的顺序不是有序的，因而C.JSP可能获取到的验证码为NULL。 　　在C.JSP页面上 在取得的验证码前后加上两个Q主要为了loadrunner能够捕获到这个验证码做的标记。 //获取C.JSP页面上的验证码 　　运行的时候 要把loadrunner的浏览器给关掉，否则lr的浏览器显示一下，相当于也做了一次请求。

：用于卫星导航系统的扩展码的制作方法

本发明涉及卫星导航系统的扩展码组的产生和使用，该卫星导航系统中的每个卫星被分配一个或多个扩展码。

卫星导航系统在广泛的应用中变得日益重要，包括用于定位的手持设备、车内导航支持等等。目前使用的主要卫星导航系统是美国国防部运行的全球定位系统(GPS)。GPS装置的世界销售量在2003年达到接近35亿美元，并且这个数字预计在未来几年将稳步增长。相似的欧洲卫星导航系统称为伽利略，其计划发射并在本年代的后期提供服务。

卫星导航系统的星座由多个卫星构成，每个卫星向地球广播一个或多个信号。卫星信号的基本成分是扩展码(也称作定位码、同步码或测距码)，其组合导航数据。然后将组合的结果调制到规定频率的载波上以向地球发射。在某些情况下，可能将多个信号(称为信道)通过某种适当的多路复用方案调制到单个载波上。此外，通常每个卫星以多个频率发射，这可以有助于补偿任何一种大气干扰。

卫星信号的扩展码成分通常包含预定频率的位(有时称为“码片”)并且用于完成两个主要任务。第一，扩展码提供同步机制以允许接收机锁定到卫星信号。从而每个卫星(并且通常是广播自该卫星的每个信道)具有其自己的同步码。接收机在最初接通时不知道可以接收哪个卫星信号，因为星座中的某些卫星在那个特定时间可能对于那个特定位置来说位于地平线以下。接收机使用同步码锁定来自第一个卫星的信号。一旦完成这个操作，可以读取信号中的导航数据。然后这将提供对于星座中其它卫星的星历表数据，并且允许相对快速地获取该接收机可见的其余的卫星。

扩展码的第二个主要任务是基于信号从卫星传播到接收机所用的时间提供从卫星到接收机的距离估计，可以表示为c(Tr-Ts)，其中 c是光速(已知的，受电离层效应等影响)， Ts是从卫星发送的时间，其编码在信号本身中，以及 Tr是接收机处信号接收的时间。

然后在给定卫星已知位置(如在其导航数据中确定)的情况下，可以通过使用三边测量处理在三维空间中确定接收机的位置。理论上，这可以使用来自最少的三个卫星的信号信息来完成。然而在实践中，可以写为Tr＝Tm+o，其中Tm是接收机处所测量的接收时间，以及o是接收机时钟和卫星时钟之间的偏差，除了对于专门化的接收机以外该偏差通常未知。这意味着从至少一个额外的卫星获取信号信息以补偿接收机处未知的时间偏差。如果可获得来自更多卫星的信号，使用任何恰当的算法、例如最小平方法可以完成统计上的定位。这还可以提供一些和所估计位置相关的误差指示。

扩展码的一个重要参数是发射扩展码的位速率，其进而控制定位的精度。例如对于1MHz的位速率，每个比特代表300米的光传播时间。对于单个比特来说，根据对单一一比特如何精确办断卫星和接收机之间相位的偏差来确定定位精度。这通常取决于系统中的噪声。例如，如果可以以90度(π/2)的精度测量相位偏差，这对应于75米的定位精度。应当理解，具有较高比特速率的扩展码允许更加精确的定位。

扩展码的另一个重要参数是其总长度，换句话说是其发生重复之前扩展码中比特或码片的数量。一个原因是，有限长度的扩展码可以导致定位的模糊性。例如，假设位速率为10MHz以及比特序列的总长度为256比特，所以其对应于/gp sworld/article/articleDetail.jsp？id＝61244可以获得。

虽然Gold码的使用是针对现存的卫星导航系统制定的，但这些码仍具有某些局限。例如，其仅仅可获得某些码长度(并非所有数值N可以用于LFSR多项式)。通常，码长度由扩展码的码片速率和导航数据的位速率的比值确定。如果限制码长度为可获得的Gold码，这意味着对码片速率和位速率的约束，其进而影响其它的考虑，例如捕获时间和定位精度。在某些情况下，对Gold码长度的限制已经通过使用截断的Gold码而被克服，但这种截断具有对于码集合的数学性质(在自相关函数等方面)的不利影响。

此外，Gold码的互相关性质通常没有对以下情况进行优化根据发射的导航数据，码的极性从码的一次重复变化到下一次重复时发生改变。在导航数据的位速率相对较高的情况下(如对于伽利略)，后面的这个问题加剧，因为这导致极大的可能出现扩展码的发射具有和紧邻的前一次扩展码发射相反的极性。

发明内容 因此，本发明的一个实施例提供一种产生用在由卫星星座构成的卫星导航系统中的扩展码组的方法。从该扩展码组中为星座中的每个卫星分配一个扩展码。该方法包括产生位组合的初始组，其中每个位组合代表一个可能的扩展码，然后对位组合的初始组执行优化过程。在优化过程中，修改或者置换该初始组中的至少一些位组合以产生用作扩展码组的位组合最终组。

从而这样的方法避免使用由数学算法产生的码，转而使用通过优化过程作为位组合产生的码。这样的码可能具有位的用在卫星导航系统中的典型长度，但如果需要可以产生其它的码长度。甚至可以为了最好地适应系统的其它操作需求而为码选择任意的码长度，而非必须选择满足特定数学算法的码长度。

在一种实现方式中，产生位组合的初始组中的每个位组合作为随机位序列。可能在优化过程之前先修改这些个别的初始位组合以执行特定的标准-例如对位组合进行均衡以及对于每个位组合的第一自相关旁瓣为零。然后可以处理优化过程而保持这些性质不变，从而保证码组合的最终组同样是均衡的并且具有设定为零的自相关旁瓣。可以以这种方式执行的其它标准包含特定位数值(1和/或0)的最大游程。作为替代，可以将这样的标准结合到整个优化过程中，而不是作为预备条件进行处理。

在一个实施例中，优化过程尝试将位组合组的代价函数最小化。该代价函数可能基于位组合组的自相关和互相关值，包含奇和偶的自相关和互相关值(以适应扩展码的相继循环之间可能的极性反转)。对位组合间的全部可能偏移计算互相关值。一般来说，如果代价函数基于多个相关值(而不是例如只是任意给定位组合组中的最差相关值)，可以获得优化程序的较好收敛。在一个特定实现方式中，代价函数基于所有大于预定界限的自相关和互相关值的总和，例如Welch界(或者其若干倍)。

在一个实施例中，在优化过程中通过对至少一个位组合中的位进行随机翻转来修改位组合。如果发现这样的位修改导致代价函数增大则反转该位修改(从而保证位组合组不发生恶化)。随着代价函数的降低，所翻转的位的数量可能减小，从而在代价函数最小值周围提供更加灵敏的搜索。

应当理解，存在很多种已知的优化策略，例如模拟退火、遗传算法等等，并且可以采用任何合适的这种策略以产生位组合的最终组。在某些这种策略中，优化可能包括产生巨大数量的位组合进而选择最佳的例子(适者生存)，而不是预定组中的个别位组合的连续修改。

本发明的另一个实施例提供一种接收机，其结合使用如上所述方法产生的位组合的最终组。在一个实现方式中，该位组合可能由纠错码保护，并且可能存储在只读存储器(ROM)或可编程只读存储器(PROM)中。应当指出，后者允许在需要的情况下更新该位组合。应当理解，可以使用其它形式的存储器保存该位组合，该位组合相对较小-每个组合典型地小于1k字节(尽管与Gold码的情形相比，位组合的随机特性意味着无法获得更加紧凑或者压缩的表示)。

在一些实现方式中，接收机可能结合至少两个卫星星座的位组合，其中一个卫星星座包括GPS。应当指出，GPS扩展码是Gold码，并且通常在接收机中使用线性反馈移位寄存器产生。然而，当前的方法可以实现为重新适应GPS系统，从而允许将单个方法用于多个卫星导航系统。

在一些实现方式中，接收机使用的位组合可能存储在可移动存储器装置中。这可以便利于接收机所用码的更新，通过使用包含更新的码的新版本置换可移动存储器装置。在其它实现方式中，接收机可能能够通过例如互联网的网络进行存取(更新的)码。然后可以将这些码下载到接收机以允许卫星定位信号的捕获。使用这后一种方法，不必将码存储在接收机自身，但仍可以通过网络在需要时进行存取。

本发明的另一个实施例提供一种操作结合卫星导航系统使用的接收机的方法。该方法包括存取所存储对应于卫星导航系统使用的扩展码的位组合的组。该方法进一步包括使用所存储位组合捕获来自卫星导航系统的信号。所存储位组合还可以用于执行与来自卫星导航系统的信号有关的定位。

本发明的另一个实施例提供一种操作构成卫星导航系统一部分的卫星的方法。该方法包含在卫星中存储至少一个对应于扩展码的位组合；检索该位组合以产生结合该扩展码的信号；以及发射该信号。同样的方法可以应用于伪卫星(在卫星导航系统中仿真卫星的地基发射机)。

在一种实现方式中，所述检索包含对所存储的位组合执行差错检验码(ECC)检验。这可以有益于检测并且在可能的情况下校正已经在所存储的位组合中出现的任何错误(例如由于宇宙射线撞击)。该位组合可能存储在可编程只读存储器(PROM)中，则其允许适当情况下更新所存储的位组合。例如，可能响应于在所存储的位组合中检测的错误或者为了避免对应于所存储的位组合的扩展码的干扰而执行该更新。另一种可能性是，进行更新以(由于商业的或安全的原因)限制可以从卫星存取扩展码的用户组。

因此这里所描述的方法将整个扩展码存储在存储器装置中，例如寄存器，而不是使用线性反馈移位寄存器(LFSR)用于代码产生。这样的存储器装置既存在于卫星负载中用于码的发射，又存在于接收机中用于码的接收。与根据某种数学算法而产生的相对比，所述码从存储器中逐位读出。这允许利用任何形式的码-尤其是，所述码无需是Gold码、部分Gold码、短循环Gold码或者这些码的组合中的一部分。可以为了所需的性质积极地优化所述码，例如自相关函数(ACF)中的最小旁瓣以及与其它码的最小互相关。最小旁瓣产生更好的捕获性质，例如可以在恶劣的接收条件下更容易地获得信号，例如室内或者在树叶下，而与其它码的最小互相关减小多址干扰和系统内噪声，从而增加信号捕获、跟踪、和数据解调的鲁棒性。此外，可以将码构造为始终是完全均衡的，并且ACF的第一旁瓣固定为零。这个后者性质意味着在-Tc到Tc区域内ACF的形状始终相同(其中Tc表示码中码片或位的长度)。所提供的码兼容于具有等级结构的码的使用，即基于初次和二次码。例如，根据本发明一个实施例提供的码可以用作等级码的初次码，从而在保持良好相关性质的情况下提供快速捕获。

由于通常不需定制硬件(例如存储器装置)来提供码(不同于特定的LFSR)，这里所描述的方法允许将扩展码最终形式的决定延迟到系统开发的很晚期的阶段。而且，该存储器可以通过将新的码加载到存储器来容许轨道中的卫星广播新的扩展码。这可以有益于在实现或者试运转的最后阶段进行码的在轨测试，或者如果需要则发射不同于原先计划的码，例如由于与其它服务发生干扰或者由于已经重新分配特定的轨迹。此外，码的修改还可能有益于商业目的，如果可能需要许可支付以获得新的码，或者安全原因，以将定位服务的获取限制到拥有新的码的那些用户。

应当指出，尽管这里描述的方法主要针对卫星导航系统(包括伪卫星)的使用，其同样可以运用于其它以前使用LFSR来产生同步码以及诸如此类的导航或通信系统(卫星的、陆地的或海上的)。

下面将仅通过例子的形式详细地描述本发明的各种实施例，参考以下附图 图1是根据本发明一个实施例的产生码组的方法的高等级流程图； 图2是高等级流程图，更加详细地显示了图1所示根据本发明一个实施例的方法的初始化过程； 图3是高等级流程图，更加详细地显示了图1所示根据本发明一个实施例的方法的优化过程； 图4显示了代价函数的减小，根据本发明一个实施例对第一个码组进行优化； 图5显示了GPS码组的奇和偶相关值； 图6显示了图4中优化产生的码组的奇和偶相关值； 图7是根据本发明一个实施例的卫星系统的高等级示意性结构图； 图8是根据本发明一个实施例的接收机系统的高等级示意性结构图； 图9显示了代价函数的减小，根据本发明一个实施例对第二个码组进行优化； 图10显示了图9中优化产生的第二码组的相关值的改善； 图11显示了代价函数的减小，根据本发明一个实施例对第三个码组进行优化； 图12显示了图11中优化产生的第二码组的相关值的改善。

具体实施例方式 现有的寻找扩展码的技术基于数学算法产生的码，与其对比，本发明的方法使用的扩展码不依附于任何特殊形式的数学结构。而是，允许扩展码具有任意的位序列，并且试图基于一个或多个客观标准确定使用的最优化的扩展码组。

应当指出，对于卫星导航系统中通常使用的长度(比方说1000位或者更多)的扩展码，可能的码的数量是非常巨大的(一旦消除关于数学结构的约束)。例如，对于长度N位的码周期，均衡位序列的总数量可以表示为 (等式1) 其对于N＝16384位，对应于～104930(远大于长度16384位的8192个Gold码)。可能均衡码的这个非常巨大的数量意味着，全部可能码组的穷举检验在计算上是不可行的。而是，本发明的方法采用一些形式的优化程序，如下面将要更加详细地描述的。

在给定码组中包含的码的数量取决于卫星导航系统的特定需求。这样的系统通常被设计为使用大约24-30个不同卫星进行操作，加上通常存在的可能的备用以防万一的故障情况。码组中所期望的码的数量可能进一步增加，以提供“伪卫星”(pseudolite)信号。这些是自地面位置发射的信号，例如机场附近，其对于接收机来说类似额外的卫星导航信号，因此在这样的位置可以提供更加精确和可信的定位。此外，可能希望以规则的标准改变卫星广播的扩展码组。这对于安全和商业原因是有用的，例如新码的获取基于支付许可费的条件的情况，或者新码的获取限制在特定的政府或军事用户组的情况。

图1是根据本发明一个实施例用于产生码组的方法的高等级流程图。方法开始于产生位组合的初始组(105)。每个位组合代表一个潜在的由卫星使用的扩展码。然后根据优化过程修改位组合(110)。然后，优化过程结束时保留的位组合的组表示由卫星使用的码组(115)。

图2是高等级流程图，更详细地显示根据本发明一个实施例用于产生位组合的初始组的方法(对应于图1中的操作101)。该方法开始于产生用于初始码组的随机位组合组(205)。在一个特定实施方案中，产生的用于初始组的位组合的数量与最终所需的扩展码的数量一致。然而如下面将要讨论的，其它的实现可能采用较大的位组合的起始组。应当指出，因为位组合的产生基于随机原则而不是使用某些特殊的数学算法(例如对于Gold码)，位组合可以是任意长度的。因此这个长度可以根据卫星系统的特定运行需要(例如捕获时间、位置精度)进行选择，而不是由所选的码格式规定。

在一个特定实现中，通过为(伪)随机数字发生器提供种子(seed)来产生初始位组合。用于产生每个位序列的种子被写入记录文件(log-file)，从而如果需要可以确定性地重复这个过程。这个实现还允许从文件加载初始码组(而不是基于随机规则产生)。这在使用前次搜索结果作为起始点开始新搜索的情况下是便利的。

现在图2的程序进行到，确定是否有任何可以利用到码组的前导条件(precursor condition)(210)，如果有则确定这些前导条件是否满足(215)。如果有不满足的前导条件，那么在开始主优化过程之前可以修改位组合以保证满足前导条件(220)。

在一个特定实施例中，施加两个前导条件到初始位组合。第一个是，码是均衡的，换句话说，码中有相等数量的1和0。假设A等于位组合中0的数量而B等于1的数量，因此操作215的测试确定是否A＝B。如果是，那么操作215具有正的结果，并且(关于这个特定前导条件)不需要进一步的操作。另一方面，如果在操作215发现A>B，那么在操作220中从位组合中随机选择(A-B)个零并从0翻转到1，从而产生均衡码。相反，如果对于初始随机位组合B>A，那么在操作220从位组合中随机选择(B-A)个一并从1翻转到0，同样产生均衡码。

施加到初始位组合的第二个前导条件是，自相关函数(ACF)的第一旁瓣(即对应于一个位置的位移位)对于每个位组合都是零。这是有用的性质，因为其保证ACF在邻近零偏移处具有已知的(固定的)状态，这和接收机的S曲线有关联。例如，真实(原始)ACF从零偏移处的单位一到第一旁瓣处的零的变化事实可以用在特定的多路缓和技术中，其中存在的干扰总量的估计可以基于第一旁瓣中检测到的任一信号的电平。(伽利略系统多路效应的讨论参见Malicorne等人的“Effects

所以为了对每个位组合获得期望的ACF，图2中的操作215对每个位组合确定ACF的第一旁瓣。对于第一旁瓣处ACF为非零的那些位组合，修改该位组合以获得期望的ACF(220)。在一个特定实施方案中，这通过翻转随机选择的“1”和随机选择的“0”直到第一ACF旁瓣为零来实现。应当理解，位以这种方式成对地翻转保证在获得期望的ACF的同时位组合保持均衡。其它实施例可能采用不同的(可能是更结构化的)方法来使第一ACF旁瓣为零，替代如上所述的随机选择位进行翻转(虽然在实践中后者的技术性能是令人满意的)。

上面描述的两个前导条件都是“局部的”，它们涉及单独的码而不是取决于多个不同的位组合。因此如图2中所示，便于在初始化阶段对其处理，而先于操作110的优化过程(参见图1)。然而在其它实施例中，可能将上面的一个或多个前导条件结合到优化阶段，作为用于评价码(见后)的代价函数的另一个成分。此外，待施加的前导条件可能随着不同实施例而改变。例如，某些卫星系统可能不需要均衡的扩展码或者在第一ACF旁瓣处为零。在某些实施例中，可能期望限制连续相同数值位的数量的上限(例如，不允许超过比方说L个连续的1或L个连续的0)。然而另一个可能性是对码限定等级结构，从而使其形成于随机产生的初次码和二次码的结合。

图3以高等级显示对应于图1中操作110的优化过程。在高等级中，该过程包括对于当前位组合计算代价函数(305)和确定是否已经满足终止或者收敛条件(310)。如果是则优化已经完成，如果否则更新至少一个码组合(315)并且返回操作305对更新的位组合的组计算代价函数。

在一个实现中，基于奇和偶的自/互相关函数确定代价函数，其分别定义如下 以及(等式2) 其中a和b是码序列、k是偏移、N是码中位的数量、σ是符号函数，即对于n<0有σ(n)＝-1；对于n≥0有σ(n)＝+1。如果a＝b，则获得自相关函数。(应当指出，这些公式假设码组合被表示为循环序列，每个码片恰当地描述为+1和-1；所获得的相关值没有被标准化到-1到+1的范围。) 偶数ACF和CCF对应于可能认为是常规的ACF和CCF。奇数ACF和CCF反映出码组合的连续循环在极性上翻转的可能性。这种极性翻转的一个原因可能是，如上所述位组合形成等级码的初次码，因此根据二次码发生翻转。另一个原因可能是，翻转由于将扩展码和导航数据多路复用在相同的信道上造成。对码组中的每一个位序列、对于每一个可能的移位值，确定奇数ACF和偶数ACF。对码组中每一对位序列、并且对于在一对中的两个位序列之间的每一个可能的移位值，确定偶数CCF和奇数CCF。

在一个实施方案中，所有相关函数使用简明的时域方法进行求值(而不是转换到频率或傅立叶域)。如下面更加详细的描述，这种计算所用的时间并不重要，因为仅对代价函数的首次计算进行CCF和ACF的完整求值，而在优化过程的后续阶段不进行。

从如上计算的奇数和偶数ACF/CCF可能产生多种代价函数。一种可能的代价函数基于两个不同位组合之间的最大CCF峰值，可以表示为 (等式3) 这里a和b表示不同的码，k表示两个码之间的偏移，而o和e表示奇数和偶数形式的相关函数。M的值经常用于前述项目作为衡量标准以评价码组，并且给出有多大的可能将来自一个卫星的扩展码误认作来自另一个卫星的扩展码的指示。然而，这个衡量标准的一个不足在于它没有考虑最大相关值出现多少次。例如，如果对于一对码组合和单个移位，给定的峰值仅出现一次，那么这可能比对于多对码组合和在多个移位处出现相同的峰值更加可接受，因为后者情况下接收机处发生错误识别的可能性要大的多。

此外，单独基于M值的优化过程的收敛特性相对较差。从而由于最大CCF峰值仅取决于一个值，当优化算法收敛时，码的位中的随机改变不太可能导致代价下降。如果具有相同最大值的多个峰值，这个问题甚至将更加显著。

另一个可能的代价函数是所有互相关峰绝对值n次方的总和 (等式4) 其中实践检验显示，幂数n的适当数值包括2和6。这比仅使用取决于更多个数值(实际上是每一个单一的可能相关值)的互相关峰值(M)更具有优势，从而通常展现出较好的收敛特性。

关于代价函数的另一个可能源于Welch界，其在文献中定义为 (等式5) 其中M是序列的数量，而N是序列的长度。Welch界可以用于确定Welch过剩标准，其由下式定义 (等式6) 这主要是所有在Welch界之上的ACF和CCF峰值(包括偶数和奇数)的总和(那些在Welch界之下的被排除在总和之外)。尤其是，每个峰值都减去Welch界并且余数取n次方，其中n是可配置的并且来源经验的适当的数值包括2、6或者8。Wen代价函数将低水平的相关值从优化过程排除，所以可以看作是使用Sn和M作为代价函数之间的折衷，Sn包括所有的相关值而M仅包括峰值相关值。

应当理解，虽然Wen、M和Sn表示操作305中使用的可能的代价函数(并且已经发现Wen尤其适合)，其它的实现方式可能使用其它的代价函数或者代价函数的组合。所选择的每个代价函数将以不同的方式导向不同的码。一种选择可能认为如果最大旁瓣小则码质量好，而另一种选择可能认为如果所有旁瓣的总和小则码质量好。还可能是多于一个的代价函数的组合(例如需要最大旁瓣和旁瓣总和都小)。代价函数可能基于相关函数和/或某些其它衡量标准。例如，具有接近均衡的码可以作为优化所用的代价函数的一个部分而被包含，而不是作为初始条件被施加。同样，取决于使用的信号结构，可能对奇相关函数不感兴趣(尤其是当始终保持扩展码的相同极性时)。

还应当理解，所选择的代价函数可能并不完全符合用于确定最终码组的最后选择标准。这是因为通常选择代价函数以提供良好的收敛，并且这通常可以通过使代价函数基于CCF峰值的具有相当数量的一个部分来获得，即便最终的评价标准可能仅基于单个CCF峰值。

在当前的实施方案中，代价函数仅在零多普勒条件计算互相关函数(即，忽略信号中来自卫星位置移动的任何可能的多普勒频移)。这一问题的主要原因是经验观察到的现象，码组具有互相关峰值的近似高斯分布，其中观察到平均起来CCF峰值的柱状图对于非零多普勒条件趋向于朝零偏移。(应当指出与此相比，Gold码具有高程度的互相关峰值非高斯分布，并且因此非零多普勒条件的效应对于这种码可能更加显著。) 可以根据多种衡量标准确定在操作310中何时结束优化过程，例如由于尝试的总次数(即贯穿图3中处理循环的次数)已经达到某个预设的界限，或者由于代价函数已经达到某个可接受的低等级。另一种可能性是优化程序已经收敛于某个代价函数极小值。应当理解，如图3所示优化程序中的一个普遍问题是，代价函数停滞于局部最小值并且在采用小步长时无法摆脱。然而在本申请中，代价函数处于非常高的尺寸空间(每个位组合中许多个位、和许多个位组合)。因此，对于任何局部最小值很可能具有摆脱办法，因为大数值尺寸通过为码组合选择不同的更新来提供很多探测的方向。

如果操作310的结果为负，在此优化过程继续，然后更新码组合(315)(后面再讨论操作312和314)。在一个实施例中，这通过将码中一定数量的位随机翻转获得。需翻转的位的数量可能取决于码已有的表现(即代价函数值如何低)。通常，码表现越好、代价函数越低，需翻转的位的数量可能减小。从而，允许当距离代价函数的最小值相对较远时进行粗搜索，而随着接近最小值进行优化空间的精细搜索。

在一个实施方案中，待修改的码组合的识别可能被随机选择。作为替代，可能以某个特定的理由选择待修改的码组合。例如，相比其它的码可能优先选择产生(任何一个)最大相关峰值的一对码用于更新。

在一个特定实施例中，在操作312中进行检验以确认在操作315中位的变化导致代价函数的改善(即减小)。如果发现情况并非如此，则恢复这些位到先前的位置(操作314)，换句话说操作315的更新被反转，并且选择新的位对用于在下次更新中翻转(操作315)。应当理解，检验312和操作314的存在保证优化过程不反向进行，即朝着代价函数增大而不是减小的方向。

优化过程可能受支配于特定的前导条件而执行，在一个实施例中，该前导条件为码是均衡的并且在第一ACF旁瓣处具有零值(如前面和图2相关进行的讨论)。一旦建立了前导条件(如果存在)，就可以选择在操作315中更新码组合的方法，从而保持这些特性不变。在一种实现方式中，通过如下方式完成 均衡不变性在每个码中，通过选择一个值为0的位和一个值为1的位进行翻转，位通常成对地翻转。这保证码以均衡性不改变的方式修改，从而码的均衡性在位的翻转前和翻转后保持相同。因此，如果码在初始化时(如在操作220)是均衡的，则它们在整个优化程序始终保持均衡。

ACF旁瓣不变性假设选择翻转的位是aJ和ak，由于均衡不变性而意味着ak＝-aj，则容易证明，ACF函数的第一旁瓣不变的条件是 ak-1+ak+1＝aj-1+aj+1(等式7) 如果这个等式没有保持，则必须选择新的位aj和ak进行翻转以保持第一ACF旁瓣的零值。更一般地，如果在初始化中(见图2)已经将码构造为ACF的第n个旁瓣为零，则这个特性可以通过保证下式来保持 ak-n+ak+n＝aJ-n+aJ+n(等式8) 从而，可以控制操作315的码更新以保证ACF的中心部分(即零偏移附近)对于所有的码保持相同的形状。

可以恰当地实施其它的前导或者不变条件。例如，可以对位组合序列中任何单一位(1或0)的最大游程设置界限。另一种可能是，码具有等级结构。在这种情况下，更新操作315可能包含码的初次部分和/或二次部分的独立修改，并且由(修改的)初次和二次码产生新的(全部长度的)码组合。

作为前导条件或者作为优化程序一部分可以应用的进一步衡量标准反映出，伽利略系统将展示类似于GPS L5中相干载波的导频信号。在GPS L5中，这是通过(在I和Q信道)发射两个正交的信号实现的。在这样的情况下，重要的是不仅通过载波的正交性、而且还通过码自身分离信号，换句话说用于I和Q信道的码对于零延迟具有尽可能小的互相关(应当理解，这两个信道之间的时间延迟是固定的)。这里描述的优化程序允许促使两个这种覆盖信道对于精确零延迟的互相关接近于(或强制为)零，即-∞dB(对照GPS L5码的大约-60到-70dB)。应当理解，一种修改两个码之间的CCF的方式为将一个码的起点相对于另一个码进行移位(使用码的循环特性)，而不是修改其中某个码的位顺序。

应当指出，在操作315更新码组合之后，如果在每次反复中仅有很少数量的位发生翻转则不需要完整地重新计算ACF和CCF以更新代价函数。而是，如果码中具有相反符号的两个位(为了保持均衡)发生翻转，比方说aJ和ak，偶互相关函数的变化由下式给出 (等式9) 其中n是码a和b之间的偏移。然后可以应用这个更新到已经计算的CCF。类似地，对于奇CCF有 (等式10) 其同样可以用于更新前次计算的奇CCF数值。

上面的程序描述一种优化程度，但应当理解可以获得很多作为替代的基于例如遗传算法、模拟退火等原理的策略。例如一种更新操作315的可能性是不依靠对随机选择的码进行随机修改，利用一种算法进行更加具有指导性的尝试以减小代价函数。这可以通过选择产生高相关值的一个码或一对码、并且选择修改这些码中对高相关值贡献大的特定位来达到。另一种可能性是，在两个或多个不同码之间(例如在遗传或基于进化的算法的育种阶段)交换局部位序列。应当理解，一些实现可能对于操作315利用随机的、导向的和/或交换的修改的某种组合，或者对于不同的优化循环执行不同类型的更新。

应当指出，在上面描述的程序中，产生用于初始码组的位组合的数量对应于最终码组中位组合的数量(即，通过已经存在于码组中的个别位的修改，后者来源于前者)。其它的优化程序可以包含比最终组所需的大的多的位组合。例如，如果在最终组中有N个码组合，那么最初可能产生具有P个码组合的组(P>N)。每个优化循环可以保留具有(比方说)N个码组合的最佳子集，然后产生另外的P-N个新码组合与前次循环保留的子集一起用于测试。某些优化策略可能将这种大数量方法和在总数中更新各个码组合相结合。

采用大数量的码的一种动机是，如果这N个码组合已经在卫星上使用，并且希望鉴别可以在替换卫星上(或者在相关的基于地面的服务上)使用的附加的兼容码组合。应当指出，N个初始码组合可能通过图1所示的不同机制而产生(例如是Gold码)，但对于当前方法来说显而易见，这些码和任何现存的码组相兼容。

到目前为止已经假设，在码组中对于码组合具有预定的长度。然而，所采用的码组合的长度可以有一定灵活性。在这种情况下，可以重复优化程序使用不同长度的码组以鉴别提供具有特殊有利性质(即，和基于不同长度的码组合相比具有较低的代价函数)的码组。

对于具有非常短的位长度的码组合，执行所有可能码组合的穷举搜索在计算上是可行的。然而，当今的计算资源对于具有卫星导航信号通常所采用的长度的码组合是不可接受的(这根据上面的等式1是显而易见的)，在这些情况下必须使用优化程序。

图4的图表显示，图1所示的根据本发明一个特定实施例的码产生程序的进展。这个例子包含20个码，每个码长度为1023位。码的初始位序列是随机产生的，然后对码进行优化，如图所示沿X轴为尝试次数(即码更新的次数)。图表绘出了作为尝试次数函数的四条曲线。其中的三条曲线在图4中彼此重叠，因而不易进行区分。这些代表使用Welch界、即类似于上面等式6的代价函数Wen计算的代价函数值。对于这个特定的例子，代价函数确定为所有相关值的8次(即n＝8)大于Welch界的1.8倍(而不是等式6所示的1.0倍Welch界)。由Welch界计算的三条曲线对应于(a)偶相关函数、(b)奇相关函数、以及(c)奇和偶相关函数的组合。可以看出，源于偶相关函数和奇相关函数的曲线轨迹彼此接近(因而组合曲线也如此)，其间没有重大差别。

图4中的第四条曲线代表最高或者峰值相关值，类似于上面等式3的数值M。应当指出，这条线形式上为矩形，并且明显地量化为特定数值。此外，这条曲线的值在越过相当数量尝试次数的某些阶段上是常数。这保证和等式3的(或其类似的)M数值相比，使用等式6的Wen的平滑曲线通常表现出好的多的数值收敛性或者优化过程。

然而如前面提到的，由于对于任何错误辨识确定了最坏情况，M的数值对于评价码组常是最终感兴趣的。在图4中，Y轴的刻度指示M(不是W)的数值。M的初始值是149，而最后的优化值是93。这些是没有标准化的数字，对于1023的码长相当于16.7dB的初始值和20.8dB的优化值(和对于零偏移、即适当同步的信号的自相关峰值相比)。

图5是相关值(绝对值)的柱状图，对应于GPS使用的20个码、每个码长度1023的组。图5的X轴表示相关值(刻度可以直接和图4的Y轴相比较)，而Y轴表示码和具有此相关值的偏移的组合的数量。相关值被分为奇相关和偶相关。偶相关包括在“1”位置上的非常大的峰值，以及63和65处的两个较小峰值。对于GPS的Gold码，这些相关性质是众所周知的(例如见上面提及的Misra和Enge所作书的7.6节)。65处的峰值对应于低于零偏移的自相关峰值的数值24dB。

图5所示柱状图中其余的条柱代表对于GPS的Gold码的奇相关值。这些值的分布和偶相关值差异很大，分布在很宽的值范围上。对于GPS码，最坏奇相关值是153，对应于16.5dB，尽管这个相关值比其它值显著恶化(对于GPS码的第二最坏奇相关值是133，对应于17.6dB)。

图6是类似于图5的柱状图，显示图4所示优化产生的码组相关值。图6对于奇函数和偶函数、以及对于优化前和优化后分别绘制相关值。由于这些不同组本身不容易分辨，对该主转图添加了画线，该画线结束于相关值93处。这代表优化后相关值的柱状图的上边界，而优化前数值显著超出该边界达到149的上端数值(和图4的图表相一致)。

因此优化过程产生初始状态和最终状态之间超过4dB的改善，其在统计原理上对应于多于两倍的码长。虽然优化后的码对于偶CCF的表现仍然在Gold码以下，实际的差别在某种程度上小于图5和6所显示的。这是因为在实践中发现，例如图6所示的高斯柱状图对于非零多普勒倾向于左移，反映出相关值的下降。与此相反，如图5中的63和65所示对于偶Gold码，顶点倾向于变得模糊。这将导致与这些峰值有关的峰值相关值增大。

来自图6的优化码此外对于奇CCF的表现通常好于Gold码对于奇CCF的表现(其通常相当于图6中的初始状态)。应当指出在GPS中，叠加到扩展码上的数据速率相对较低，从而码之间发生位翻转的可能性仅有0.5/20或者说2.5％。所以GPS中奇CCF的表现并不重要。与此相反在伽利略中，叠加到扩展码上的数据速率相对较高，从而码间发生位翻转的可能性是0.5(50％)。应当理解，在这样的情况下对奇CCF的表现就成为非常重要的因素。

此外在某些情况下，为了具有特定长度的码，可能希望使用截断的Gold码而非完整的Gold码。已经发现，这种截断的Gold码的表现类似于图6中的初始码组，因而显著差于图6中优化码组的表现。

图7是根据本发明一个实施例、用于卫星有效负荷的发射系统601的高等级示意结构图。(应当理解，类似结构还可以用在伪卫星或其它这样的仿效卫星的装置。)发射系统601利用扩展码611，例如使用图1所示的方法产生。扩展码611存储在存储装置610中，其在正常广播活动中作为只读存储器。在一种实现方案中，存储装置610可能在逻辑角度上运行为环形缓冲器，使用读指针围绕存储的码序列611循环(这可能比传统的LFSR设计更容易实现，LFSR对于每个输出位需要多个读-写操作)。

在典型的卫星导航系统中，码611的长度达到1000到10000位，虽然在适当情况下可以使用更长或更短的码。应当指出在某些情况下，码611包括等级结构的码，在此情况下存储装置610可能被分为两个组件，一个用于存储初次码而另一个用于存储二次码。在这种情况下，发射系统601还可能包含适当的逻辑，用于由存储的初次码和二次码产生完整的码。作为替代，即使码611具有等级结构，其仍可以在存储器610中存储为一个单个的长序列。在存储器中具有这样的平坦结构是有益的，例如可能希望用某种不同的码代替存储器610中的码611(参见后面)。

现代存储器的特征尺寸非常小。因此存储器610中存储的位可能容易受到宇宙射线撞击(尤其在空间环境中)和其它可能污染的损坏。因此在一个实施例中，存储器装置610的输出经过差错检验码(ECC)单元612以保护码611的准确性。ECC单元612能够在从存储器610中读出码611时探测码611中的错误，并且在某些情况下能够自动校正错误(取决于码和错误的性质)。例如，存储器610可以存储码611的两份拷贝，并且从两份拷贝同步地读取每个位。如果从不同版本读出的两个位不一致，将表示在一个存储版本中存在(即检测到)错误。如果在存储器610中存储有码611的三份拷贝，那么基于多数表决可以自动校正任何检测到的错误。

本领域技术人员应当知道很多来自数据通信和数据存储应用的ECC机制，例如使用卷积编码、循环冗余码(CRC)等等。这些通常比简单存储码611的多份拷贝高效的多，即它们在额外存储能力方面以较低的开销提供更好的防错保护。

存储器610对于存储码611的完整长度通常足够长。换句话说，如果码611具有(例如)1023码片的长度，那么存储器610具有至少1023位的存储能力以按位存储整个码(加上用于任何冗余或ECC功能的额外存储)。这是因为，如果码611表示任意随机序列，那么通常无法将其压缩存储在存储器610中。这区别于使用Gold码(或某些由其派生的码)的现有系统，其不需要存储整个扩展码而是可以在需要时使用LFSR产生扩展码。

在码经过ECC检验612之后，通过信道产生子系统620与导航数据617相结合。这一结合通常使用某种形式的模2加法(异或)进行。然后产生的信道转到调制单元625，在这里使用某些适当的调制机制叠加到载波信号上，例如二进制相移键控(BPSK)。应当指出，在一些卫星系统中，可能将多个信道调制到单个载波信号上。然后这个载波信号转到发射器630以向地球广播。

虽然在理论上，码611可能是在发射前“硬件有线连接”于存储器610中，如果存储器装置610包含写能力则将是十分灵活的，即其实现为某种可编程只读存储器(PROM)。例如，如果ECC检验612确实发现存储的码611已经破坏，则存储器装置610的写能力允许将码的正确版本写回到存储器装置610(码的正确版本可能获得于ECC单元612自身，或者可能必须由地面控制系统提供)。还存在多种需要更新存储在存储器610中的码611的其它原因。例如，如果原来的码与某种其它服务或者卫星发生干扰，则可能安装新的码以帮助改善检测相位过程的表现。还可能是商业的或安全的原因而改变码611，前者可能是为了提高许可费收入，后者将定位信号的存取限制到适当授权的人员。

应当理解，这种改变卫星发射扩展码的灵活性在很多现存系统中是不存在的，因为这样的系统常常结合硬件实现的LFSR以产生特定Gold码。这样的现存系统可能将扩展码加密以控制扩展码的存取(无论是商业的或军事的原因)，但这种加密将影响接收机的性能以及复杂性。

图8是根据本发明一个实施例的接收机701的高等级示结构图。操作中，接收机701包含天线715，用于接收例如由卫星601发射的卫星信号。天线715连接到解调器720，其接着传输输入的解调信号到信道捕获单元725。

接收机701还包含存储器装置710，其存储接收机701支持的卫星星座的码组合611A、611B...611N。存储器装置710通常存储码611A、611B等的完整位组合，如前面所提到的，在缺少任何形式化的数学结构的情况下对这些码更紧凑的表示通常不可能存在。

存储器装置710可能被提供为只读存储器(ROM)，或者其可能具有某种更新能力，例如实现为可编程只读存储器(PROM)。后者在码611A、611B、...611N为商业或安全原因而更新的情况下尤其适合。应当指出，在某些情况下，存储器710可能代表某种形式的可移动存储介质，可以插入接收机701以及从其中移出。例如，存储器装置710可能包括智能卡(类似于手机中的SIM)或者闪存存储器装置。这因而允许通过置换可移动存储器装置更新接收机701中的码611。进一步的可能性是，装置710可能能够通过某种商业网络从远程系统(例如服务器)下载码以存储在本地RAM中并且进行利用，例如通过互联网或者移动电话连接。这种下载可能经过用户的适当授权，以便因商业、安全或法律原因而限制卫星导航系统的使用。

在某些实现方式中，存储器710的输出经过ECC单元712以执行错误检验和/或校正，如上面关于卫星系统601所描述的，尽管在其它接收机中可能省略ECC检验机制712。然后码611被提供到信道捕获单元725，从而可以从解调信号捕获信道。应当指出，这种捕获的执行可能依次尝试一个码611A、然后另一个码611B等等。作为替代，可能将多个码(可能是其全部)并行地与解调信号进行相关。一旦接收机已经通过识别特定扩展码611A、611B的存在而锁定到输入信号，则可以取出信号中的导航数据并由位置确定单元使用，结合对接收的扩展码的定时以帮助计算接收机的位置。

在很多实施例中，接收机701可能能够接收来自多于一个的卫星导航系统的信号，例如从伽利略并且从GPS。虽然GPS的扩展码包括可以实现为LFSR的Gold码，应当理解这样的码也可以完全存储在存储器装置710中。因此，存储器710的单一结构兼容特定的或定制的码组合，例如使用图1的方法产生的以及源于LFSR的传统码组合。

表1展示了用于伽利略E6-B和E6-C信道的初次码，而表2展示了用于伽利略L1-B和L1-C信道的初次码(参见上面提及的Hein等人的论文，以获得关于不同伽利略信道的更多信息)。操作中，将E6-C码和100码片的二次码结合，而将L1-C和25码片的二次码结合(对于E6-B或L1-B信道没有二次码)。

表1的码组包括100个码，其覆盖可以使用的卫星(通常为24-30个)星座，加上任何可置换的任务、可能的伪卫星等等，而表2的码组包括137个码(提供额外的码用于在需要的情况下使用的另一个兼容卫星导航系统)。每个E6-B和E6-C码具有5115位的长度，而每个L1-B和L1-C码具有4092位的长度。这些码长度确定为提供相关导航数据所需的位速率，加上选择码片速率使其是GPS卫星所用码片速率的整数倍(这有助于GPS和伽利略系统之间的兼容性)。

使用基数64来表示码-即每6位组织在一起并且由依照下面表3的单个符号来表示。在表1和2的列表已经进行了填充以完成基数64的编码(即，实际的扩展码代表表1的第一个5115位，和表2的第一个4092位)。关于基数64的编码和解码的更多细节可以在rfc1113(参见WWW.faqs.org/rfcs/rfc1113.html)中找到。

将为每个伽利略卫星提供来自表1和表2的E6-B、E6-C、L1-B和L1-C码的其中一个用于广播。与此相反，接收机701通常结合其支持的每个服务的全部码组，尽管在某些情况下可能仅支持服务的所有码中的一个子集，例如仅是分配给已经发射卫星的那些码。还应当理解，接收机通常能够容许其存储的码和接收自卫星的码之间的较小差异。换句话说，存储在接收机中的码可能不精确匹配于表1和2中的码(取决于所支持的服务)，但却是足够接近的以准许相应码的识别以及与其同步。

图9和10显示了E6码(码片)的优化过程，而图11和12显示了L1码(4092码片)的优化过程。图9和11一般地说具有与上面关于图4描述的相同的形式，显示了优化程序产生的代价函数的改善。这些图表的横坐标表示尝试的次数，而纵坐标表示两个不同的代价函数。第一个代价函数基于Welch界，类似于上面等式6给出的，并且对应于图表左侧的刻度。第二个代价函数表示(未标准化的)最大旁瓣值，类似于上面等式3给出的，并且对应于图表右侧的刻度。应当指出，这两个代价函数的计算既使用奇相关函数又使用偶相关函数。

图10和12一般地说具有与上面关于图6描述的相同的形式，显示了优化程序产生的初始码和最终码之间代价函数的改善。尤其是，这两个图表表示初始码组和最终码组(未标准化的)最大旁瓣值的柱状图。在这两个情况中，代价函数的计算既使用奇相关函数又使用偶相关函数。在图10中，添加了一条线以更加清晰地区分初始和最终状态。这条线的虚线部分近似追随初始码组的较低旁瓣数值柱状图的顶部，可以看出其位于最终码组的相应柱状图水平的下面。这条线的点线部分近似追随最终码组的较高旁瓣数值的柱状图的顶部，可以看出其位于初始码组的相应柱状图水平的下面。

从图9、10、11和12可以看出，优化程序导致最终码组相比于初始码组的显著改善。尤其是，初始码组和最终码组之间最大旁瓣数值的改善，对于E6码(5115码片)大约为从410到275(21.9dB到25.4dB)，而对于L1码(4092码片)为从355到245(21.2dB到24.5dB)。

最后，尽管这里详细描述了多种特定的实施例，应当理解这只是作为示例。本领域技术人员将会意识到很多包含在权利要求中的进一步可能的修改和修正及其等价形式。

权利要求 1.一种产生扩展码组的方法，该扩展码组用在包括卫星星座的卫星导航系统中，其中从所述扩展码组中为星座中的每个卫星分配一个扩展码，该方法包括

产生位组合的初始组，其中每个位组合代表一个可能的扩展码；以及

对位组合的初始组执行优化过程，从而修改或替换所述初始组中的至少一些位组合，从而产生位组合的最终组以用作扩展码组。

2.权利要求1所述的方法，其中产生位组合的初始组中的每个位组合作为随机位序列。

3.权利要求2所述的方法，进一步包括在执行优化过程之前先对初始组中的每个随机位序列进行均衡。

4.前面任意一项权利要求所述的方法，其中初始组中的每个位组合是均衡的，并且其中对作为优化过程的一部分所执行的位组合的修改保持了位组合的均衡。

5.前面任意一项权利要求所述的方法，进一步包括在执行优化过程之前对位组合的初始组进行修改，从而使每个位组合的第一自相关旁瓣为零。

6.前面任意一项权利要求所述的方法，其中所述初始组中的每个位组合具有为零的第一自相关旁瓣，并且其中对作为优化过程的一部分所执行的位组合的修改保持第一自相关旁瓣的零值。

7.前面任意一项权利要求所述的方法，其中优化过程尝试使位组合的组的代价函数最小化。

8.权利要求7所述的方法，其中所述代价函数基于位组合的组的自相关值和互相关值。

9.权利要求8所述的方法，其中对位组合之间的全部可能偏移计算所述互相关值。

10.权利要求8或9所述的方法，其中所述代价函数基于位组合的组的奇和偶的自相关值和互相关值。

11.权利要求8到10中任意一项所述的方法，其中所述代价函数基于所有大于预定界限的自相关值和互相关值的总和。

12.权利要求11所述的方法，其中所述预定界限源于Welch界。

13.前面任意一项权利要求所述的方法，进一步包括在优化过程中通过随机翻转至少一个位组合中的位，对位组合进行修改。

14.权利要求13所述的方法，进一步包括如果对位组合的修改导致代价函数的增加则反转该修改。

15.权利要求13或14所述的方法，进一步包括随着代价函数的下降而减小所翻转的位的数量。

16.前面任意一项权利要求所述的方法，其中位组合中位的数量在1000到10000范围内。

17.一种接收机，其结合使用前面任意一项权利要求所述的方法产生的位组合的最终组。

18.权利要求17所述的接收机，其中所述位组合由纠错码保护。

19.权利要求17或18所述的接收机，其中所述位组合存储在只读存储器(ROM)中。

20.权利要求17或18所述的接收机，其中所述位组合存储在可编程只读存储器(PROM)中。

21.权利要求17到21中任意一项所述的接收机，其中所述接收机结合用于至少两种卫星星座的位组合，其中所述卫星星座之一包括GPS。

22.一种用在接收机中的可移动存储器装置，其中所述存储器装置结合有权利要求1到16中任意一项所述的方法产生的位组合的最终组。

23.权利要求22所述的可移动存储器装置，其中所述位组合由纠错码保护。

24.权利要求22或23所述的可移动存储器装置，其中所述可移动存储器装置结合至少两种卫星星座的位组合，其中所述卫星星座之一包括GPS。

25.一种结合至少一个位组合的卫星，所述位组合来自使用权利要求1-16中任何一项所述的方法产生的位组合的最终组。

26.权利要求25所述的卫星，其中所述位组合由纠错码保护。

27.权利要求25或26所述的卫星，其中所述位组合存储在可编程只读存储器(PROM)中。

28.一种结合至少一个位组合的卫星信号，所述位组合来自使用权利要求1-16中任何一项所述的方法产生的位组合的最终组。

29.一种结合如表1或表2所展示的位组合的最终组的接收机。

30.权利要求29所述的接收机，其中所述位组合由纠错码保护。

31.权利要求29或30所述的接收机，其中所述位组合存储在只读存储器(ROM)中。

32.权利要求29或30所述的接收机，其中所述位组合存储在可编程只读存储器(PROM)中。

33.权利要求29到32中任意一项所述的接收机，其中所述接收机结合至少两种卫星星座的位组合，其中所述卫星星座之一包括GPS。

34.一种用在接收机中的可移动存储器装置，其中所述存储器装置结合如表1或表2所展示的位组合的最终组。

35.权利要求34所述的可移动存储器装置，其中所述位组合由纠错码保护。

36.权利要求34或35所述的可移动存储器装置，其中所述可移动存储器装置结合至少两种卫星星座的位组合，其中一所述卫星星座之一包括GPS。

37.一种结合至少一个位组合的卫星，所述位组合来自如表1或表2所展示的位组合的最终组。

38.权利要求37所述的卫星，其中所述位组合由纠错码保护。

39.权利要求37或38所述的卫星，其中所述位组合存储在可编程只读存储器(PROM)中。

40.一种结合至少一个位组合的卫星信号，所述位组合来自如表1或表2所展示的位组合的最终组。

41.一种结合所存储的位组合的组的接收机，所述位组合对应于卫星导航系统使用的扩展码，其中所述接收机使用所存储的位组合来捕获来自卫星导航系统的信号。

42.权利要求41所述的接收机，其中所述位组合由纠错码保护。

43.权利要求41或42所述的接收机，其中所述位组合存储在只读存储器(ROM)中。

44.权利要求41或42所述的接收机，其中所述位组合存储在可编程只读存储器(PROM)中。

45.权利要求41到44中任意一项所述的接收机，其中所述接收机结合至少两种卫星星座的位组合，其中所述卫星星座之一包括GPS。

46.权利要求41到45中任意一项所述的接收机，其中所述所存储的位组合的组包含至少一个如表1或表2所展示的位组合。

47.权利要求46所述的接收机，其中所述所存储的位组合的组包含至少二十个位组合，并且至少二十个位组合如表1或表2中任何一个所展示的。

48.权利要求41到47中任意一项所述的接收机，其中所述位组合是均衡的。

49.权利要求41到48中任意一项所述的接收机，其中所述位组合具有等于零的自相关函数的第一旁瓣。

50.一种用作卫星导航系统的一部分的设备，该设备包含对应于该设备使用的扩展码的至少一个位组合，其中该设备检索该位组合以产生作为卫星导航系统的一部分的结合该扩展码用于发射的信号。

51.权利要求50所述的设备，其中所述位组合由纠错码保护。

52.权利要求50或51所述的设备，其中所述位组合存储在只读存储器(ROM)中。

53.权利要求50到52中任意一项所述的设备，其中所述位组合对应于表1或表2所展示的位组合之一。

54.权利要求50到53中任意一项所述的设备，其中所述位组合是均衡的。

55.权利要求50到54中任意一项所述的设备，其中所述位组合具有等于零的自相关函数的第一旁瓣。

56.权利要求50到55中任意一项所述的设备，其中所述位组合存储在该设备中。

57.权利要求50到56中任意一项所述的设备，其中所述设备包括卫星。

58.权利要求50到56中任意一项所述的设备，其中所述设备包括伪卫星。

59.一种操作结合卫星导航系统使用的接收机的方法，该方法包括

存取所存储的位组合的组，所述位组合对应于卫星导航系统使用的扩展码；以及

使用所存储的位组合来捕获来自卫星导航系统的信号。

60.权利要求59所述的方法，进一步包括使用所存储的位组合执行与来自卫星导航系统的信号有关的定位。

61.权利要求59或60所述的方法，其中所述位组合存储在只读存储器(ROM)中。

62.权利要求59或60所述的方法，其中所述位组合存储在可编程只读存储器(PROM)中。

63.权利要求62所述的方法，进一步包括通过将位组合的新组写入接收机来更新所存储的位组合的组。

64.权利要求59所述的方法，其中接收机通过网络存取所述所存储的位组合。

65.权利要求59到64中任意一项所述的方法，其中所述所存储的位组合对应于来自GPS卫星的码。

66.一种操作构成卫星导航系统一部分的卫星的方法，该方法包括

在卫星中存储至少一个位组合，所述位组合对应于扩展码；

检索该位组合以产生结合该扩展码的信号；以及

67.权利要求66所述的方法，其中所述检索包含对所存储的位组合执行差错检验码(ECC)检验。

68.权利要求66或67所述的方法，其中所述位组合存储在可编程只读存储器(PROM)中。

69.权利要求66到68中任意一项所述的方法，进一步包括更新所存储的位组合。

70.权利要求69所述的方法，其中响应于在所存储的位组合中检测到错误而进行所述更新。

71.权利要求69所述的方法，其中为避免对应于所存储的位组合的扩展码的干扰而进行所述更新。

72.权利要求69所述的方法，其中为限制可以从卫星存取该扩展码的用户组而进行所述更新。

73.一种结合卫星导航系统使用的接收机，该接收机包括

存取所存储的位组合的组的装置，所述位组合对应于卫星导航系统使用的扩展码；以及

使用所存储的位组合来捕获来自卫星导航系统的信号的装置。

74.权利要求73所述的接收机，其中通过网络存取所述所存储的位组合的组。

本发明的一个实施例提供了一种产生用在包括卫星星座的卫星导航系统中的扩展码组的方法。从该扩展码组中为星座中的每个卫星分配一个扩展码。该方法包括产生位组合(105)的初始组，其中每个位组合代表一个可能的扩展码，以及对位组合(101)的初始组执行优化过程。该优化过程修改初始组中的至少一些位组合以产生用作卫星导航系统的扩展码组的位组合的最终组。支持该卫星导航系统的接收机结合位组合的最终组以用于信号捕获和定位。

J·O·温克尔 申请人:欧洲太空署

• 对场景进行设计后，接着需要对负载生成器进行管理和设置。Load Generator是运行脚本的负载引擎，在默认情况下使用本地的负载生成器来运行脚本，但是模拟用户行为也需要消耗一定的系统资源，所以在一台电脑上无法模拟大量的虚拟用户，这个时候可以通过多个Load Generator来完成大规模的性能负载;

  1、添加负载机器之前需要开启代理运行时设置；

  注意：默认选第一项后，在这里点击OK，可能开启不了小雷达，目前在我们实际的工作中已经出现了这样的问题，后来我们找到了解决的方法。开启不了小雷达，我们选择第二项，点击OK，发现会报运行时错误，报错后我们点击报错中的退出，然后进入开始-所有程序-LoadRunner-Advanced Settings,找到Agent Configuration，点击后弹出如下界面，我们勾选第二项后，点击OK，发现小雷达出现了。

  2、设置完成后添加负载机器：

  　　● “New Rule”：在该应用下新建规则，规则中包含字符串或者字符前缀和后缀。

  　　● “Set as Default”：默认情况下，当前所作的更改只适用于当前的脚本，如果想让更改适用于本机所有脚本的话，单击该按钮即可。

  　　● “Import/Export”：利用该按钮可以把定义好的规则导入和导出。

  　　其他的标签设置采用默认值即可，这里不再详细地介绍。

• 1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

  
  2. 查找瓶颈时按以下顺序，由易到难。

  
  服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器瓶颈（参数配置）-〉中间件瓶颈（参数配置，，服务器等）-〉应用瓶颈（语句、数据库设计、业务逻辑、算法等）
      注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

  
  3 分段排除法 很有效分析的信息来源：
  1 根据场景运行过程中的错误提示信息
  2 根据测试结果收集到的监控指标数据

  1．最大并发用户数：应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
  在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
      如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

  
  2．业务操作响应时间：
       分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
      细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
    如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

  3．服务器资源监控指标：

  1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
  bytes计数器的值持续降低，则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆:很高的换页率(high pageout rate);进程进入不活动状态;交换区所有磁盘的活动次数可高;可高的全局系统CPU利用率; 内存不够出错(out

  utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL

  
  1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
  Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 
  3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
  4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

   性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比较复

  杂、需要具备很多相关的专业知识，因此常常会感觉拿到数据不知从何下手。这也是我性能

  测试过程中感觉比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特作了以下笔

  记，这里只是书中第4章WEB应用程序性能分析的一

  部分，贴出来希望和大家共同讨论：

  一：性能分析的基础知识：

  1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS（每秒钟处理的交易数）、点

  2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB服务

  器、数据库服务器、操作系统四个方面。

  3.常规、粗略的性能分析方法：

     当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统

  基本稳定；若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是

  网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。

  4.作者提出了如下的性能分析基本原则，此原则本人十分赞同：

      应用此原则，分析步骤具体可以分为以下三步：

     第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；

     第二步：比较Tn（网络响应时间）和Ts（服务器响应时间）可以确定瓶颈发生在网络还是服

     第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。

  二：以WEB应用程序为例来看下具体的分析方法：

  失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。若失败的事务非常多，则

  说明系统发生了瓶颈或者程序在执行过程中发生了问题。

  测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务

  的最大值、最小值和平均值。通过它可以分析系统的性能走向。若所有事务响应时间基本成一条

  曲线，则说明系统性能基本稳定；否则如果平均事务响应时间逐渐变慢，说明性能有下降趋势，

  造成性能下降的原因有可能是由于内存泄漏导致。

  秒中，每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务

  负载。若随着测试的进展，应用系统在单位时间内通过的事务数目在减少，则说明服务器出现瓶

  每一秒中，通过、失败以及停止的事务总数。若在同等压力下，曲线接近直线，则性能基本趋于

  稳定；若在单位时间内通过的事务总量越来越少，即整体性能下降。原因可能是内存泄漏或者程

  最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求（重点关注事务平均、最大

  该图可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性

  图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发，若可能事务的最大响

  应时间很长，但如果大多数事务具有可接受的响应时间，则系统的性能是符合。

  图显示了测试过程中不同响应时间的事务数量。若系统预先定义了相关事务可以接受的最小和最

  大事务响应时间，则可以使用此图确定系统性能是否在接受范围内。

        分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入

  的分析。没有贴图，看起来有点费劲，如果你对这些图都比较了解，应该是比较简单的.

• 1,把rstatd文件解压到要监控的机器上。

  2,打开终端，定位到rstatd文件夹下：查看文件夹中的内容如下：

  这之后可以执行:make check检查一下。

  命令。启动rpc服务。

  命令。检查rpc服务的状态.

  1,若RPC服务没有成功启动。

  2,若目标主机上开启了防火墙，阻挡了RPC服务。

  在LR中添加时可能会出现如下错误：

• 首先，telnet以root用户的身份登录入系统，在命令行提示符下输入：

  进入编辑文件页面后，输入：

  （命令解释：在打开的文档中查找“rstatd”）接下来继续输入：

  （命令解释：删除当前字符，在这里为删除rstatd命令前的“#”）继续输入：

  （命令解释：保存并退出，注意前面有个冒号）

  
  接着在命令提示符下输入：

  （命令解释：重新启动服务）

  这样使用loadrunner就可以监视AIX系统的性能情况了。

• 在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。  
  　　前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：  
  　　通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：  
  　　看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。  
  　　事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。  
  　　因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角，中国自学编程网， 。  
  　　对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义： “要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )  
  　　面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。  　　因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。  
  　　最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。

• 如何在Loadrunner中监控服务器资源使用情况

  一．监控需要进行的配置：

  在LR控制台设置监控Windows服务器的资源比较容易，直接添加Measurements即可。

  但是大多情况下面服务器的操作系统是Linux或者Unix，这时想监控系统的资源使用情况就需要进行一些设置：

  1．由于LR是通过rpc.rstatd进程获得系统的性能数据，因此首先查看进程中是否存在该进程，或者能否通过运行./rpc.rstatd启动该进程，如果可以，恭喜你，你可以直接在LR的控制台添加

  理论上info为7个进程（前面共有两次start），如果各位有

  兴趣可以自己使用rpcinfo来查看前后的服务对比。

  关于之上的那段Shell程序，偶还灭有研究过。待研究过以后，在放上来与大家一起分享。

  本帖后上传了两个中间文件分别为：

  Average Load:上一分钟同时处于“就绪”状态的平均进程数

  Page-in Rate:每秒钟读入到物理内存中的页数

  Page-out Rate:每秒钟写入页面文件和从物理内存中删除的页数

  Paging Rate:每秒钟读入物理内存或写入页面文件中的页数

  Memory:内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始： 
  MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

  
  page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

  Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

  
  Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 
  

  
  Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

  Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。 
  Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。 
  Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。

  Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。 
  %Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。 
  %User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 
  %Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。 
  % DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

  (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

  %Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘

• 说一下oracle的性能测试。 oracle的性能测试主要是模拟大量的sql语句操作，来对数据库服务器进行加压。在测试前，需要准备以下要模拟的sql语句，测试脚本，并将测试控制机、测试加压机、被测数据库服务器准备妥当。

  将脚本放在控制机上，就可以开始加压了，注意的是，被测数据库服务器的各个参数配置要记录下来，以便修改参数调优时能分析清晰。记录下数据库的iops，time，tps和响应时间，结果汇总出报告。

• 　　一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同，其数据报文的结构也有所不同。协议是有层次的，一般我们从ip层开始，往上有TCP协议层，UDP协议层，而TCP和UDP协议层上又有http协议层，ftp协议层，smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子，本来IP协议的数据报文是无序，不是可靠传输的，在其数据报文外面增加了报文序号，报文状态等数据段就构成了TCP协议层。所以我们很多网络应用，没有找到合适的协议，就用winsock来录制，那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的，而socket正是这一级上的概念。但是由于socket协议级别太低，你录下来的东西是很难理解的，都是 socket，port，data之类的东西。所以，我们尽量用高层协议来录制，我们就能看懂了。

  　　话要再说回来，解决一下具体的问题。我们看到一个软件体系架构，应该怎样选择录制协议呢？说到这里，我要说一下自己对lr录制机理的理解（我没有接触过lr内核，只是凭猜测和推断）。在录制时，lr应该会对你从本机发出去的数据进行截包，并拆包。因为我们知道协议的不同就是体现在数据包的结构不同，lr应该通过对包结构的分析，判断是不是它支持的协议，对包数据的分析，来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作，那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包，都是http协议格式的包，它不认，当然就是一个录制为空的结果了。现在我们弄懂了这个事情，就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的：

  　　1、首先弄清mysql协议和其他数据库协议的关系，看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议，sqlserver也是一样，而mysql又与这几大产品又不是隶属关系，其脚本录制的可能性很小。

  　　2、mysql协议的底层是基于什么协议的，如果直接构建在tcp协议上，lr又不支持mysql协议，那只能考虑用低一点的协议录录看，即socket。如果mysql协议是构建在odbc协议上的，那么就可能用lr的odbc api来写。

  　　很多时候一提到不是基于浏览器的应用，很多人就会想到用WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此，不是所有的程序都是适合WinSocket协议的。实际上，那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以参考录制的结果。所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前，要先和开发人员了解一下他们在开发过程中都用了些什么技术，数据流是用什么协议封装的，还要了解我们要测试的系统的网络结构，服务器的配置等问题；还有就是要知道系统客户端和第一服务器间的协议，这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则（都是自己遇到过的，呵呵，没遇到过的就不知道了）：

  　　1、一般情况下b/s构架的只要 选择WEB（Http/Html)协议就可以了，如果有中间件的则选择中间件服务器的协议 ；

  　　2、C/S结构，可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用；MS SQL Server协议用与测试后台数据库为 SQL Server的应用；

  　　3、一般不是基于浏览器的，对于一些没有数据库的Windows应用，我们在测试的过程中都会选择WinSocket协议来录制，理论上来讲我们这样选择是正确的，但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包，如果我们选择错误了，将会捕获到一些无用的数据包。

  cs结构是比较复杂的，在这里我要提醒大家，一定要搞清楚cs是client-database还是client-server-database结构的，只有这样我们才能够决定是选择WinSocket协议还是sql协议，或者说选择多个协议；当然协议的选择也是一个探索的过程，只要能够得到我们想要的结果，那就是正确的。还有一点，我们在做性能测试的时候应该是有测试重点的，呵呵。

  　　4、关于单协议和双协议，我只知道IE6内核的浏览器在录制脚本的时候要选择单协议，而IE7内核的浏览器在录制脚本的时候要使用双协议。

  　　 　 C/S （第二种）客户端以ODBC方法连接后台数据库 ODBC

• 现在好多网站系统为了防范，恶意访问系统，在登陆口进行限制，使用验证码登陆。

  　　验证码是随机产生的，并且验证码在页面上显示为图片。此时想通过直接获取服务器发送过来的参数，肯定是不可行的。

  　　在进行的时候，有两种办法进行此类系统的测试。

  　　1、将验证码暂时屏蔽，待完成性能测试后，在恢复。验证码屏蔽一定不会给性能测试带来影响，这是肯定的。

  　　2、如果要测试系统是在用的系统，屏蔽验证码会带来不安全因素，不能屏蔽验证码。遇到这个问题当然也有办法解决－－添加一个页面将验证码的输出到页面，然后用loadrunner获取到。

  　　验证码页面（a.jsp）

  在iframe中放入的c.jsp页面就是 获取验证码的页面。 　　这儿加了一个c.jsp 页面链接，主要是用在loadrunner录制脚本的时候，a.jsp 和c.jsp在B页面上加载的顺序不是有序的，因而C.JSP可能获取到的验证码为NULL。 　　在C.JSP页面上 在取得的验证码前后加上两个Q主要为了loadrunner能够捕获到这个验证码做的标记。 //获取C.JSP页面上的验证码 　　运行的时候 要把loadrunner的浏览器给关掉，否则lr的浏览器显示一下，相当于也做了一次请求。