Home > System Administration > Services > Merchant Central Server Settings

Merchant Central Server Settings

Overview

Service Function Pools

Reporting Threads

Overview

There are many INI file settings that can be used to control how MerchantCentralServer (MCS) operates. These settings are stored in the DYNAMIC.INI file in the [DRSServers] section, for example

[DRSServers]

MaxConnectionsBusiness=40

MaxConnectionsPOS=100

There are five main work sections in MCS. Each section handles a number of different functions. These sections are:

Basic	Handles basic functions such as login, user validation, cache data, and so on.
Data	Handles actual data changes, for example add a new item, change a PO, and so on.
Business	Performs business functions such as get costs, increase stock, and so on.
POS	Handles POS functions such as reloads, validate customers, record sales, and so on.
Reports	Handles report related functions such as creating reports, downloading reports, and so on.

The settings in DYNAMIC.INI are generally available for each section. The setting will include the name of the section. So for the MaxConnections setting there is MaxConnectionsBasic, MaxConnectionsData, MaxConnectionsBusiness, MaxConnectionsReports and MaxConnectionsPOS. These all control the same thing (MaxConnections) but are for each of the five sections.

Listening Ports

Clients connect to MCS via one of four network protocols - HTTP Stateless, TCP Stateless, TCP Stateful and TCP Mixed. In order to successfully connect, the client has to know the address of MCS and the port to talk to. Likewise, MCS has to know which port it needs to listen on. For example, by default HTTP traffic for Basic requests come through on port 8300. TCP traffic for Business requests are on 8321. If you don't like the defaults you can change the ports that MCS will listen on. There is one set of ports for each of the five sections. Each set consists of three ports - one for HTTP, one for TCP Stateless and one for TCP Stateful/TCP Mixed.

HTTPPortBasic=8300

TCPPortBasic=8301

TCPStatePortBasic=8302

HTTPPortData=8310

TCPPortData=8311

TCPStatePortData=8312

HTTPPortBusiness=8320

TCPPortBusiness=8321

TCPStatePortBusiness=8322

HTTPPortReport=8330

TCPPortReport=8331

TCPStatePortReport=8332

HTTPPortPOS=8340

TCPPortPOS=8341

TCPStatePortPOS=8342

If you don't want to open five ports for each running instance of MCS, you can set up MCS so that it only uses one port. You must always set up a port for the Basic service. However, you can set the other ports to 0. If you do this, the port for that service will not be activated. You would need to change your communication configurations for the client so that all the port numbers were the Basic port number.

Example

MCS DYNAMIC.INI

[DRSServers]

TCPStatePortBasic = 8302

TCPStatePortData = 0

TCPStatePortBusiness = 0

TCPStatePortReport = 0

TCPStatePortPOS = 0

Client DYNAMIC.INI

[DRS]

PortBasic=8302

PortData=8302

PortBusiness=8302

PortReport=8302

PortPOS=8302

Compression

You can control whether the server will compress its data before sending it to the client. Compression will generally give better performance because you are sending less actual data. The compression can be controlled for each network protocol (HTTP stateless, TCP stateless and TCP stateful) and for each section.

HTTPCompressBasic=F

TCPCompressBasic=F

TCPStateCompressBasic=F

HTTPCompressData=F

TCPCompressData=F

TCPStateCompressData=F

HTTPCompressBusiness=F

TCPCompressBusiness=F

TCPStateCompressBusiness=F

HTTPCompressReport=F

TCPCompressReport=F

TCPStateCompressReport=F

HTTPCompressPOS=F

TCPCompressPOS=F

TCPStateCompressPOS=F

Encryption

The data traffic that is communicated between clients and servers can be encrypted. Add the following to DYNAMIC.INI

[Miscellaneous]

EncryptComms=T

This should be set for each of the services, not just Merchant Central Server. It does not need to be set at the clients though. When a client connects to an encrypted server, it will detect the encryption and automatically adjust itself to use the encryption.

Database Pooling

Every time a client calls a function on MCS and MCS needs to access the database, it requires a database connection. Opening a database connection and then closing it when finished, adds time to every database access. MCS maintains a pool of database connections for each section. When it needs to access the database, it gets a connection from the pool.

This connection is already open and ready for use. When it has finished the database access, it returns the connection to the pool without closing it. This means that we save the open/close connection time which results in significant time gains.

Also, database connections use memory resources. Most of the time, clients are not accessing the MCS. So even though you might have 100 users, only 10 of them may be trying to use the MCS at exactly the same time. So we only need a pool of 10 connections. If we tried to keep connections for every client, we would use significantly more resources. You need to tune the size of the pool. By default there is a maximum of 40 database connections for each section.

MaxConnectionsBasic=40

MaxConnectionsData=40

MaxConnectionsBusiness=40

MaxConnectionsReport=40

MaxConnectionsPOS=40

Communication Pools

