Академический Документы
Профессиональный Документы
Культура Документы
No part of this publication may be reproduced or transmitted in any form or for any purpose
without
the express permission of SAP SE. The information contained herein may be changed without
prior notice.
Some software products marketed by SAP SE and its distributors may contain proprietary software
components of other software vendors. National product specifications may vary.
These materials are provided by SAP SE and its affiliated companies ("SAP Group") for
informational purposes only without representation or warranty of any kind, and SAP Group shall
not be liable for errors or omissions with respect to the materials. The only warranties for SAP
Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as
constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE in Germany and in several other countries.
For easier reading and better understanding, we will use in this documentation the following
typographic conventions and symbols.
Format Description
Introduction................................................................
................................................................................................
...................................................................................
................................................... 7
Architecture ................................................................
................................................................................................
...................................................................................
................................................... 8
Scaling................................
Scaling................................................................
................................................................................................
................................................................................................
................................................................................................
.................................................................
................................. 9
RAM ................................................................
................................................................................................
................................................................................................
................................................................................................
...................................................................
................................... 10
Network ................................................................
................................................................................................
................................................................................................
............................................................................................
............................................................ 11
Reference environment
environment for sizing ................................................................
................................................................................................
................................................................................
................................................ 11
Influencing factors for sizing of the reference environment.......................................................................11
Sizing of the reference environment ................................................................................................................11
Performance of the reference environment...................................................................................................12
Network ................................................................
................................................................................................
................................................................................................
............................................................................................
............................................................ 14
Sizing of the
the application server ................................................................
................................................................................................
....................................................................................
.................................................... 16
Number of required application servers .........................................................................................................16
Influencing factors for sizing of the application servers...............................................................................17
Scaling ......................................................................................................................................................................18
Introduction
This document outlines the factors influencing the sizing of the following applications:
The document describes the requirements for RAM, CPU, hard disk, etc. in the different
deployment scenarios, and gives additional information on application scaling.
For information on the installation process, refer to the corresponding Installation Guide. For
information on the operation process, refer to the corresponding Operation Guide. For
information on updates from older versions, refer to the corresponding Upgrade and Update
Guide.
8 Architecture
Architecture
Basic configuration
Assumptions
• Operating system is already installed. Indicated file system size refers to the portion
needed in addition to the operating system.
• Number of item master data records: 100,000 items
• Number of promotions 1,000
• No saving of customer data
• Number of transactions per day: 1,500 with an average of 10 line items
• Log file backup: 30 days
• Processor class: Intel Celeron processor
Minimum configuration
Type CPU RAM Hard disk
Recommended configuration
Type CPU RAM Hard disk
Scaling
The table below shows the additional resources required per influencing factor. Values are based
on the minimum system requirements described under "Minimum configuration". The data volume
of the POS especially depends on the number of transactions per day and on the master data
(items, GTINs, merchandise categories, customers, promotions, etc.).
Database size
Master data
Items DB size
30,000 140 MB
100,000 460 MB
500,000 2.3 GB
Transaction data
Transactions DB size
RAM
TouchPOS 32 Bit OS, 32 Bit Java Runtime 300 MB 100 MB 800 MB 768 MB
The RAM requirements also depend on the used Java Runtime and the garbage collector. The data
refers to Oracle Java 1.8 with Concurrent Mark Sweep Garbage Collector.
Network
TouchPOS Central POS Server, Store Device Control WAN 256 KBit 1024 KBit
The reference environment is meant to represent a typical configuration for the live operation, and
is used for the internal performance tests. Specific assumptions are made resulting in a defined
sizing.
The test results are an indicator of the performance that can be achieved under these conditions.
Platform
Criterion Instance
Criterion Instance
RAM 2 GB
Test results
Criterion Result
Basic configuration
Assumptions
• Operating system is already installed. Indicated file system size refers to the portion
needed in addition to the operating system.
• Number of item master data records: 100,000 items (stored in the central POS Service)
• Number of promotions 1,000 (stored in the central POS Service)
• No saving of customer data
• Number of transactions per day: 1,500 with an average of 10 line items
• Log file backup: 30 days
• Processor class: Intel Celeron processor
Minimum configuration
Type CPU RAM Hard disk
Recommended configuration
Type CPU RAM Hard disk
Scaling
The table below shows the additional resources required per influencing factor. Values are based
on the minimum system requirements described under "Minimum configuration".
Database size
RAM
Application Environment Heap Permanent size Typical footprint RAM required
The RAM requirements also depend on the used Java Runtime and the garbage collector. The data
refers to Oracle Java 1.8 with Concurrent Mark Sweep Garbage Collector.
Network
POS Service WAN 1024 KBit 2048 KBit Required bandwidth depends on the number of
POS Clients in the store.
Central Services WAN 256 KBit 1024 KBit Required bandwidth depends on the number of
POS Clients in the store.
The reference environment is meant to represent a typical configuration for the live operation, and
is used for the internal performance tests. Specific assumptions are made resulting in a defined
sizing.
The test results are an indicator of the performance that can be achieved under these conditions.
Platform
Criterion Instance
RAM 2 GB
Sizing procedure
Sizing of the POS Service depends on several factors. It is recommended to proceed as follows:
• Use sizing checklist to determine the relevant influencing factors (countries, stores,
platform)
• Sizing of application server instances or cluster
• Calculation of the database sizes
• Sizing of database server instances or cluster
Sizing checklist
The standard sizing checklist for POS Service contains important key figures, which are required to
determine the sizes of application and database servers. Among others, the following key figures
are required:
In this case, a load balancer will be placed in front of the cluster. It is essential that the load
balancer supports the sticky session mode. This means that the load balancer, during a session,
will always send the requests from one Thin Client to the same node unless the node fails. If the
node fails, the call will be routed to another node.
Generally, each temporary state of a transaction is persisted in the database and kept in the main
memory during the session. Only if a change between nodes occurs, the POS transaction will be
reloaded and added again to the session. In all the remaining cases, the transaction from the main
memory will be used.
Sizing: POS Service 17
• POS Clients/stores in different time zones, independently of the server time zone.
• Different master data sets for each of the stores or countries.
• Different configurations for each of the stores or countries.
Due to the one software version restriction, special attention should be paid to countries where
fiscalization is required. Depending on the applicable fiscalization laws, certification may be
required for new versions in these countries. Generally, this will result in lower update frequencies
and own versions for the concerned countries.
Overview
The following functional use cases are relevant for sizing of the POS Service:
Technical factors:
• Used runtime: Apache Tomcat (with Oracle JDK 8) versus SAP NetWeaver (with SAP JDK 6)
Simultaneous accesses
The POS Service uses the business layer of the POS application. Thus, the POS Thin Clients will call
the POS Service for each process step.
During usual POS Client operation, the majority of requests refer to:
The frequency of item entry and transaction closing should be taken into account for sizing of the
POS Service. These values depend on the average number of transactions per day for all the
stores, and on the average number of line items per receipt.
18 Sizing: POS Service
If the peak is considerably higher than the average values, peak values should be used for sizing
instead. If the difference between peak and average values is not extremely large, you can cope
with a buffer.
If there are few promotions only, price calculation is done very quickly. However, if there are a lot
of applicable promotions and a high number of receipt line items, price calculation may be decisive
for runtime duration of item entry. In this case, master data lookup and business logic will be of
less importance.
Application server
Using SAP NetWeaver as the runtime environment offers a large number of operational benefits
with respect to clustering and monitoring. Requirements of resources, however, are lower with
Tomcat. Using Windows or Linux as the operating system does not affect the sizing at all.
Apache Tomcat Application Server currently does not yet support clustering.
Database
It is recommended to not virtualize the database server as it depends on a good I/O performance
to a large extent.
It is recommended to use Oracle as the database server, and Oracle Real Application Server (RAC)
for larger installations.
Scaling
In general, scaling of the POS Service is almost linear with respect to the number of simultaneous
item entries. Server sizes should be calculated with a certain buffer, i.e. peak condition should not
correspond to 100% server load. If the server scaling is not sufficient, cluster operation mode will
be required.
Apache Tomcat Application Server currently does not yet support clustering.
Load balancer
If the SAP NetWeaver Application Server runs in a cluster, a load balancer will be placed in front of
the cluster. Depending on the load balancer, allocated CPU resources should be increased by 10-
20%. In case of the SAP Web Dispatcher e.g., increase by 20%.
Cluster structure
A NetWeaver cluster consists of several NetWeaver nodes. A NetWeaver node can run on different
hardware or different virtual machines.
A load balancer will be placed in front of the cluster (e.g. SAP Web Dispatcher), distributing the
requests to the NetWeaver nodes. For synchronization of the nodes, GK uses an own cluster
framework, which is able to directly cooperate with NetWeaver mechanisms. In addition, the
framework distributes tasks to various nodes.
Multiple NetWeaver Server processes can be executed in one NetWeaver node. Each of these
processes uses its own Java Virtual Machine (JVM), which is separated from the others. On the one
hand, this allows compensating the possible failure of a JVM. On the other hand, better hardware
utilization is provided in case of several processes running on accordingly sized NetWeaver
machines (i.e. large number of CPUs and a lot of RAM). SAP ICM (Internet Communication
Manager) is used to distribute the requests to several NetWeaver Server processes.
20 Sizing: POS Service
Important notes:
• The POS Service does not use an Enterprise
Enterprise Scheduler. The Enterprise Scheduler is used if
both a POS Service and a POS Server are running in the same application. The scheduler is
responsible for distributing and synchronizing the tasks within the cluster.
• All the nodes logically access the same database. It is even possible to use a database cluster
(e.g. Oracle RAC)
NetWeaver
It is recommended to use one NetWeaver Server process for approx. 8 CPUs with 8 to 12 GB RAM.
1. Saving of transactions: The transactions are saved to the POS Server transaction pool. For
database sizing, refer to the POS Server Sizing Guide.
2. Master data reading: Master data is loaded via Store Device Control. The size of the
database depends on the number
n of master data. Refer to the Store Device Control Sizing
Guide.
Sizing: POS Service 21
The general performance depends on the number of simultaneous accesses by POS Clients. The
number of simultaneous item scans per second is relevant for the sizing. As other types of
accesses, e.g. subtotal, payment etc. behave in a similar way, the number of item scans can be
used as the key figure for sizing.
Used transactions:
Measurement results:
200 8%
330 12%
500 20%
690 27%
The reference environment is meant to represent a typical configuration for the live operation, and
is used for the internal performance tests. Specific assumptions are made resulting in a defined
sizing.
The test results are an indicator of the performance that can be achieved under these conditions.
Promotions 100
Platform
Criterion Instance
Database Oracle
Clustering Yes (with and without the SAP Web Dispatcher as load balancer)
Application server
Criterion Instance
RAM 24 GB RAM
Nodes 1-4
Database
Criterion Instance
RAM 56 GB RAM
Sizing: POS Service 23
4x NetWeaver node + Web Dispatcher 424.6555 413.5979 346.7171 618.24 89.32 24.00
24 Sizing: Smart POS Service
Sizing procedure
The Smart POS Service is a POS Service that is locally installed in the store. If the central POS
Service fails, all of its services will be assumed by the Smart POS Service, for all the POS Thin Clients
of the store.
Overview
The following functional use cases are relevant for sizing of the POS Service as a Smart POS:
Technical factors:
Simultaneous accesses
The POS Service running as a Smart POS uses the business layer of the POS application. Thus, the
POS Thin Clients will call the POS Service for each process step.
During usual POS Client operation, the majority of requests refer to:
The sizing of the Smart POS Service should be determined according to the frequency of item
entries and transaction closing. These values depend on the average number of transactions per
day for all the stores, and on the average number of line items per receipt.
If the peak is considerably higher than the average values, peak values should be used for sizing
instead. If the difference between peak and average values is not extremely large, you can cope
with a buffer.
Sizing: Smart POS Service 25
If there are few promotions only, price calculation is done very quickly. However, if there are a lot
of applicable promotions and a high number of receipt line items, price calculation may be decisive
for runtime duration of item entry. In this case, master data lookup and business logic will be of
less importance.
Application server
Currently, the store supports Apache Tomcat Application Server only. Clustering is not supported
with the Smart POS.
Database
Scaling
In general, scaling of the POS Service is almost linear with respect to the number of simultaneous
item entries. Server sizes should be calculated with a certain buffer, i.e. peak condition should not
correspond to 100% server load.
1. Saving of transactions: The transactions are saved to the POS Server transaction pool. For
database sizing, refer to the POS Server Sizing Guide.
2. Master data reading: Master data is loaded via Store Device Control. The size of the
database depends on the number of master data. Refer to the Store Device Control Sizing
Guide.
3. General performance of POS Service accesses
The general performance depends on the number of simultaneous accesses by POS Clients. The
number of simultaneous item scans per second is relevant for the sizing. As other types of
accesses, e.g. subtotal, payment etc. behave in a similar way, the number of item scans can be
used as the key figure for sizing.
Used transactions:
Measurement results:
Derby 5
If Derby is used, the number of clients is severely reduced. Oracle Express variant is limited due to
CPU and RAM usage by the Express version.
A higher number of client accesses is possible with unlimited Oracle Database.
The reference environment is meant to represent a typical configuration for the live operation, and
is used for the internal performance tests. Specific assumptions are made resulting in a defined
Sizing: Smart POS Service 27
sizing.
The test results are an indicator of the performance that can be achieved under these conditions.
Platform
Criterion Instance
RAM 8 GB RAM
Derby 5 82 % 1.2 GB
GK SOFTWARE AG
Waldstraße 7
08261 Schöneck
Germany
Tel.: +49 (0) 3 74 64 84 – 0
Fax : +49 (0) 3 74 64 84 - 15
E-mail: documentation@gk-software.com
www.gk-software.com