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
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 cus- tom-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 siz- ing. 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 possi- ble.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
Page 4 of 19
The stores are typically less of a concern in this topology, unless
the stores are larger (more than 20 ter- minals). In this case,
tuning the store server to support the number of concurrent clients
becomes impor- tant.
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 typi- cally
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 re- quired.
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
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
Page 5 of 19
Therefore, it is critically important to create a Head Office
environment that is suitable to grow with the re- tailer’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 deploy- ments, 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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 transac- tions. 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 data- bases. 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 appli- cation (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
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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
#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 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 dif- ferent
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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 sev- eral, 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 rec-
ommended. 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 ac- cess 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 recom- mended 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
individ- ual 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”.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 lo- cal 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 data- base. 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 documenta- tion 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 deter- mine any problem spots
and is well-documented in the WebSphere Information Center (see the
Appendix for link).
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 per- formance 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 ma- chine 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 ap- plications, 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, se- lect “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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 han- dled 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
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 num- ber 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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 post- ing 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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 num- ber 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 num- ber of threads. The goal
during listener port tuning is to balance response time and
throughput. For ex- ample, 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-
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
Page 16 of 19
listenerport was set to 20, for example, there would be 5 threads
left over for other activities. As an over- view, 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 maxi- mum 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”.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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.
© 2008 SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 trans- formations 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 perform- ance 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.
Title: Enterprise POS Tuning Guide Version: 1.0 Date:
11/18/2008
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 gener- ates 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 in- creases 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 re- ceipts 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