Experimental Research on Influence of Hardware Infrastructure Sizing on Optimization of PLM System Performance in Auto Industry

Experimental Research on Influence of Hardware Infrastructure Sizing on Optimization of PLM System Performance in Auto Industry

M.S. Gopinatha* Dr. Vishnukanth S. Chatpalli** and Dr. K.S. Sridhar***

*Research Scholar, PES Institute of Technology (VTU), Bangalore, India

Senior Expert Specialist, PLM Competency Centre (Asia Pacific), Siemens PLM Software,

**Advisor, Karnataka Vocational Training & Skill Development Corporation (KVTSDC), Bangalore, India.

***Prof. of Mechanical Engineering, PESIT, 100 feet Ring Road, BSK III stage, Bangalore, India.

ABSTRACT

PLM technology has become the backbone of product design and development for many of the auto companies across the globe. System Performance is the Transaction time as perceived by the end-user – conforming to requirements. Optimized performance of all the IT components of the PLM system will ensure successful product design and development in auto industry. Optimization will generally focus on improving just one or two aspects of performance: execution time, memory usage, disk space, bandwidth, power consumption or some other resource. This will usually require a trade-off – where one factor is optimized at the expense of others.

A typical PLM system in automobile industry consists of the PLM Application server which hosts the PDM system, CAD system, Digital Simulation system, BOM system etc. Database server stores all metadata of PLM system while the bulk data is stored in the file volume server. Web server helps in connecting the PLM Application server with client machines, ERP systems, CRM/SCM systems, legacy systems etc. [Ref. 4 and 5]

An effort is made in this research paper for analysis of the hardware infrastructure component of the PLM system, which greatly influences the optimization of performance [Ref. 6]. This paper provides guidelines for establishing initial server configuration and sizing specifications. This is typically represented as SPECint_rate_base2006 points per concurrent user, for CPU; and MB per concurrent user, for memory. It provides information about each infrastructure resource that may require adjustments to meet unique usage requirements of automobile companies.

Experimental research is conducted to find out information about the types of computing resource required for a specific sample usage profile using the test labs of Siemens PLM Software. The main objective of this experimental research is to develop a baseline test result, which would lead to sizing guidelines for CPU and Memory requirements per concurrent user of PLM system.

1. INTRODUCTION

   It is almost impossible and not practical to calculate a 100% accurate H/W size because a lot of parameters are hard to be decided precisely and too many assumptions are to be considered. Most important factors while sizing the hardware infrastructure are:

   • It performs the intended function correctly (correctness)

   • Performs it efficiently (performance)

   • Does so in a cost-effective manner (Cost).

     A correct hardware size may not imply that it performs blazingly or is very cost-effective. It is necessary to trade-off performance or perfect correctness to save cost. Hence it calls for development of methods in sizing the hardware, where a trade-off between these three conflicting items in some logical manner is established to achieve optimized system performance.

