Enterprise POS Tuning Guide

Transcription

1 Version: 1.1 Status: Final Enterprise POS Tuning Guide Version Status Date 1.1 Final Page 1 of 19

2 Contents 1 Summary Tuning Overview A Note on Sizing Topologies, and their Impact on Tuning Local Store Server Topology Centralized Store Server Topology The Optimum Head Office Deployment The EPOS Components Tuning the Operating System Linux Middleware Preparation File System Remove Unnecessary Services Tuning DB Physical Disks DB2 Configuration Advisor DB2 Maintenance Tuning WebSphere Application Server Java Memory Management and Garbage Collection Thread Pool Management JDBC Tuning WebSphere MQ Tuning EPOS EPOS Configuration Appendix: Additional Resources...19 Page 2 of 19

3 1 Summary Enterprise POS (EPOS) is a world-class point of sale platform. It has been designed to take advantage of modern technologies and middleware, making it one of the most scalable retail platforms available. This software offers a great deal of flexibility; it can be used for small and large retailers, for very small and very large stores, for low-volume boutiques as well as very busy convenience stores. This flexibility is achieved through the tuning of a myriad of options. EPOS is built upon IBM s Web- Sphere Remote Server, which includes WebSphere Application Server, WebSphere MQ, and DB2 UDB. Each of these components can be tuned for different operating environments. Additionally, you can custom-tune the EPOS itself to be used in different circumstances. This document provides guidance on how to tune this point of sale platform to meet the needs of retailers. 2 Tuning Overview 2.1 A Note on Sizing Sizing hardware to meet requirements is a complex task which is typically accomplished using skill sets that range from benchmark testing to real-world experience. This guide does not deal with hardware sizing. What it does deal with is how to get the most out of the hardware that is being used. 2.2 Topologies, and their Impact on Tuning EPOS has the ability to deploy its components on various nodes in a retail system. This is often one of the first decisions made during the blueprinting phase of a project. The following subsections list typical topologies and identify tuning issues associated with each one: Local Store Server Topology This is the most common topology, in which both the POS Manager and the Configurator are deployed centrally. The store server holds only the POS component. It is possible to use the central site as a failover target. This topology is the most frequently used for the following reasons: Allows retailers to use smaller servers in the store since major functions are performed centrally. Does not require a cluster at every store (POS Manager in the store); using a central cluster guarantees high availability. From a tuning perspective, the Head Office deployment in this topology is a major performance hot-spot. Transactions are posted (via JMS) from all stores, all stores use it for POS Manager. Additionally, if using a Master Data Import (MDI), the Head Office component serves all stores their master data. Significant effort should be applied to making this Head Office deployment run as efficiently and smoothly as possible. Page 3 of 19

4 The stores are typically less of a concern in this topology, unless the stores are larger (more than 20 terminals). In this case, tuning the store server to support the number of concurrent clients becomes important Recommendations Unless there is a reason not to, use this topology. Unless the retailer is quite small (less than 100 stores), separate the Head Office Application Server from the Database Server. The operating system, hardware, disk utilization, etc. are typically very different. By separating them, they can be tuned independently. Follow the advice in this Tuning Guide as closely as possible Centralized Store Server Topology This topology is only for retailers that have very high WAN reliability and performance. This topology does not deploy in-store servers. The store server components are deployed at a central site. The POS Clients communicate across the WAN for all operations. If the WAN is down, the POS Client is unavailable, unless using Offline Capable Clients. This is an excellent topology for retailers that have a reliable-enough WAN. However, any instability in the WAN will cause this topology to behave very poorly, and as such, is only recommended for retailers that have 99.9% WAN reliability. If the retailer meets this requirement, the benefits are clear: a central store server, if sized appropriately, can support more than one store, significantly reducing the total cost of ownership Recommendations If the retailer s WAN meets the availability and performance criteria, this is a good choice. Sizing the store servers is the key to ensuring they can support the number of POS clients required. Separate the Store Servers from the Head Office servers. I.e. deploy only POS on the store servers, and POS Manager on the Head Office Servers. Separate the App and DB servers on the head office. 2.3 The Optimum Head Office Deployment The Head Office, in nearly all EPOS deployments, is where the biggest performance load is. The Head Office handles: Transactions posting from the store POS Manager (in most deployments) Service Access Exporting services to ERP Importing Master Data etc. Page 4 of 19

