■ 走出误区
深入TPC-C指标
TPC体系是影响最大的评测基准之一，尤其近两年，国内媒体对TPC指标的报道可谓海量。但有多少用户真正了解其中的含义呢？本文以TPC-C为例，让用户深入了解这项基准测试。
tpmC值在国内外被广泛用于衡量服务器系统的事务处理能力。但究竟什么是tpmC值呢笔者曾向一些用户、专业媒体记者乃至某些国外大公司的技术人员问过这个问题，但回答的精确度与tpmC值的流行程度差异甚远。不少人将之误写为TPMC，甚至与TPC组织混为一谈。
TPC(Transactionprocessing Performance Council，事务处理性能委员会)是由数十家会员公司创建的非盈利组织，总部设在美国。TPC的成员主要是计算机软硬件厂家，而非计算机用户，其功能是制定商务应用基准程序的标准规范、性能和价格度量，并管理测试结果的发布。
TPC不给出基准程序的代码，而只给出基准程序的标准规范。任何厂家或其他测试者都可以根据规范，最优地构造出自己的测试系统(测试平台和测试程序)。为保证测试结果的完整性，被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report)，包括被测系统的详细配置、分类价格和包含5年维护费用在内的总价格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。TPC在全球只有不到10名审核员，全部在美国。
TPC推出过11套基准程序，分别是正在使用的TPC-App、TPC-H、TPC-C、TPC-W，过时的TPC-A、TPC-B、TPC-D和TPC-R，以及因为不被业界接受而放弃的TPC-S（Server专门测试基准程序）、TPC-E（大型企业信息服务测试基准程序）和TPC-Client/Server。而目前最为“流行”的TPC-C是在线事务处理(OLTP)的基准程序，于1992年7月完成，后被业界逐渐接受。
TPC-C使用三种性能和价格度量，其中性能由tpmC（transactions per minute，tpm）衡量，C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。TPC-C还经常以系统性能价格比的方式体现，单位是＄/tpmC，即以系统的总价格（单位是美元）/tpmC数值得出。
解读tpmC
从TPC-C的定义不难知道，这套基准程序是用来衡量整个IT系统的性能，而不是评价服务器或某种硬件系统的标准，而且tpmC数值的高低直接受到各个环节的影响，右表大概可以说明系统设置对tpmC测试的影响。此处的“IT系统”包括服务器、外设(如硬盘或RAID)、服务器端 *** 作系统、数据库软件、客户端及其 *** 作系统、数据库软件和网络连接等。因此，如何解读tpmC数值会因不同的采购需求有非常大的差异。以服务器为例。在很多厂家的TPC测试系统中，服务器的价格只是系统总价格的25％或更小，而硬盘的价格有可能占到总价格的30％以上，因为TPC-C要求被测系统必须保存180天的事务记录（这一趋势从一些最新的TPC-C测试结果来看，会愈演愈烈）。如果同样的服务器被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在许多用户还没有意识到这一点。
尤其需要服务器采购用户注意的是，tpmC指标更多的是衡量从Client到终端网络的性能区域（如左图所示），而不是通常误认为的服务器到企业端网络的性能。由此可见，如果用户是建立一套全新的业务系统，那么无妨多借鉴tpmC的性能指标，如果只是采购某种或某些硬件设备，则需要参考更多的指标。
对于tpmC数值着迷的用户而言，一个现实问题是，实现高tpmC指标的代价是否能够承受，毕竟TPC-C都是很复杂的基准程序，做一个严格的测试非常消耗资源，厂商通常不会给TPC报告出全部花费的金钱和时间。
实际上，正因为tpmC（其他评测指标也大都一样）受系统优化影响较大，业界对于是否应该在测试中进行优化向来争议颇多。在1993年, 当时三大IT公司的专家就对OLTP性能测试的优化提出过反对意见——DEC的 Jim Gray (现为TPC-C委员会专家) 与Walt Kohler 、天腾公司（TANDEN）的Charles Levine 和IBM的Steve Kiss共同发表了对OLTP性能测试指标是否应该进行人为优化的看法:
“一个好的性能测试指标是不会依赖于特殊情况下的优化。最理想的情况应该是：一个测试指标在测试过程中所表现出的性质和能力, 以及对测试所做的优化能够确实提供对现实世界中用户实际应用的性能改进。然而，事与愿违，某些厂商迫于标准测试指标所带来的巨大市场压力，他们花费巨大的精力在如何改进测试结果的同时还能降低价格比率，而全然不顾所做的这一切优化究竟是否给用户带来了真实的利益。”
--------------------------------------------------------------------------------
2
--------------------------------------------------------------------------------
相信实践：最佳检验方式
众所周知，成熟的企业从不相信任何“国际通用标准”，而是花相当精力，比如预算的5％，使用自己的应用来测试系统，从而决定选型。“国际通用标准”的度量可以作为参考值，而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义，是在什么样的系统环境中测得的，以及基准程序是否符合企业真实的业务流程和运作模式。
下面就是三种不同的检测模式。
在真实环境中运行实际应用
这是最理想的方式。要求制造商或系统集成商配合将系统(含平台、软件和 *** 作流程)在一个 实际用户点真正试运行一段时间。这样，用户不仅能看到实际性能，也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。
使用用户定义的基准程序
如果第一种方式不可行，用户可以定义一组含有自己实际应用环境特征的应用基准程序。业内有两个典型的例子：其一是，近年来由于3层应用模型的风靡，SAP SD基准获得了众多厂商和用户的认可，于是在很多地方都能看见对SAP测试数据的引用；其二是，国家税务总局曾经开发自己的基准程序，以帮助税务系统进行服务器选型。这种方式在中国尤其重要，因为中国的信息系统有其特殊性。
使用通用基准程序
如果前两种均难实行，那么使用如TPC-C之类的通用基准程序未尝不可。但用户应当尤其注意——实际应用是否与基准程序相符？绝大多数基准程序都是在美国制订的，而中国的企事业单位与美国的运作方式常常不一样，在使用TPC-C时，用户应该清楚地知道：自己的应用是否符合批发商模式事务请求是否与测试模式近似？对响应时间的要求是否那么高？如果都不是，则tpmC值的参考价值就不太大了。那么不妨看看其他的更合适的测试指标，例如SPECweb2005等。 ■ 突出重点
SPEC关注CPU和Web
与TPC体系注重在线处理能力和数据库查询能力不同，SPEC体系中最广为人知的两个子项，是衡量CPU、内存性能的CPU2000和Web服务器性能的web2005。
除了TPC家族，SPEC家族也是广为人知的一大体系。SPEC指标体系由Standard Performance Evaluation Corp制定，目前主要包括针对CPU性能的SPEC CPU2000（已有CPU2006，但尚无数据）、针对Web服务器的SPECweb2005、针对高性能计算的SPEC HPC2002与SPEC MPI2006、针对Java应用的jAppServer2004与JBB2005以及对图形系统、网络和邮件服务器的测试指标。
其中CPU2000和web2005两类是被引用最广泛的指标。
CPU2000 注重CPU
SPEC CPU2000 是一组针对 CPU 和内存的测试，它主要测试的对象是 CPU、内存，不测试硬盘、I/O 效率和网络等部分。SPEC CPU2000 由许多源代码程序组成，这些程序都从实际的应用（主要来自配置1～4颗CPU的工作站应用）中取出来的，例如 164gzip 就是gzip 压缩程序。这些程序区分成“整数”和“浮点数”两组。SPECint2000 就是“整数”部分，而 SPECfp2000 则是“浮点数”部分。“整数”部分有 12 个程序，使用 C 或 C++ 语言，它们不使用CPU的浮点单元；而“浮点数”部分有 14 个程序，使用 FORTRAN 77/90 和C语言，这些程序的主要运算是浮点数的。
SPECint2000 和 SPECfp2000 的结果，以执行时间为准。每个程序的执行时间和一个参考平台（Sun Ultra5/10 300MHz）相比，计算出其倍数。如果执行时间和参考平台相同，结果就是100。如果只花了一半时间完成，结果就是200。“整数”的12 个程序的结果，取其平均值，得到的就是SPECint2000 的测试结果。“浮点数”的 14 个程序也是一样。
由于SPEC CPU2000的测试程序都是源代码形式（以保证跨平台测试），所以编译器效率就显得十分重要。SPEC CPU2000规定，测试结果有“Base”和“Peak”两种结果。“Base”测试中，对于编译时的最佳优化参数有所规定（所有的程序都需使用同样的参数，且参数数目不能超过四个），而“Peak”测试则比较宽松。
另外，因为 SPEC CPU2000的程序都是针对单CPU的系统设计，因此，在多CPU系统上，如果要测试多CPU系统的效率，则是采取同时执行多个相同程序的方法，这个结果就是“Rate”。因此，同样有 SPECint_rate 和 SPECfp_rate 的测试结果。需要说明的是，“Rate”测试同时执行多个相同的程序，但程序之间并不会有关联，所以这是一种理论计算能力测试，并不代表实际并行计算能力。
Web服务 参考Web2005
SPEC web2005测试的原理是，通过多台客户机向服务器发出>
TPC百度百科上的词条是这样说的：
TPC
天的用户在选用平台时面对的是一个缤纷繁杂的世界。用户希望有一种度量标准,能够量化计算机系统的性能，以此作为选型的依据。作者曾在美国从事过数年计算机性能评价工作，深深体会到，计算机的性能很难用一两种度量来 评价，而且，任何度量都有其优缺点，尤其是当使用者对性能度量了解不深时，很容易被引入一些误区，甚至推演出错误的结论。本文以TPC基准程序为例，给出一 些实际建议，以帮助用户避免进入这些误区。
一、什么是TPC和tpmC
tpmC值在国内外被广 泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢作者曾向一些 用户、推销人员乃至某些国外大公司的技术人员问过这个问题，但回答的精确度 与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPM或TPMC。
1、TPC
TPC(Transaction Processing Performance Council，事务处理性能委员会)是由数10家会员公司创建的非盈利组织，总部设在美国。该组织对全世界开放，但迄今为止，绝大多数会员都是美、 日、西欧的大公司。TPC的成员主要是计算机软硬件厂家，而非计算机用户，它的功 能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量，并管理测 试结果的发布。
TPC的出版物是开放 的，可以通过网络获取(>
2、tpmC
TPC已经推出了四套基准程序，被称为TPC－A、TPC－B、TPC－C和TPC－D。其中A和B已经过时，不再使用了。TPC－C是在线事务处理(OLTP)的基准程序，TPC－D是决策支持(Decision Support) 的基准程序。TPC即将推TPC－E，作为大型企业(Enterprise)信息服务的基准程序。
TPC-C模拟一个批发 商的货物管理环境。该批发公司有N个仓库，每个仓库供应10个地区，其中每个地 区为3000名顾客服务。在每个仓库中有10个终端，每一个终端用于一个地区。在运 行时，10×N个终端 *** 作员向公司的数据库发出5类请求。由于一个仓库中不可能 存储公司所有的货物，有一些请求必须发往其它仓库，因此，数据库在逻辑上是 分布的。N是一个可变参数，测试者可以随意改变N，以获得最佳测试效果。
TPC-C使用三种性能 和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是transactions per minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是，在处理新订单的同时，系统还要按表1的要求处理其它4类事务 请求。从表1可以看出，新订单请求不可能超出全部事务请求的45％，因此，当一个 系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。价格是指系 统的总价格，单位是美元，而价格性能比则定义为总价格÷性能，单位是＄/tpmC。
二、如何衡量计算机系统的性能和价格
在系统选型时，我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了“与国际接 轨”而盲目套用“国际通用”的东西。在性能评价领域，越是通用的度量常常越是不准确的。据我所知，美国的一些大用户从不相信任何“国际通用”的度量，而是花相当精力，比如预算的5％，使用自己的应用来测试系统，决定选型。在使用任何一种性能和价格度量时，一定要弄明白该度量的定义，以及它是在什么系统配置和运行环境下得到的，如何解释它的意义等。下面我们由好到差讨论三种方式。
1、在真实环境中运行 实际应用
最理想的方式是搞一个试点，要求制造商或系统集成商配合将系统(含平台、软件和 *** 作流程)在一个 实际用户点真正试运行一段时间。这样，用户不仅能看到实际性能，也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统，这种方式应列为首选，因为它不仅最精确、稳妥，也常常最有效率，用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。
2、使用用户定义的基准程序
如果由于某种原因第一种方式不可行，用户可以定义一组含有自己实际应用环境特征的应用基准程序。 我举两个例子：近年来，由于R/3软件是应用层软件，SAP公司的基准程序获得了越来越多国外企业的认可；中国税务总局最近也开发了自己的基准程序，以帮助税务系统进行计算机选型。这种方式在中国尤其重要，因为中国的信息系统有其特殊性。
3、使用通用基准程序
如果第1种和第2种方式都不行，则使用如TPC-C之类的通用基准程序，这是不得已的一种近似方法。因 此，tpmC值只能用作参考。我们应当注意以下几点：
(1)实际应用是否与基准程序相符
绝大多数基准程序都是在美国制订的，而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPC－C时，我们应该清楚地知道：我的应用是否符合批发商模式事务请求是否与表1近似对响应时间的要求是否满足表1如果都不是，则tpmC值的参考价值就不太大了。
(2)TPC度量的解释
TPC基准程序是用来测系统而不是测主机的，厂家肯定要充分优化他们的被测系统。此处的“系统”包括主机、外设(如硬盘或RAID)、主机端 *** 作系统、数据库软件、客户端计算机及其 *** 作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中，主机的价格只是系统总价格的1/4或更小，而硬盘的价格有可能占到总价格的1/3以上，因为TPC－C要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中，厂家报的tpmC值就意义不大，因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时，tpmC值可能有相当大的变化，现在很多用户还没有意识到这一点。
我举一个例子。假设用 户希望购买一批同类系统，每一系统至少需要1GB的内存和50GB的硬盘。厂家A、B、C 各报了三个价格相当的系统，tpmC值分别为3000、2800、2600。用户是否应该选厂 家A的产品呢答案是：不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好，不 论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。
(3)TPC测试的成本
TPC－C和TPC－D都是很复杂的基准程序，做一个严格的测试是很消耗资源的，厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露，一个厂家做第一个TPC－C测试需 要几十万到上百万美元的资金和半年左右的时间投入。因此，很多TPC的度量值都 是估计的。由于计算机系统换代频繁，如果用户一定要用通过审核的度量值，就必 须多等待半年时间，因此而不能用最先进的系统。中国的厂家通过审核的时间则 更长。
综上所述，我们对中国 用户(尤其是大用户)在计算机系统的选型方面有如下建议：
最好建立一个真实的试点，因为实际应用环境是检验计算机系统的最好标准。
中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心，制定跨行业、符合中国企事业运作模式的性能测试标准。
“国际通用”的度量可以作为参考值，而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义，是在什么样的系统环境中测得的，以及基准程序是否符合企业真实的业务流程和运作模式。
--------------------------------------------------------------------------------------------------------------------------------------------------
作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。
相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。
TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(>
tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。
1．TPC-C规范概要
TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。
TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
该系统需要处理的交易为以下几种：
New-Order：客户输入一笔新的订货交易；
Payment:更新客户账户余额以反映其支付状况;
Delivery:发货(模拟批处理交易);
Order-Status:查询客户最近交易的状态；
Stock-Level:查询仓库库存状况，以便能够及时补货。
对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。
2．评测指标
TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。
TPC-C的测试结果主要有两个指标：
● 流量指标(Throughput，简称tpmC)
按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
流量指标值越大越好！
● 性价比(Price/Performance，简称Price/tpmC)
即测试系统价格（指在美国的报价）与流量指标的比值。
性价比越小越好！
3．结果发布
各厂商的TPC-C测试结果都按TPC组织规定的两种形式发布：测试结果概要(Executive Summary)和详细测试报告(Full Disclosure Report)。测试结果概要中描述了主要的测试指标、测试环境示意图以及完整的系统配置与报价，而详细测试报告中除了包含上述内容外，还详细说明了整个测试环境的设置与测试过程。
P690 tpmC测试值：76,389,83900
$/tpmC：83100
美国美金报价：6,349,2230
CPU数：32
数据库：IBM DB2 UDB 81
*** 作系统：AIX 5L V52
中间件：TUXEDO 80
测试日期：2003630
P690 TPC-C测试的配置：
1． 后台：1 x eServer pSeries 690 with 32 x 17GHz POWER4+ processors with 128MB L3 cache per MCM (total of four MCMs), 512GB memory
2． 前端：30 x eServer pSeries 630 Model 6E4 each with 4 x 10GHz POWER4 CPUs with 32MB L3 cache, 16GB memory
SPECweb:
SPECweb96: 在SPECweb96基准测试程序上实现的每秒钟超文本传输协议（>
SPECweb99: 接入数，网络服务器可用预先确定的工作量支持的同时接入数。SPECweb99检测设备模拟客户通过慢Internet联接，向网络服务器发送>
SPECweb99 测试Web服务器运行状况
SPECweb99 是由标准性能评估组织（SPEC）开发的Web服务器基准测试。它测量满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量。并发连接的合计波特率在320 Kbps到400Kbps范围内，则满足相应规范。
SPECweb99 在一台称为主客户端的机器上运行，这台机器上包含有允许用户加载特定负载请求的配置文件。主客户端也要处理在客户端和服务器或测试中的系统（SUT）之间的传输协调问题。客户端通过许多子进程／线程生成独立>
在这个测试中，客户端向测试中的服务器发送请求数据。测试规范要求客户端和服务器之间的连接不能使用片段大小大于1460比特的TCP协议。因此，每一个客户端读取1460比特或更少数据块的响应。
测试中使用两种类型的负载量：
静态负载 静态负载具有四种类型的文件。最小的文件的增幅为01KB，第二种文件类型的增幅为1KB，最后两种类型的文件的增幅为10KB和100KB。每一个目录包含每种类型9个文件共36个文件。
目标请求的文件类型在各类型中分散使用。在每一类中的9个文件中又进行二次分布。最终目标文件混合为：
35％的请求文件小于1 KB
50％的请求文件小于10 KB
14％的请求文件小于100 KB，但是大于或等于10 KB
1％的请求文件小于1000 KB，但是大于或等于100 KB
动态负载动态负载是基于广告和用户注册。共有四种在SPECweb99中使用的请求内容类型，分别是标准动态取 *** 作、动态随机取 *** 作、动态发送 *** 作和客户图形接口动态取 *** 作。标准动态取 *** 作和客户图形接口动态取 *** 作表现web服务器的简单广告轮转特性。带有广告轮转的动态取 *** 作追踪用户和用户选择，所以广告可以由不同的方式来定制。最终，动态发布实施一个用户注册在相应的网站上。
P690 SPECweb99测试值：21,000
Web服务器：Zeus 40
*** 作系统：AIX 5L V51 (64-bit)
CPU数：16
测试日期：2001-10-1
测试配置：16 x 13GHz POWER-4 Processors w/1440KB unified on chip L2 cache, 192GB memory, 32 x 32 IBM Gigabit Ethernet-SX PCI controllers, 32 x Gigabit Ethernet network (1 Gigabit/sec ), 96 x Clients (4 x 375MHz POWER3-II, RS/6000 44P-270), Requested Connections = 21000, Max Fileset Size = 673196MB
P650 SPECweb99测试值：12,400
Web服务器：Zeus 41r3
*** 作系统：AIX 5L V52 (64-bit)
CPU数：8
测试日期：2002-10-1
测试配置：8 x 145GHz POWER4+ processors w/15MB(I+D) unified on chip L2 cache, 32MB unified off chip/SCM L3 cache, 64GB memory, 8 x Gigabit Ethernet-SX PCI-X controllers, 8 x Gigabit Ethernet network (1 Gigabit/sec ), 48 x Clients (6 x 668MHz RS64-IV, pSeries 620 Model 6F1), Requested Connections = 12400, Max Fileset Size = 3980128MB
p630 SPECweb99测试值：6,895
Web服务器：Zeus 42r1
*** 作系统：AIX 5L V52(64-bit)
CPU数：4
测试日期：2003-2-1
测试配置：4 x 1450MHz POWER4+ Processors w/1536KB(I+D) unified on chip L2 cache, 8MB unified (off chip)/SCM L3 cache, 32GB memory, 4 x Gigabit Ethernet-SX PCI-X controllers, 4 x Gigabit Ethernet networks (1 Gigabit/sec ), 24 x Clients (4 x 375MHz POWER3-II, pSeries 640 Model B80), Requested Connections = 6900, Max Fileset Size = 2219912MB
NotesBench:
NotesBench是测试各种不同Lotus Notes方面的驱动程序。目的是执行自定义工作量教本中的命令，模拟客户机的 *** 作。NotesBench测试“仅测试邮件”和“测试邮件和数据库”。所有已经公布的IBM结果均为“仅测试邮件工作量”。
p680 NotesBench测试值：150,197
用户数：108,000
平均反应时间：0584秒
Domino服务器版本：506a
*** 作系统：AIX 433
CPU数：4
测试日期：20011120
测试配置：IBM eServer pSeries 680 (24RS64 IV/600MHz; 96GB RAM, 30 Partitions)
。pod setup用于初始化本地第三方库的Spec描述文件，所有的spec文件存都存放在~/cocoapods目录中。pod install用来安装或删除Podfile文件声明中的第三方依赖库。下面继续介绍其它一些命令。Shell代码
$ pod list
# 列出所有可用的第三方库
Shell代码
$ pod search query
搜索名称包含query的类库，query可以替换为你想搜索的名字（如json)，不区分大小写。也可以使用pod search --full query命令作更仔细的搜索，该命令不但搜索类库的名称，同时还搜索类库的描述文本，所以搜索速度也相对慢一些。
pod list和pod search命令只搜索存在于本地~/cocoapods文件夹的所有第三方库，并不会连接到远程服务器。如果你要从服务器更新本地第三方库的描述文件，可以:
Shell代码
$ pod repo update master
创建自己项目的Podspec描述文件
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）