2. EXPERIMENTAL RESEARCH PLAN

   The foundation of an accurate estimation of system resources for PLM system begins with a full understanding of how the system will be used. This is referred to as a Usage Profile. Key elements of a usage profile include:

   • Number of users

   • User login rate

   • Types and categories of users

   • Features used by each user type

   • Data types used by the users

     The sizing information provided in this paper is based on the PLM system Client Usage Profile

     as shown in the table below:

     Tool	HP LoadRunner 8.1
     User Distribution	Approximately: 70% Consumer users and 30% Author users. 60% of users are light users loading small assembly, 35% of users are medium users loading medium assembly, and 5% of users are heavy users loading large assembly (Refer to Table2).
     Consumer user Actions		* Query / View Dataset 4X (File sizes – 250KB, 500KB, 1MB, 3MB)

     • Simple Query 5X

     • View Product Structure 1X

     • Adv Query / View Properties

     	5X * BOM Report 1X
     Author user Actions	*View Product Structure 3X
     User Loading	Users log in with unique id/password and are all ramped up in 66 minutes (Refer to Figure2). Steady state at peak user load is maintained for at least 90 minutes.
     Transaction Probability	Each author and consumer performs all of the above respective actions for every login session.
     Activity Rate	Standard rate of 18 transactions per hour (tph) per user with interval between transactions randomly varying from 20 seconds to 10 minutes is used in the simulated experiment. To simulate user loads beyond 500 users (maximum number of LoadRunner licenses at Siemens), higher transaction rates of 36 tph/user and 54 tph/user were used.

     • Query –

     • Save-As Item

     • Create Item

     • Delete BOM Item

     • Add BOM Item

     • Edit BOM Item

     • Revise Item

     • CheckOut Item

     • CheckIn Item

     • Create Dataset / Upload Text file (250KB-40%, 500KB-30%, 1MB- 10, 2MB-10%, 3MB-10%)

     Table1: Client Usage Profile

     1. Tools used for the experimental research testing

        HP Load runner tool is used in this experimental research for simulating the user loads on the PLM system hardware infrastructure. LoadRunner contains the following components:

        The Virtual User Generator captures end-user business processes and creates an automated performance testing script, also known as a virtual user script.

        The Controller organizes drives, manages, and monitors the load test.

        The Load Generators create the load by running virtual users.

        The Analysis helps you view, dissect, and compare the performance results.

        The Launcher provides a single point of access for all of the LoadRunner Components

        Load testing typically consists of five phases: planning, script creation, scenario definition, scenario execution, and results analysis.

        Figure1: Load Testing Phases

        • Plan Load Test: Define the performance testing requirements, for example, number of concurrent users, typical business processes and required user data.

        • Create Vuser Scripts: Capture the end-user activities into automated scripts.

        • Define a Scenario: Use the LoadRunner Controller to set up the load test environment.

        • Run a Scenario: Drive, manage, and monitor the load test from the LoadRunner Controller.

        • Analyze the Results: Use LoadRunner Analysis to create graphs and reports, and evaluate the performance.

          A network simulation tool is either a hardware evice or software application that allows one to simulate various network characteristics such as throughput and latency. Network Simulation Tool used in this experimental research is Network Nightmare. This will simulate remote network latencies for specific user log-in.

          The experimental research is conducted with the following software versions:

        • PLM Application: Siemens PLM Teamcenter 8.3.2

        • Database: Oracle 11.2.0.1

        • Web Application: Weblogic 10.0

     2. User Login Rate

        User Login Rate is defined as the average number of login attempts per minute during any given period. If the User Login Rate is high, then system resources will need to be increased to handle the peak load of users logging in plus users already logged in.

        Login rate is illustrated for 500 users in Figure2. It shows it has an average rate is 7.5 logins per minute. In this User Profile, users stay active for at least one hour and then begin to logout as they complete their activities.

        Figure2: User Login Profile

     3. User Types and Categories

        Users typically rely on a subset of PLM features according to their role in the organization. Some users may work exclusively in CAD Manager or Workflow, while others may work mostly in BOM. Generally most of the PLM system users are consumer users who reference or retrieve information and a small number of users are author users who create or manage that information.

        Every type of user will fall into one of the following user categories and each will utilize system resources differently:

        User Type	Heavy	Medium	Light
        Concurrency	50%	30%	15%
        Activity ratio	40%	20%	10%
        Data Structure Size in number of BOM lines	2,000 ~ 3,000	< 500	10 ~ 100

        Table2: Definition of Heavy, Medium and Light users

        • User concurrency ratio is the time logged on to PLM system divided by the total time available.

        • Activity ratio is the time in percent; user spends working on the logged-in PLM system.

     4. Features Used

        Each feature provided by PLM application requires differing amounts of each type of computing resource. For example, one feature may require pieces of data from different sources such as a

        .gif image from the data volume plus a simple query of the database, thus requiring more work from the PLM Application server and Data Volume servers, but very little from Oracle server. Another feature may not require any volume data but requires a complex query to be performed on the database placing a heavy load on Oracle but virtually none on the PLM Application server.

     5. Data Used

     Data used by the end user, including CAD files affect the system resources needed for the transactions to be completed. The following table shows the characteristics of data used in this experimental research:

     Name	Classification	Parts	Levels	Size MB	Default Name of top assembly
     87_comp_assy	MEDIUM	87	3	54.80	gm_assy_001.prt
     a6_model	MEDIUM	38		55.60	a6_cape_cod.prt
     AMAT_files	LARGE	170	4	32.80	0290-TOP1.prt
     binding	MEDIUM	26		80.00	binding_assembly.prt
     computer	SMALL	16		3.94	notebook_assy.prt
     explorer	MEDIUM	44		50.00	explorer.prt
     gm_data	LARGE	341		269.00	aer15830.f01.0019.prt
     gurney	SMALL	13		28.80	aar3.prt
     hub	MEDIUM	90		35.30	assy_demo.prt
     indy	SMALL	27		7.01	indy_scene.prt
     mfex	SMALL	15		7.53	mfex.prt
     nutcracker	SMALL	14		1.68	nutcracker_plus_smasher.prt
     PL41756	SMALL	20		1.66	pl41756-000.prt
     terry	MEDIUM	67		12.50	loghauler.prt
     valve	SMALL	20		2.49	cl-amd_total_valve_assm.prt
     WheelBaseAssembly	SMALL	15	2	16.00	300-963.prt

     Table3: Characteristics of the Assemblies