5 Therefore, it is critically important to create a Head Office environment that is suitable to grow with the retailer s environment. Out of the box, EPOS places all middleware components on the same physical machine. WebSphere Application Server, WebSphere MQ, and DB2, are all deployed automatically. However, this can be changed by the retailer in many ways: Separate the database from the application server this is typical in most large scale deployments, as the operating system and hardware can be tuned differently for DB2 and WebSphere. This is recommended. Separate WebSphere MQ from the Application Server in extremely intensive environments, WebSphere MQ can be very CPU intensive, and may be best served by its own environment. Deploy DB2 s database into a SAN. Deploy WebSphere MQ into a cluster provides load balancing and high availability. Deploy WebSphere into a Node Deployment (ND) cluster provides high availability and load balancing. Note that these changes are not automatically deployed, and must be configured by the retailer. Assistance for making these changes is available from both SAP and IBM. 2.4 The EPOS Components There are six main tunable components to any EPOS deployment: Hardware Hardware tuning involves the adding or removing of hardware, for example, adding memory, CPUs, disks, etc. In some cases, changing BIOS settings may improve performance. Hardware tuning is not discussed in this guide. Operating System Both Windows and Linux can be tuned to support EPOS deployments. WebSphere Application Server this is the container for most of the EPOS business logic. This can be highly tuned to support the needs of a retailer. WebSphere MQ This component is used for message interchange between servers. It can be tuned to support the number of servers to connect, as well as to better support the message volumes of the individual retailers. DB2 As a data storage mechanism, DB2 is widely used for all CRUD (Create, Read, Update, Delete) operations. DB2 can be tuned based on whether a retailer chooses to do more reporting or transactions, as well as the size of data to be retained. EPOS The EPOS software can be tuned. Choosing the correct topology is the first tuning operation. There are also a number of system properties that can be set to improve performance, as needed. Page 5 of 19

6 3 Tuning the Operating System 3.1 Linux The following tuning parameters have all been tested on Suse Linux Enterprise Server, versions 9.3 and However, they should apply to most other Linux editions. Unless otherwise noted, all commands executed below should be executed using the root id Middleware Preparation Follow the operating system pre-requisites for the IBM Middleware. Use the following links to access documentation on the necessary settings: WebSphere Application Server: doc/info/aes/ae/tins_linuxsetup.html WebSphere MQ: m File System During on-going POS operations, there is a significant amount of inserts performed for recording transactions. As load increases, disk access becomes a major point of contention. For Head Office systems, we strongly recommend the use of a SAN. By having faster access and more physical disks, a limiter can be avoided. For In Store systems, the decision making lies in whether to use RAID, and which RAID option to use. We noted a significant performance improvement going from RAID 5 to RAID 0. For Linux, ext3 is strongly preferred over reiserfs. Ext3 is more appropriate for larger files, such as databases. Reiserfs is more appropriate for smaller files. For reiserfs file systems, in /etc/fstab add noatime,notail to the appropriate file systems. These settings reduce the amount of work performed each time a file is read or accessed. For ext3, only noatime is appropriate. Explanations below: noatime - turns off 'access time'. Can be a significant performance boost under some load scenarios. notail - stops the fs from storing small files in the end of the tree storing file metadata Remove Unnecessary Services For most distributions, the default Linux installation includes services that are not required for operating an EPOS Server application. Disabling these services reduces the overhead on the server. The first service that can be disabled is XWindows. XWindows support is not needed on the server application (although it is required on Linux POS Terminals). Disable this by setting the initial run-level of the server to 3 instead of 5. In /etc/inittab, modify the following line: # The default runlevel is defined here Page 6 of 19

7 id:5:initdefault: To this: # The default runlevel is defined here id:3:initdefault: You can also disable extra virtual terminals in /etc/inittab. This may only yield a small, but nevertheless worthwhile benefit. Comment out (add # at the beginning of a line) the terminals you won t use. In the example below, terminals 4, 5, and 6 are disabled. # getty-programs for the normal runlevels # <id>:<runlevels>:<action>:<process> # The "id" field MUST be the same as the last # characters of the device (after "tty"). 1:2345:respawn:/sbin/mingetty --noclear tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 #4:2345:respawn:/sbin/mingetty tty4 #5:2345:respawn:/sbin/mingetty tty5 #6:2345:respawn:/sbin/mingetty tty6 Finally, check that all unnecessary services are disabled. Run chkconfig list as root and check to see which services are on in runlevels 3 and 5. In our test environment, the following services were unnecessarily enabled: alsasound: Enables the sound card. postfix: Enables . smbfs: Enables the Samba file system. A service can be disabled using the following command: chkconfig <servicename> off After making all of the above changes, restart the server. 4 Tuning DB2 As an out-of-the-box environment, SAP DB2 is reasonably well-tuned. However, every retailer uses different hardware, and has different data sets. As such, certain manual steps are required to tune DB2. The DB2 Control Center should be installed on an administrator PC before starting the tuning steps. While many of the options below are available in a command line mode, certain steps are easier with the Control Center. Additionally, the databases being administered need to be added to the control center before continuing. Page 7 of 19

