Home > System Administration > Services > Merchant Central Server Settings
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.
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
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
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.
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
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
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. |
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) |