160 likes | 491 Vues
RPI The R elative P erformance I ndex What is it?. Mark Simmons, B.Sc(Hons), DIS, MBCS Chief Systems Architect Fujitsu Computer Systems. Contents. Definition of RPI and Standard Benchmarks RPI and OLTP TPM Standard benchmark results Standard benchmark relevance
E N D
RPIThe Relative Performance IndexWhat is it? Mark Simmons, B.Sc(Hons), DIS, MBCS Chief Systems Architect Fujitsu Computer Systems
Contents • Definition of RPI and Standard Benchmarks • RPI and OLTP TPM • Standard benchmark results • Standard benchmark relevance • Benchmark activities in Linux • RPI Load Categorization • Benchmark Profiles • Application Profiles • RPI Values • What is being Benchmarked on a Benchmark • Benchmark Categories • Testing Ranges • Fujitsu’s TPM Number vs. TPC-C • RPI Tool Demonstration • Application Services • AS Tool Demonstration
RPI and Standard Benchmarks • RPI and OLTP TPM are :- • Internal use only • Attempting to level set the server “playing field” • Designed for system positioning and accurate system sizing • First based on estimates, later adjustments are made if necessary • Also provided for competitive/competitors products, though these are harder to verify fully
RPI and Standard Benchmarks • Standard benchmark results are usually for:- • Sales and marketing, and for public awareness • Analysts, press and media • Designed for customer confidence • Values are available on public domain web pages • Underlines validity of internal sizing figures • Referenced under diverse Web Pages such as those at:-http://www.spec.org and http://www.tpc.org • and diverse web pages of the analyst community
Testing Focus SAP SD/ATO/etc Oracle’s OASB APPL SPEC jApps2002 SPECjbb2000 J2EE DB TPC-C TPC-H SPECweb99 OS SPECfp _rate2000 SPECint _rate2000 HW Basic Performance Relevance Commercial Business Relevance Standard Benchmarks - Relevance and test focus
Benchmark Activities of major vendors( >=8 CPU Cores; Jan 03=>Feb04) Quantity
What is being Benchmarked when performing a Benchmark? Testing Range Application and Benchmark Kit Operating system, Compiler, Libraries CPU Cache Memory Multi- CPU Disk- IO DBMS LAN CPU SPEC int/fp 2000 CPUs SPEC int/fp 2000 Rate Java VM SPECjbb2000 Benchmark Category SPECweb99 Webserver OLTP TPC-C DSS TPC-H, TPC-R ERP SAP ERP Oracle Applications
RPI - Load Categorization RPI MEAN RPI CPU RPI TP+I/O Benchmark Profile SPEC TPC-C/H OLTP Application Profile • simple - medium transactions • high number of operations • simple- medium operations • short response time • heavy use of physical I/O no system calls little disk I/O one/few processes well-balanced system load Work Type CPU Centric I/O Centric tpsA SAP tpsB Oracle Apps tpmC SPECint92/95/2000 SPECrate_int92/95/2000 RPI Tool Category to use for sizing
Fujitsu’s Transactions Per MinuteRPI TPM vs. TPC-C / tpmC • Fujitsu‘s measurement for OLTP performance (throughput of transactions per minute) in commercial environments is:- • based on an Oracle 9i(not RAC) database profile • available for all vendors current systems and all configurations • provides similar load characteristics as TPC-C and its tpmC results • is not standardized, other competitors use similar absolutes or relative (e.g. mvalues (Sun) / rPERF (IBM) ) figures and the related database is not defined • TPC’s rules strongly restrict the usage of those proprietary values: • only with signed Non Disclosure Agreement(NDA) • not in public disclosures • no comparisons with published tpmC figures
RPI – The Disadvantage • RPI as a metric is not as easily applicable to the LINUX space as it is in the proprietary Unix space because:- • IA-32 is totally commoditized • There is massive diversity in IA platforms • Plethora of product offerings with very few constants • I/O bandwidth delivery is highly variable • Linux Kernels are generic in nature • Systems running IA32/Linux differ widely in performance delivery • Linux typically degrades faster than other Unix variants in scalability the heavier the load that is placed upon it • Its “Heavy Lifting” capability is not yet mature !
The Solution is an “Application Level Service” • Application Service is an abstract concept of an “Application Unit of Work” that must:- • Concurrently support multiple Linux application processes: • Oracle • SAP • Directory Services • Web Services • Monitor the quality of each application service and automatically adjusts capacity to meet business’s service level goals. • Operate autonomously, with little or no intervention • Make Linux based hard- and software resources shift automatically to meet changing demand. • Allow dynamic capacity scaling – mitigating impact of disparate hardware • Offer users a self-management capability to assist in the administration of dramatically varying environments.
Application Services:Administrative Features • Users must be able to specify application service priorities. • Administrators should be able to change priorities dynamically, redirecting a higher service level toward other applications as business requirements change. • Users must be able to • Set min-max ranges or high/low water marks • Directly influence the number of instances of an application that are available for use. • Users can define Quality of Service (QoS) metrics based upon: • CPU load • Network load. • Application Services must automatically distribute the load using user-selected algorithms. • Provide load balancing algorithms • Balance servers for a given application • Balance across all servers in total.
Application Services:Operational Features • Dynamically provisions servers with the resources necessary to support applications such as: • Dynamically adjusting the number of online application instances. • Meeting defined Quality of Service (QoS) service levels. • Provision applications and operating systems or both • Automatically bring servers online for extra application support • Re-provision servers used by lower-priority applications. • Provision net-new servers that are added to the pool • Takes excess systems offline if service levels are being met. • Reduce license charges (must be negotiated with ISV!) • Leaves offline servers in “warm” state • Reduce the time to re-provision the server for same applications • Reduce the time to re-provision for same operating system
Application Services:Customer Benefits • Lowers total cost of ownership • Server consolidation alone can reduce hardware and software costs • Reduces the need to over-spec server capacity • Improved utilization decreases costs and increases ROI • Improves productivity • Automated solution reduces manual administration • Time spent in training • Correcting human errors. • Load balancing can optimize QoS • Service level monitoring and capacity provisioning to meet needs as workloads change. • Improved application response times • Improves application availability • Continuous availability of application services avoids costly downtime