8 4.1 Physical Disks When planning the hardware configuration of the Head Office database server system, the physical disk configuration can have a major impact on the performance of EPOS. The reasons for this impact are several, including the overall size of the data sets handled by the Head Office server, the transaction loads on the database and subsequent storage read and write frequencies, and the ability of the hardware to respond to the external storage request. The following general guidelines should be considered with respect to the physical configuration of the EPOS database storage hardware: Increase the number of spindles to improve performance. Spreading the storage operations over more spindles allows for the storage management to access or write information to more than one spindle simultaneously rather than wait for a single spindle to respond. This is most important for random, spaced read access, as well as, container write access, where the container is spread over multiple spindles. Proper logging (archive settings). DB2 logs require storage space. If left unchecked and nonarchived, the logs can fill the assigned log file storage. Automatic archiving of DB2 log files is recommended. Cyclic logging should not be used as it could severely impact replication if MDI is utilized. Archived logs should be removed periodically to offline storage but only if the archive files are no longer required for replication (MDI activated). Use of a SAN. A SAN is specifically designed to handle large storage requirements and high access rates. For large scale EPOS Head Office deployments, that is, large databases, these devices are a natural fit in terms of hardware storage for DB2. DB2 Automatic Storage is recommended for the deployments and segmentation of the SAN into several storage paths assigned to DB2. Each storage path represents a RAID 5 string of physical disks managed by the SAN. Separate storage paths for log files are also recommended to keep log file activity in the physical layer independent of the EPOS functional storage access. Tuning Tablespaces and Buffer Pools. As a consequence of performance testing, a more granular tablespace structure is being adopted by EPOS. This provides the opportunity to tune individual tablespace and bufferpool performance parameters based on the deployment of specific data content and hardware. 4.2 DB2 Configuration Advisor Tuning a database manually is a complex task; years of experience are typically required to massage the vast number of configuration parameters into a set that best supports the usage of the database. DB2, in its latest versions, has provided a configuration advisor that simplifies the database configuration. IBM quotes that the DB2 Configuration Advisor can achieve configurations that are at least 90% as good as what an expert DB2 DBA can set up manually. To begin, right-click on the database in Control Center, and select Configuration Advisor. Page 8 of 19

9 Figure 1: DB2 Configuration Advisor Set the required parameters on subsequent screens. Our recommendations are as follows: On the Server page, select the maximum amount of memory that can be dedicated to DB2. If the machine is running DB2 exclusively (recommended for Head Office), set the amount of memory as high as possible (for instance, 85%). Workload Mixed Transactions Select More than 10 (long transactions). You will then need to estimate the number of transactions per minute that you expect to complete across the enterprise. Enter the estimated value keeping in mind that the peak load on the system (at Head Office) will typically be transaction posting. Priority This is a choice that the retailer must make. We have had good results with Both. Populated The engine works best when the database has data in it. For the first run, select no. However, run the tool frequently, with data in it, and better optimizations will be offered. Page 9 of 19

10 Connections The maximum size of the database connection pools in WebSphere are defaulted to 100 for the TE database and 20 for the Receipt database. These maximums will most likely never be exceeded, therefore: o When the DB is on a separate machine from the application server, set the initial value for remote connections to 120, and set the local connections to 5 to allow for MDI and administrative users. o When the DB is on the same machine as the application server, set the initial value for local connections to 125. Isolation The default, Cursor Stability, is appropriate. Results The advisor calculates and displays setting changes. Schedule You can save the changes to an SQL file, or you can execute them or schedule them to be executed. Summary Displays the summary of execution. In our test labs, an MDI run improved from 18 minutes to 4 minutes after executing this wizard, demonstrating that substantial improvements can be made quickly. 4.3 DB2 Maintenance Keeping track of the statistics in the database is a critical part of ensuring that the database query engine always responds with the best access plan. As such, there are two jobs that should be run frequently: RUNSTATS This updates the statistics on table sizes and indexes that are kept by the database. This command should be run relatively often, especially after periods of high activity, such as an extremely high volume transaction day, or a large MDI run. REORGCHK UPDATE As the database gets used, data gets inserted, updated, and deleted. This can cause the table indexes to get fragmented. A full REORG will allow the database to organize the indexes for faster access. This job is time-consuming, and will take several hours. To determine if it is needed, you can run a REORGCHK (without UPDATE). See DB2 documentation for further details. 5 Tuning WebSphere Application Server WebSphere Application Server provides innumerable tuning options. This section covers the settings that SAP has found to yield the highest performance benefits. Some of the settings mentioned below depend entirely on the retailer s environment, and some are best practices that should not be changed unless advised otherwise by SAP. IBM also provides the Tivoli Performance Advisor as part of WebSphere. This tool can be used to determine any problem spots and is well-documented in the WebSphere Information Center (see the Appendix for link). Page 10 of 19

