A Fieldpine system will often include a server component used at head office to combine and control all the stores in the network. These services can be placed on Virtual Machines. The following outlines some of the technical considerations for IT designers.
- There are two main services "PosService" and "Gds/2". Both are currently required and focus on slightly different needs. PosService tends to be used more for receiving and storing transactions from stores, while Gds/2 is focused more on reporting. Gds/2 does include transaction support as well though, so this division is somewhat murky.
- Both of the services will "run" on pretty much any level of hardware, however performance is highly dependant on the resources available (See below)
- PosService is conceptually one thread (although it is actually multi threaded internally) receiving transactions and storing them to the database. The transactions are typically done in the background to the user.
- Gds/2 is conceptually much more advanced. It uses multiple processes and multiple threads within processes. It uses "cpu dispatching" to select
different algorithms in some key areas. For a Virtual environment, this implies:
- Do not cause the VM to execute emulated instrutions by defining the VM as a higher spec'd CPU than the actual available. Gds/2 uses CPUID and other similar techniques to detect environment abilities.
- Gds/2 assumes that the box it is running on for it to use alone. It schedules tasks internally. It is a server application and expects a dedicated server. It can be de-rated however when running on laptops or smaller/shared environments.
- Gds/2 works best with 4 to 8 vcpu. It uses atomic instructions and/or lock prefix. Threads may work cooperatively on the same memory segment, in a cache friendly way.
- Gds/2 uses threads internally and runs them at different priorities. You may observe high CPU from a process, but this could easily be one of the background analytical tasks running 1 or 2 points below normal priority.
- One of the documented effects of VM environments is they are often much lower in terms of IO performance. If you are running ODBC connections to backend databases, remember that placing Fieldpine in one VM and the database server in another VM is compounding this IO performance issue. Gds/2 will sometimes aggresively cache in memory to avoid this double hit.
With a virtual server it makes little sense to specify minimum hardware requirements. Most customers have no way of verifying the underlying hardware is correct or how loaded the server is. Gds/2 therefore takes a different tack and reports to users the actual performance being achieved. These performance reports are de-sensitised, we understand that VMs will have variable performance from time to time, but the medium term average is more interesting to users.
We mainly care about performance when users are interactively waiting. Performance of background tasks at 2am is not generally of interest to us
The following measurements are taken at various intervals:
- Cpu performance characteristics. How many "Add 1+1" operations can we perform per unit of time.
- Memory performance. Can we read and write main memory at acceptable rates? We test new memory allocation, large sequential scanning and random access.
- Disk IO performance. We measure times to open and close files, random small IO time and large sequential IO.
- We attempt to verify that the system is not using time adjusting techniques to hide CPU brownout. (ie where the clock is massaged after insufficient CPU was allocated to the VM)
In general we expect the following minimums:
|CPU performance||250||The main test we use for reporting is an unrolled 32bit XOR loop|
|Memory Allocate and clear||600 MB/sec||This is quite a rare operation. Minimum for "real" hardware is 1GB/sec|
|Memory Bandwidth||?||No recommendation currenty|
|Small Random IO performance||< 20mS sustained per IO||Easily achievable with low end disks|
|Large Sequential IO performance||At least 60MB/sec sustained|
The results of the tests are presented to users in a comparitive fashion rather than hard numbers as shown above. ie "Your performance is about equal to a $1000 laptop".