The HTTP Stateless and TCP Stateless communication methods work by using a pool of threads (one thread is one client connection). A separate pool is kept for each section. The default pool size is 50. If a connection cannot be obtained the client will get a network error (normally 10061).

Note: The TCP Stateful method is handled differently and does not use a pool of threads.

HTTPThreadsBasic=50

TCPThreadsBasic=50

HTTPThreadsData=50

TCPThreadsData=50

HTTPThreadsBusiness=50

TCPThreadsBusiness=50

HTTPThreadsReport=50

TCPThreadsReport=50

HTTPThreadsPOS=50

TCPThreadsPOS=50

Service Function Pools

As described above there are five main sections - Basic, Data, Business, Report and POS. Each of these consists of a number of services. Each service has a set of functions. So in the Data section, there is an Item service (contains the functions for changing items) and an Inventory service (contains functions for changing inventory transactions).

When MCS needs to call a function in one of these services, it has to create a thread, get an instance of the service, do the work, close the service and close the thread. In order to improve performance, MCS keeps a pool of threads for each service. This saves the work of having to open and close the service and therefore improves performance.

When MCS starts up, it will open the full number of threads for the pool immediately. So if you say the pool size for the Item Data service is 10, MCS will immediately open 10 threads ready for work. If a client tries to get a thread from the pool and they are all used, they will immediately get an error. If this starts to happen consistently, you may need to increase the pool size. Remember that these functions are generally designed to be as short and quick as possible. So if you see a pool size of 20, that is the number of simultaneous calls to that pool. If the function being called only takes 50ms to run, then a pool size of 20 is going to serve a lot of users. However, some functions may take a long time to run, for example the stock audit functions, so it may be worth while increasing these pools.

The creation of this pools will only use memory NOT connections from the database pool (see above). A thread will not use a database connection until it has been activated. So if you have 200 various threads spread over a single section, you will not use 200 database connections UNLESS all threads are active at exactly the same time.

These pool settings are stored in DYNAMIC.INI in the DRSServerPoolSizes section, for example

[ DRSServerPoolSizes]

CacheService=10

CacheLookupService=15

The pools that are available are as follows:

AccountDataService=20	Data	Number of threads available for adding/editing accounts data.
BasicService=20	Basic	Number of threads available for login in, validating users, getting next sequence values.
BusinessNextCounterService=10	Business	Each thread is used to get the next sequence number for a specific counter within business related functions.
CacheLookupService=20	Basic	Number of threads available for getting lookup data for clients (used for drop down combo-boxes), for example Departments, Reasons, and so on.
CacheService=10	Basic	Used internally to update the information in in-memory data caches. So if a location is changed and the cache needs to be reloaded, one of these threads will be used.
CostsSellsService=20	Business	The number of threads available for doing cost calculations.
CustomerDataService=20	Data	Number of threads available for adding/editing customer data.
DynaPOSTouchRemoteService=20	POS	Number of threads available to handle remote connections from v4 POS. (Not generally used)
FileService=20	Basic	The number of threads available for doing file downloads for upgrades.
InventoryDataService	Data	Each thread is used to add/edit inventory transactions.
InventoryService =20	Business	Number of threads available to perform stock increases and decreases and to validate an item exists at a store.
ItemDataService=20	Data	Each thread is used to add/edit items.
ItemService=20	Business	Used internally to load item details ready for inventory transactions.
LocationDataService=10	Data	Each thread is used to add/edit locations.
POSDataService=20	POS	The number of threads available to download POS data, upload Z-Read information, check table status, and so on.
POSMessages=20	POS	Number of threads available when POS want to check for messages for itself.
POSTransService=0	POS	Number of threads available for accepting sale transactions from POS.
ProjectDataService=20	Data	Number of threads available for adding/editing project/task data.
ReportService=20	POS	Number of threads available for requesting reports and downloading
StatsService=20	Business	Number of threads available for getting trading statistics and quantity sold information.
SetStoreCostsSellsService=20	Business	Number of threads available for doing the 'get new costs and sells' and 'set store costs/sells' processes.
StockAuditService=10	Business	Number of threads available for getting detailed stock audit information.
SupplierDataService=5	Data	Each thread is used to add/edit suppliers.
TicketService=10	Business	Threads available for doing ticket related functions.
TillDataService=5	Data	Each thread is used to add/edit tills.
TransHistoryService=20	POS	Each thread is used to get transaction history used for electronic audit or printing old receipts.
UserDataService=5	Data	Each thread is used to add/edit users.

Reporting Threads

Reports are requested by a client but are actually generated by MCS. MCS maintains a pool of threads specifically for processing reports. Each thread is able to generate one report. Reports are quite intensive to generate so you will want to limit the number of threads generated at any point in time. By default, 10 reports can be generated at one time. If you are running multiple MCS on one database, you may want to set this value to zero on some of the MCS so they don't generate any reports at all.

[DRSServers]

ReportThreads=10

Converted from CHM to HTML with chm2web Pro 2.85 (unicode)