11 5.1 Java Memory Management and Garbage Collection Numerous articles have been written about Java Garbage Collection, and for good reason. Performance testing conducted by SAP has uncovered that significant benefits can be achieved by tuning the garbage collector. This section does not attempt to explain Java Memory Management; instead, it describes what SAP has discovered about our usage of Java Memory. Initial tests using IBM s default garbage collection policy yielded significant CPU overhead and frequent collections. In order to analyze the output of verbose garbage collection, we used the IBM Pattern Modeling and Analysis Tool for Java Garbage Collection (see the Appendix for links). This tool indicated that garbage collection was occurring quite frequently every 200 ms on average. This is a significant performance problem, as all processing must stop in order for garbage collection to occur. To solve this problem, we tuned the garbage collector to use IBM s gencon policy generational and concurrent. According to the IBM documentation: gencon, which is new in IBM Java 5.0, is a generational garbage collector for the IBM virtual machine for Java. The generational scheme attempts to achieve high throughput along with reduced garbage collection pause times. To accomplish this goal, the heap is split into new and old segments. Long lived objects are promoted to the old space while short-lived objects are garbage collected quickly in the new space. The gencon policy provides significant benefits for many applications, but is not suited to all applications and is generally more difficult to tune. With the gencon policy, you tune the new and old generations. Our testing has shown that for extensive transaction posting, roughly 25% of the total heap size should be old, and 75% should be new. Another setting that we have found useful to tune is Xnoclassgc, which prevents the JVM from garbage collecting a class from memory when no instances of that class exist. Using the above settings, for heap sizes of 2GB max, the JVM parameters should be: -Xnoclassgc -Xgcpolicy:gencon -Xmns384m -Xmos128m -Xmnx1536m -Xmox512m These values can be set using the IBM WebSphere Administration Console, which, if defaults are used during installation, can be found at After logging in, select Servers followed by Application Servers. On the right-hand side, select server1. Under Server Infrastructure, select Java and Process Management, then Process Definition. Under Additional Properties, select Java Virtual Machine. Make the necessary changes in the Generic JVM Arguments. Note that you can click the Custom Properties link on this page to change D JVM Parameters settings. SAP has also investigated the use of large pages, that is, the ability of a process to use extremely large heap sizes (option is Xlp). Our testing has not shown benefit, but the IBM JVM Tuning Guide indicates that it may be useful for scalability purposes. Note that the operating system must be tuned to allow this to happen. A link with instructions for Linux is included in the Appendix. Page 11 of 19

12 Figure 2: The WebSphere Administration Console 5.2 Thread Pool Management Threads are how the Java Virtual Machine enables concurrency. WebSphere Application Server offers three distinct thread pools that are used by EPOS: o Message Listener Thread Pool Used by Message Driven Beans receiving messages from WebSphere MQ (for example, Transaction Post, Customer Service Request) o ORB Thread Pool Used by the POS Server application to service POS Clients. o HTTP Thread Pool Used by POS Manager and Configurator. Managing the size of the thread pools is critical to ensuring optimum throughput. It is unlikely that all three thread pools become stressed at the same time. Therefore, the tuning of each thread pool can be handled somewhat independently provided the loads are well understood. For example, the HTTP Thread Pool will be busy during store opening and closing times, while the Message Listener Thread Pool will be Page 12 of 19

