enterprise pos tuning guide

Page 1 of 19
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date: 11/18/2008
Page 2 of 19
Page 3 of 19
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:
2.2.1 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 4 of 19
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.
2.2.1.1 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.
2.2.2 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 unavail- able, 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.
2.2.2.1 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
Page 5 of 19
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. Assis- tance 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 vol- umes 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 op- eration. There are also a number of system properties that can be set to improve performance, as needed.
Page 6 of 19
3.1 Linux
The following tuning parameters have all been tested on Suse Linux Enterprise Server, versions 9.3 and 10.1. However, they should apply to most other Linux editions. Unless otherwise noted, all commands executed below should be executed using the root id.
3.1.1 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: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base. doc/info/aes/ae/tins_linuxsetup.html
3.1.2 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 sce- narios.
notail - stops the fs from storing small files in the end of the tree storing file metadata.
3.1.3 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 7 of 19
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
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 unnec- essarily enabled:
alsasound: Enables the sound card.
postfix: Enables email.
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 8 of 19
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 re- spect 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 non- archived, 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 util- ized. 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 de- vices 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 granu- lar 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 9 of 19
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 10 of 19
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 ad- ministrative 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, demon- strating 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 or- ganize 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 11 of 19
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 Model- ing 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. Ac- cording 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 seg- ments. 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 exten- sive 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 http://<servername>:9060/ibm/console. After logging in, select “Serv- ers” followed by “Application Servers”. On the right-hand side, select “server1”. Under Server Infrastruc- ture, 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 12 of 19
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 13 of 19
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 14 of 19
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 In- terface 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 15 of 19
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-stores- listenerport. 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 time- critical (a customer is waiting for the response). If the maximum number of listeners on te-from-stores-
Page 16 of 19
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 Appli- cation, 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 Con- nection 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 “Re- sources” from the WAS Console, followed by “JDBC”, and then “Data Sources”. Select the appropriate Data Source and select “Connection Pool Properties”.
Page 17 of 19
Figure 5: Configuring the Connection Pool
The prepared statement cache can also be tuned. SAP has initialized this value to 100. The Tivoli Per- formance Viewer might determine that the retailer’s usage requires this value to be increased or de- creased.
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 1168143. 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. There-
fore, this value can be set to “SingleWrite”. The default is “TripleWrite”, and is slower.
Page 18 of 19
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 Facto- ries. 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: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/i 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 100000 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. 01233231354) 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 19 of 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 pur- chase 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 ref- erence. 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: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
WebSphere 6.1: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
Tuning Linux for Large Page Support: http://andrigoss.blogspot.com/2008/02/jvm-performance- tuning.html
The IBM Pattern Modeling and Analysis Tool for Java Garbage Collection : http://www.alphaworks.ibm.com/tech/pmat
WebSphere JVM Tuning: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/ aes/ae/tprf_tunejvm_v61.html

enterprise pos tuning guide

Documents