Download PDF (1.3 MB) - IBM Redbooks

More documents

Recommendations

Info

2.4.2 Use a high-performing browser The choice of browser technology is crucial to Business Process Manager client performance. It is possible that more recent versions of a browser perform better than the older versions of the same browser. 2.4.3 Enable browser caching Browsers generally cache static data after it is initially retrieved from the server, which can significantly improve response time for scenarios after the cache is primed. This improvement is especially true for networks with relatively high latency. Ensure that the browser cache is active and is effective. Cache settings are browser-specific; see 4.11, “Enable browser caching” on page 78 for further details. 2.4.4 Locate servers physically near clients, and databases physically near servers One factor that influences network latency is the physical distance between servers and clients, and also the distance between the Business Process Manager servers in a cluster and their database (for example, between the Process Server and its databases). When practical, locate Business Process Manager V8.0 servers physically close to each other and to the Business Process Manager clients to minimize the latency for requests. 2.4.5 Use modern desktop hardware For many Business Process Manager solutions, significant processing is done on the client system (for example, browser rendering). Thus it is imperative to deploy modern desktop hardware with sufficient physical memory and high-speed processors with large caches and fast front-side buses. Monitor your client systems with performance tools (Windows Task Manager or vmstat) to ensure that the client system has sufficient processor and memory resources to ensure high performance. 2.5 Large objects (LOBs) One issue that is frequently encountered by field personnel is identifying the largest object size that the Business Process Manager V8.0 server, corresponding document management functions, and corresponding WebSphere adapters can effectively and efficiently process. A number of factors affect LOB processing in each of these products. This section presents both a description of the factors involved and practical guidelines for the current releases of these products. The issue of identifying the largest object size primarily applies to 32-bit JVMs because of the constraints on heap sizes in that environment. The JVM is the single most important factor affecting LOB processing. JVM technology changed starting with Java 5, which was first used by the Business Process Manager products in V6.1.0. Business Process Manager V8.0 uses the Java 6 JVM, which is the follow-on release to Java 5. The suggestions and best practices in this document differ from those in Business Process Manager V6.0.2 and earlier, which used JVM 1.4.2. In general, objects that are 5 MB or larger might be considered “large” and require special attention. Objects of 100 MB or larger are “very large” and generally require significant tuning to be processed successfully. 18 IBM Business Process Manager V8.0 Performance Tuning and Best Practices
2.5.1 Factors affecting LOB size processing In general, the object size capacity for any installation depends on the size of the Java heap and the load placed on that heap (that is, the live set) by the current level of incoming work. The larger the heap, the larger the business object (BO) that can be successfully processed. To apply this principle, you must first understand that the object size limit is based on three fundamental implementation facts about JVMs: ► Java heap size limitations The limit to the size of the Java heap depends on operating system, but it is not unusual to have a heap size limit of approximately 1.4 GB for 32-bit JVMs. The heap size limit is much higher on 64-bit JVMs and is typically less of a gating factor on modern hardware configurations than the amount of available physical memory. Further details about heap sizes are described in “Increasing the Java heap size to its maximum” on page 63. ► Size of in-memory BOs BOs, when represented as Java objects, are much larger in size than when represented in wire format. For example, a BO that uses 10 MB on an input Java Message Service (JMS) message queue might result in allocations of up to 90 MB on the Java heap. This condition results from many allocations of large and small Java objects occurring as BO flows through the adapters and Business Process Manager V7.5. A number of factors affect the in-memory expansion of BOs: – The single-byte binary wire representation is generally converted to multi-byte character representations (for example, Unicode), resulting in an expansion factor of two. – The BO might contain many small elements and attributes, each requiring a few unique Java objects to represent its name, value, and other properties. – Every Java object, even the smallest, has a fixed need for resources because of an internal object header that is 12 bytes long on most 32-bit JVMs, and larger on 64-bit JVMs. – Java objects are padded to align on 8-byte or 16-byte address boundaries. – As the BO flows through the system, it might be modified or copied, and multiple copies might exist at any time during the end-to-end transaction. Having multiple copies of the BO means that the Java heap must be large enough to host all these BO copies for the transaction to complete successfully. ► Number of concurrent objects being processed The size of an object that can be successfully processed decreases as the number of requests being processed simultaneously increases because each request has its own memory usage profile (live set) as it makes its way through the system. Simultaneously processing multiple LOBs dramatically increases the amount of memory required because the total of live sets for the request must fit into the configured heap. 2.5.2 Large object design patterns The following sections describe the two proven design patterns for processing large objects successfully. In cases where neither design pattern can be applied, consider 64-bit mode. See 2.6, “Considerations for 64-bit mode ” on page 21 for details. Also, for IBM WebSphere ESB and Mediation Flow Components, a developerWorks article is available that details best practices and tuning for large messages: http://www.ibm.com/developerworks/webservices/library/ws-largemessaging/ Chapter 2. Architecture best practices 19
Page 1: IBM ® WebSphere ® Front cover IBM
Page 4 and 5: Note: Before using this information
Page 6 and 7: 3.1.8 Preventing WSDL validation fr
Page 8 and 9: 4.15.4 Sizing log files appropriate
Page 10 and 11: Trademarks IBM, the IBM logo, and i
Page 12 and 13: Now you can become a published auth
Page 14 and 15: 1.1 Products covered in this public
Page 16 and 17: 4 IBM Business Process Manager V8.0
Page 18 and 19: 2.1 Top tuning and deployment guide
Page 20 and 21: Two individuals with the following
Page 22 and 23: Turn off auto-tracking in business
Page 24 and 25: Avoid use of anonymous derived type
Page 26 and 27: ► ► Independent Disks (RAID) ad
Page 28 and 29: that can process 10 requests per se
Page 32 and 33: Batched inputs: Sending large objec
Page 34 and 35: 2.7 Business Monitor This section d
Page 36 and 37: 3.1 Process Designer development be
Page 38 and 39: 3.1.5 Use sequential system lane ac
Page 40 and 41: 3.2 Integration Designer best pract
Page 42 and 43: 3.2.4 Business object parsing mode
Page 44 and 45: Applications benefiting from lazy p
Page 46 and 47: Business object instance validator
Page 48 and 49: 3.2.6 Business Process Execution La
Page 50 and 51: Client systems that follow a page-f
Page 52 and 53: 3.2.10 Invocation style considerati
Page 54 and 55: If a number of services in a FanOut
Page 56 and 57: Aggregation blocks (FanOut and FanI
Page 58 and 59: ► ► ► - The generated BPEL fl
Page 60 and 61: 4.1 Performance tuning methodology
Page 62 and 63: This information is useful for obta
Page 64 and 65: ► ► ► ► Messaging and messa
Page 66 and 67: If you click Generational Concurren
Page 68 and 69: 4.3.7 Messaging engine properties T
Page 70 and 71: ► ► Ensure that database statis
Page 72 and 73: 4.5.8 Define Authentication Alias w
Page 74 and 75: 4.6 Process Center tuning Because a
Page 76 and 77: peak throughput, so if an adapter i
Page 78 and 79: esources (for example, a DB2 databa
Page 80 and 81:
Use the following steps to place al
Page 82 and 83:
4.7.5 Clustered topology tuning One
Page 84 and 85:
To check the Business Space target
Page 86 and 87:
In addition, you can customize the
Page 88 and 89:
4.9.2 Disabling event distribution
Page 90 and 91:
This processing and reporting mode
Page 92 and 93:
4.13 General database tuning This s
Page 94 and 95:
4.14 DB2-specific database tuning P
Page 96 and 97:
Increasing the primary log file siz
Page 98 and 99:
When running clustered applications
Page 100 and 101:
Using materialized query tables Whe
Page 102 and 103:
4.15.8 Special considerations for l
Page 104 and 105:
4.16.1 Monitoring garbage collectio
Page 106 and 107:
Increasing the maximum size of the
Page 108 and 109:
96 IBM Business Process Manager V8.
Page 110 and 111:
5.1 Business Process Manager server
Page 112 and 113:
Tuning variations Microflow: Number
Page 114 and 115:
DB2 database server in three-tiered
Page 116 and 117:
► Set the Maximum Connections pro
Page 118 and 119:
106 IBM Business Process Manager V8
Page 120:
► ► ► ► ► Understanding a
show all

Download PDF (1.3 MB) - IBM Redbooks

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?