13 idle. However, during the course of the business day, the Message Listener Thread Pool will be very busy receiving transactions from the stores, while the HTTP Thread Pool will only see occasional use, such as for a report or a shift change. The single key factor to manage is CPU Utilization. As requests come in, over any of the thread pools, they get handled by a thread. If the number of requests exceeds the thread pool size, the requests will queue (wait) for an available thread. Once the thread pool is fully occupied, typically, the CPU will be fully occupied. We have found the best throughput is when the CPU peaks at 80%. This means that the number of threads must be tuned higher or lower accordingly. If the CPU utilization is too low, it means the machine sits idle, and you need to increase the thread count. If the utilization is too high, the CPU is thrashing and not working efficiently, and you need to reduce the thread count. For a dual-core Intel Xeon processor, running at 3.1 GHz, we found that for transaction posting, the machine handled 8 threads very well. However, note that this number is highly dependent on a number of factors, such as, the use case, the transaction size, the hardware, etc. A good number to start with is between 4 and 8 threads per CPU, and then adjust from there. Thread pools are also configured in the WebSphere Administration Console. To configure the Message Listener Thread Pool, select Servers followed by Application Servers. On the right-hand side, select server1. Under Communications, select Message Listener Service, then Thread Pool. Adjust the maximum size accordingly. Page 13 of 19

14 Figure 3: Configuring the Message Listener Thread Pool Note that additional throttling can be achieved by tuning the listener ports. Listener ports are the Java Interface to the various JMS destinations that EPOS communicates with. For example, a transaction posting from stores to Head Office is received at the te-from-stores-listenerport. From Message Listener Service in the console, select listener port, then te-from-stores-listenerport. Here, you can set the minimum and maximum sessions. Page 14 of 19

15 Figure 4: Configuring Listener Ports During listener port tuning, the listener port maximum sessions setting determines the maximum number of threads that can be dedicated to receiving messages from that particular JMS destination. This number should be less than the number of threads in the Message Listener Thread Pool. However, the sum total of all the maximum listeners of all the listener ports need not (and should not) be less than the number of threads. The goal during listener port tuning is to balance response time and throughput. For example, consider that a POS Client is failed over to the Head Office. It makes an EFT request. The POS Client is locked, waiting for a response from the EFT Provider over the te-eft-listenerport. Meanwhile, all other stores are in normal operations, and transactions are posting at a high rate on the te-from-storeslistenerport. Suppose that the maximum number of threads in the Message Listener Pool is 25, and the te-from-stores-listenerport is set to a maximum number of listeners of 25. In this case, there may be a wait time until a thread is available to process the EFT response, which in this case, is much more timecritical (a customer is waiting for the response). If the maximum number of listeners on te-from-stores- Page 15 of 19

16 listenerport was set to 20, for example, there would be 5 threads left over for other activities. As an overview, when performing listener port tuning, consider the types of loads that the retailer will incur. Another item that can be tuned during listener port tuning is the number of retries. When a message is received, if an unexpected error occurs, such as a timeout or deadlock, the message will be rolled-back and retried. The default retry count is 5 times, after which, the message will be automatically sent to a Dead Letter Queue for error handling. The retry count can be lowered to 2 or 3, reducing the amount of work the application server has to do in an error situation. The ORB and HTTP thread Pools are configured in the WebSphere Administration Console. From Application, select Servers followed by Application Servers. On the right-hand side, select server1. Under Additional Properties, select Thread Pool. Configure as needed. When putting the three thread pools together, consider that having three thread pools with a maximum of 10 threads each does not mean that 30 threads will be actively using the CPU at all times. These are thread POOLS, indicating that threads are allocated as needed. Configure each thread pool for maximum throughput in that area, and then be conservative as loads are mixed. For example, if the optimum thread pool size for Messaging is 10, but it s possible that there will be some POS Manager transactions occurring simultaneously, it might be best to lower the Message Listener Thread Pool to 8, so that a part of the CPU is always available for POS Manager. 5.3 JDBC The Database Connection Pools in EPOS typically do not require tuning. However, the Database Connection Pool should have at least as many connections as the maximum number of concurrent requests you anticipate. If the number of requests you anticipate is greater than the maximum configured in the Connection Pool, increase the size accordingly. To configure the Database Connection Pool, select Resources from the WAS Console, followed by JDBC, and then Data Sources. Select the appropriate Data Source and select Connection Pool Properties. Page 16 of 19