3. EXPERIMENTAL RESEARCH RESULTS

   Server Demand Rate

   The Usage Profile will generate a specific system Load Profile that characterizes what resources are used in each server throughout a typical day. The load profile can be simplified by averaging daily utilization and adjusting for peak usage to estimate the Server Demand Rate. This is denoted as SPEC rating, a popular indicator of how much work a computing system can perform (i.e. throughput).

   SPECint_rate2006, the current benchmark used by hardware platform providers to rate server throughput, is used in this research to estimate CPU capacity. This is a CPU throughput benchmark from SPEC, an independent benchmarking organization (see http://www.spec.org and http://www.spec.org/cpu2006/results/ [Ref.1]).

   1. PLM Application Server

      Peak and Average Server Demand Rate (SDR) of PLM Application Server per user for different platforms are listed in Table4 below as SPECint_rate2006 values.

      Platform	Peak CPU per User in SPECint_rate2006	Average CPU per User in SPECint_rate2006
      AIX	0.283	0.105
      HP-UX	0.346	0.071
      Solaris	0.149	0.047
      Suse Linux	0.140	0.047
      Windows	0.142	0.044

      Table4: Test Results for PLM Application Server SDR per user

      The CPU Utilization of PLM Application server during the tests on AIX platform is shown in Figure3 below.

      Figure3: PLM Application Server CPU Utilization AIX platform (500 Users)

      Number of Users = 500 users SPECint_rate2006 of IBM server = 179

      Peak CPU per User in SPECint_rate2006 = [(179 x 0.79)/500] = 0.283 Average CPU per User in SPECint_rate2006 = [(179 x 0.294)/500] = 0.105

      Each Concurrent user consumes approximately the amount of RAM and SWAP listed in the Table5 below in Megabytes at the PLM Application server layer. Note that HP-UX and Solaris pre-allocate SWAP space when a process is instantiated. [Ref. 2 and 3]

      Platform	RAM per User in MB	SWAP per User in MB
      AIX	114.30	0.49
      HP-UX	147.01	169.26
      Solaris	47.70	106.46
      Suse Linux	55.74	0.00
      Windows	33.98	0.03

      Table5: Test Results for PLM Application Server RAM and SWAP per user

      The Memory Utilization of PLM Application server during the tests on AIX platform is shown in Figure4 below.

      Figure4: PLM Application Server Memory Utilization AIX platform (500 Users)

      Number of Users = 500 users + 20 warm tcservers Total memory used = (114808 55370) = 59438 MB RAM per User = 59438 / 520 = 114.3 MB / user

   2. PLM Database Server

      The Usage Profile plays a big role in determining the Oracle Server Demand Rate (ODR) of PLM Database Server and ultimately the size of the Oracle server. Oracle server sizing factors are again related to the types and frequency of PLM operations but are generally more affected by:

      • The amount of data managed

      • The number of concurrently logged in users

      • The data access patterns of users

      • Settings in the web server configuration

      • Database index and optimizer maintenance

        Peak and average Oracle Server Demand Rate (ODR) of PLM Database Server per user for different platforms are listed in Table6 below as SPECint_rate2006 values.

        Platform	Peak CPU per User in SPECint_rate2006	Avg CPU per User in SPECint_rate2006
        AIX	0.087	0.022
        HP-UX	0.084	0.024
        Solaris	0.053	0.017
        Suse Linux	0.077	0.013
        Windows	0.036	0.012

        Table6: Test Results for Oracle Server ODR per user

        The CPU Utilization of Database server during the tests on AIX platform is shown in Figure5 below:

        Figure5: Oracle Database Server CPU Utilization AIX platform (500 Users)

        Number of Users = 500 users SPECint_rate2006 of IBM server = 106

        Peak CPU per User in SPECint_rate2006 = [(106 x 0.41)/500] = 0.087 Average CPU per User in SPECint_rate2006 = [(106 x 0.103)/500] = 0.022

        Each Concurrent user consumes approximately the amount of RAM and SWAP listed in the Table7 below in Megabytes at the Oracle Database Server layer. Note that HP-UX and Solaris pre-allocate SWAP space when a process is instantiated.

        Platform	RAM per User in MB	SWAP per User in MB
        AIX	5.57	0.00
        HP-UX	6.52	13.44
        Solaris	3.72	5.57
        Suse Linux	3.31	0.00
        Windows	1.73	0.08

        Table7: Test Results for Oracle Server RAM and SWAP per user

        The Memory Utilization of Database server during the tests on AIX platform is shown in Figure6 below:

        Figure6: Oracle Database Server Memory Utilization AIX platform (500 Users)

        Number of Users = 500 users + 20 warm child processes Total memory used = (18475 15579) = 2896 MB

        RAM per User = 2896 / 520 = 5.57 MB / user

   3. PLM WEB Server

      Peak and average Web Server Demand Rate (WDR) of PLM Web Server per user for different platforms are listed in Table8 below as SPECint_rate2006 values.

      Platform	Peak CPU per User in SPECint_rate2006	Avg CPU per User in SPECint_rate2006
      AIX	0.009	0.004
      HP-UX	0.017	0.003
      Solaris	0.002	0.0001
      Suse Linux	0.007	0.004
      Windows	0.005	0.002

      Table8: Test Results for Web Server WDR per user

      The CPU Utilization of Web server during the tests on AIX platform is shown in Figure7 below:

      Figure7: Web Server CPU Utilization AIX platform (500 Users)

      Number of Users = 500 users SPECint_rate2006 of Test web server = 90

      Peak CPU per User in SPECint_rate2006 = [(90 x 0.05)/500] = 0.009 Average CPU per User in SPECint_rate2006 = [(90 x 0.0195)/500] = 0.004

      Each Concurrent user consumes approximately the amount of RAM and SWAP listed in the Table9 below in Megabytes at the PLM Web server layer. Note that HP-UX and Solaris pre- allocate SWAP space when a process is instantiated.

      Platform	RAM per User in MB	SWAP per User in MB
      AIX	0.97	0.00
      HP-UX	5.13	5.41
      Solaris	0.55	0.40
      Suse Linux	1.15	0.00
      Windows	0.58	0.00

      Table9: Test Results for Web Server RAM and SWAP per user

      The Memory Utilization of Web Application server during the tests on AIX platform is shown in Figure8 below:

      Figure8: Web Server Memory Utilization AIX platform (500 Users)

      Number of Users = 500 users + 20 warm child processes Total memory used = (4595 4091) = 504 MB

      RAM per User = 504 / 520 = 0.97 MB / user

   4. PLM system Client

      Rich Client experiments were performed and resource utilization of the client workstation was measured for both 2-tier and 4-tier environments. The workstation machine used for these tests was a HP Z400 configured as follows:

      • Intel Xeon, 2×2.533 GHz Dual-Core CPU

      • 16GB of physical RAM

      • Microsoft 64 bit Windows7 Operating System

        Key system utilization metrics were collected during the execution of the test to determine CPU and memory requirements.

        User Type	Rich client Memory on Windows (4-tier)	Rich Client Memory on Windows (2-tier)
        Typical (Navigator, My Worklist applications)
        Virtual Bytes	1920 MB	2048 MB
        Private Bytes	400 MB	512 MB
        Working Set	256 MB	400 MB
        BOM / Visualization (Large Assy expanded / viewed in BOM Module / embedded Viewer)
        Virtual Bytes	2304 MB	2560 MB
        Private Bytes	640 MB	768 MB
        Working Set	512 MB	640 MB

        Table10: Rich Client Workstation Memory Measurements

        To maximize workstation performance allocate sufficient physical RAM required for the operations used (i.e. the usage profile) in addition to the OS and any other applications that may be running on the machine.

      • A single user Rich Client workstation configured in 4-tier mode should be equipped with a SPECint_rate2006 value of at least 30.0 to provide some excess capacity, again without regard to other applications.

      • A system configured in 2-tier mode should be equipped with a SPECint_rate2006 value of at least 36 to provide some excess capacity.

4. Conclusions from Experimental Research

   This experimental research provides guidelines for establishing initial erver sizing requirements. It provides information about the types of computing hardware resource required for a specific usage profile, and aspects of each that may meet unique usage requirements of automobile companies.

   Hardware sizing must be done in a specific scenario compliant with deployment architecture and solution architecture. Sizing guidelines provided in this chapter for all layers of PLM deployment are based on experimental research done on a standardized representative database with a specific set of user scenarios on an out-of-the-box application configuration.

   In the entire server sizing recommendations the key resources are the CPU capacity (determined by the SPECint_rate_base2006) and the Memory (RAM). Equivalent or better servers from any hardware vendor, with any supported operating system, can be selected to satisfy the deployment requirements.

   Physical Hard Disk Space calculation is based on SWAP Space, Software Installation space, Business Data size, Redundancy Policy of the company, etc.

   1. Suggested Sizing Calculation formula

      Using the experimental results following formulae are suggested for calculating the CPU Spec- Int-Rate and Memory (RAM). These will help to calculate the minimum infrastructure size needed for optimal performance of PLM system for specific number of concurrent users.

      SIR = (ConUsersNum * SDR * BufCoeff ) / CPUMaxUsg

      RAM = (ConUsersNum * MemPerConUser * BufCoeff) + OSMem + SGA

      Where

      • SIR SPEC-Int-Rate of the server

      • ConUsersNum — Number of Concurrent Users

      • SDR Server Demand Rate

      • MemPerConUser — MB / per concurrent user

      • BufCoeff — Buffer coefficient based on scaling factors

      • CPUMaxUsg — Maximum Usage Ratio of CPU

      • OSMem Memory consumed by Operation System

      • SGA System Global Area applicable to Oracle database server only

        SDR: This value for PLM Application server is shown in Table4, for Database Server is shown in Table6 and for Web Application Server is shown in Table8 above for different platforms of deployment based on the experimental results.

        MemPerConUser: This value for PLM Application server is shown in Table5, for Database Server is shown in Table7 and for Web Application Server is shown in Table9 above for different platforms of deployment based on the experimental results.

        BufCoe: Suitable scaling factors need to be considered to take care of production system variations that include usage scenarios, transaction rates, type of data, data size, etc. This value can be from 1.5 to 2.0 depending on the complexity of PLM system deployment.

        CPUMaxUsg: Server performance remains fairly consistent below the server load of 80% of available capacity. Beyond this point response times can increase in a very nonlinear manner. Hence CPUMaxUsg values are taken as 80% for sizing calculations.

   2. Guidelines for Performance Optimization

   Auto companies need to ensure that the servers used for PLM system deployment meet the sizing requirements as calculated using the formulae suggested in Section 4.1. This calculated size is the minimum needed size for the specific number of concurrent users to achieve desired end user performance.

   This sizing calculation result can be used to procure properly sized server machines for new implementations. In case of existing deployment infrastructure, this calculation will help to maximize the usage of existing hardware. Auto OEMs can determine the number of concurrent users that can be deployed on the existing infrastructure for optimal system performance.

   When the number of concurrent users deployed on the PLM system equals the calculated value, the PLM system in on Break-Even. At this point, the PLM system will not have resource bottleneck affecting the end user performance.

   If more users are added, the system performance will deteriorate. Any system performance optimization efforts on hardware infrastructure will be futile, unless the infrastructure is upgraded and/or enhanced to the calculated value for the increased number of concurrent users.

   If less numbers of users are deployed, infrastructure usage will not be maximized, resulting in under utilization of available resources.

5. REFERENCES

1. http://www.spec.org/cpu2006/results/

2. Stephen Ciullo, HP Senior Technical Consultant and Doug Grumann, HP Performance Technology Center R&D Lead Engineer, HP-UX Performance Cookbook – revision 10JUN08.

3. B̦rje Lindh РSun Microsystems AB, Sweden, Application Performance Optimization Sun BluePrints OnLine РMarch 2002

4. Michael Greaves, Product Lifecycle Management: Driving the Next Generation of Lean Thinking, NewYork, McGraw-Hill, (2006).

5. M.S.Gopinatha and Dr.Vishnukant S.Chatpalli, Implications of Globalization on product design IT systems in Automobile Industry PDMA India IV annual International conference, NPDC 09 New Product Development: Challenges in meltdown times, Department of Mechanical Engineering and Department of Management studies, IIT, Chennai, India, pp. 94- 101, 17-19th Dec 2009 (www.npdc.iitm.ac.in).

6. M. S. Gopinatha, Dr. Vishnukant S. Chatpalli and Dr. K. S. Sridhar, Survey of factors influencing the performance of PLM system in Auto Industry, International Journal of Research in Computer Applications and Management (IJRCM), Volume no. 2 (2012), Issue no. 12, ISSN 2231-1009, pp. 47-52, December 2012, (http://ijrcm.org.in).