17 Figure 5: Configuring the Connection Pool The prepared statement cache can also be tuned. SAP has initialized this value to 100. The Tivoli Performance Viewer might determine that the retailer s usage requires this value to be increased or decreased. 6 Tuning WebSphere MQ We have found that the information provided in the WebSphere MQ tuning guide (see the Appendix for link), to be invaluable in improving the performance of the WebSphere MQ. We strongly recommend that you read the WebSphere MQ tuning guide. In summary, the following elements can be tuned: Log File Size Should be maximized. In EPOS 3.1 SP2 and beyond, this will be the default. MaxActiveChannels See SAP OSS Note In short, the number of channels must be set to a value commensurate with the number of store servers. LogFiles Primary and Secondary Log Files can be increased. SP2 and beyond defaults both values to 10. LogWrite If the Log Files are stored on a SAN, the SAN guarantees write consistency. Therefore, this value can be set to SingleWrite. The default is TripleWrite, and is slower. Page 17 of 19

18 Further tuning can be made to the way that WebSphere Application Server communicates with Web- Sphere MQ. The default EPOS method is CLIENT. This enables the Application Server and Queue Manager to be deployed on different physical servers. In situations where the Queue Manager is on the same server as the Application Server, you can use the BINDINGS method, which is significantly faster. To make the change, go into the WebSphere console, then Resources, then Queue Connection Factories. Select Triversity Transactionware Queue Connection Factory. Under Transport Type, change the value from CLIENT to BINDINGS. Repeat this process for the Topic Connection Factory. Save the changes, and restart WebSphere. Certain Operating System defaults are inappropriate for a production WebSphere MQ system. For Linux, the following document provides the necessary recommendations: nfo/exp/ae/tprf_tunelinux.html The above document is actually a WebSphere Application Server document, but we have found that MQ errors are received if these recommendations are not followed. Additionally, the ulimit value for open files must be greater than for root and trivers users. 7 Tuning EPOS Currently, EPOS does not have many system tuning parameters. The only noteworthy tuning parameter at this point is whether or not you want the XSL Templates to be cached. For EPOS 3.1 SP1 and earlier, XSL Templates are not cached by default, but you can change this setting. XSL transformations are used by the EPOS in multiple places. An earlier version of Xalan-J, the parser provided in the IBM WebSphere Java Virtual Machine, had a defect that caused problems with XSL transformations in a high-volume environment. The latest service pack for the IBM JVM, 1.5 SR7, includes this fix. This service pack is not currently installed by default; to set the XSL Template caching option, you must download and install the service pack manually. To enable XSL Template caching, set the option to com.sap.epos.xmltransformerutil.usecache=true. This is a D option to the Java command line, and you can set it in the WebSphere console, under JVM custom properties. In EPOS 3.1 SP2 and higher, this will be the default, and by setting it to false the caching will be disabled. SAP has noted significant performance improvements in Transaction Posting by using this setting. 7.1 EPOS Configuration EPOS is highly configurable. Although configurations are mostly business oriented, they can have impact on overall system performance. Listed below are some of the EPOS configurations that have performance implications. Item Lookup EPOS supports multiple ways of looking up items. Typically, an item is identified by an item key (e.g ) and item key type (e.g. UPC). Since there are multiple item key types, and EPOS allows the use of mixed key types, EPOS can be configured to find the best match by using the item key only. Although this feature is convenient and easy to configure, it will not perform as well as item lookup with both item key and key type. Page 18 of 19

19 Transaction Discount EPOS supports two types of transaction discounts - regular prorated discount and standalone discount. Regular prorated discount generates separate discount lines for each item. Standalone discount generates one discount line based on the transaction total. If the retailer's typical transaction contains a large number of items, applying a regular prorated discount doubles the transaction line count and increases server load. Receipt Archive EPOS can be configured to archive documents that are not output during sales. For example, each purchase can generate multiple optional receipts. Although only some customers will request the optional receipts to be printed, you can configure EPOS to archive all optional receipts in the database for later reference. If many such documents are configured to be archived, the total Tlog size will increase. MixMatch and Promotion MixMatch and Promotion are powerful pricing features that support the Best Price logic. Best Price logic determines the best (lowest) price for an item when there is more than one promotion applicable to it. Since business logic needs to calculate prices for each applicable promotion, item scan response times will be affected if there are many items that have many applicable promotions. 8 Appendix: Additional Resources IBM Information Centers the source of all the IBM documentation. DB2 9.1: WebSphere 6.1: WebSphere MQ 6.0: General Tuning Information WebSphere MQ Tuning: WebSphere MQ Networking Setup: nfo/exp/ae/tprf_tunelinux.html A Redbook on WRS Performance: Tuning Linux for Large Page Support: The IBM Pattern Modeling and Analysis Tool for Java Garbage Collection : WebSphere JVM Tuning: aes/ae/tprf_tunejvm_v61.html Page 19 of 19