Performance issues in Cerm What to check first? The Cerm software is built as a client server model. This means the client and the server need the correct specifications, but also the network in between needs to be fast and stable. In this document you ll find the performance issue causes we ve seen the most at our customers in the last years. This document is meant for your IT (partner) to investigate performance issues in Cerm. This document starts with the client part, the client running the Cerm software has the highest influence on the overall performance of the Cerm MIS system. Cerm Client - Processor (CPU) Power profile There are settings on 3 different levels: the physical server or pc, the Hypervisor host and guest VM s / OS. Physical server / PC In most physical servers or pc s there will be BIOS settings which tell the pc to run in a kind of Balanced Performance, Low Performance or High Performance mode. As an example, this is the setting on an HP Server (2016): Putting the setting from HP Dynamic Power Savings Mode to HP Static Performance Mode, gave our customer a performance boost which almost doubled the speed of Cerm. The reason is that in a balanced mode ( Dynamic Power Saving Mode ), the CPU will use less power. When using less power, the CPU is less powerful and becomes slower.
Hypervisor Hypervisors (e.g. VMWare ESX, Hyper-V, ) will probably have power settings, for example (ESXi): By default, this one is set to Balanced. High performance on ESX means Do not use any power management features. This way, the OSes in the VM s will manage power usage. We advise to set this setting to High performance. Guest VM / OS This can be the Windows client on a pc, or the Windows setting on a Remote Desktop Server (RDS). Windows has Power Options included in the control panel. We have seen performance drops when this setting was set to Balanced (recommended). We advise to put this on High performance. Speed (Ghz) Each Cerm applications run in a single CPU core. This means adding CPU cores to a pc or server will not increase the Cerm performance. If the Cerm performance needs to be increased, the CPU speed will need to increase. The speed of Cerm can be compared with the speed of the client s CPU. For example, a 2 Ghz client will run at about 2/3 of the speed compared to a 3 Ghz client. Windows Server 2012 RDS TSFairShare TSFairshare is a mechanism in Microsoft Windows RDS which dynamically balances CPU, network and disk resources along the different users on the RDS. This seems to be a good functionality, but for Cerm, it generates waiting times of 5-10 seconds when running Cerm applications on the RDS. We advise to disable this functionality.
Windows Server 2012 RDS Memory When using a Remote Desktop Server / Terminal server, give it enough RAM memory. We estimate 1 GB RAM / user. Non existing links in Cerm Links to different files do exist in cerm. There is a program in the Cerm software which checks those links. It is located in the Cerm explorer (File > Links). When choosing * as the anchor, all links will appear. The links can be selected and checked by clicking the button Check. Links which are not available or accessible, can slow down and generate errors in the software. General UNC shares Cerm has some general UNC shares configured. These shares need to be available at any time. The configured UNC shares are located in System Management > System explorer > Directories. When clicking Edit, you can check if the shares are available with the green arrow at the left. Especially the Job, Product and Tools folders are mostly customized folders where Cerm not always has the right access to. Not being able to connect to or access these shares, will generate slowness and errors in the Cerm software. Please check the general UNC paths on all client having the Cerm software.
JDF Settings The Cerm application sends and receives continually JMF messages to JDF controllers like Esko, Xeikon, Incorrect JDF settings can cause performance issues. Please check these 3 JDF settings: The correct ip address and port of the JDF service. The ip address must be the ip of the host running the JDF service. Also JDF and JMF directory must exist and have RW permissions The JDF service must be in a running state All defined JDF controllers must exist and be accessible Anti-virus Anti-virus programs mostly check read/write operations on the hard disks of an OS. We advise to activate only the scanning of write operations. When all written files are ok, these files will still be ok when they need to be read. On clients, we also advise to exclude the Cerm folders out of the anti-virus scan, so they aren t scanned every time the program is trying to do something. The folders which need to be excluded are the Cerm and Cerm Utilities folders in the program files folder. Next to these folders, it s also a good idea to exclude the *.bpl files in c:\windows\system32..bpl files are Borland compilation files which are installed with the Cerm software. Server Side - SQL and File server
Disk I/O The SQL server and file server functions will need to be able to read/write the data fast. The more IOPS the SQL and file server have, the faster this part will be. Memory SQL Server tries to cache as much data as possible in Memory. This is because reading from the memory is a lot faster than reading from the hard disk. This means SQL Server always uses quite a lot of memory. Database sizes are growing, which will need the SQL server memory to grow with it. The available memory for the OS (and SQL server) should be at least the size of the main database + 5GB. Network A stable and fast network is fundamental for Cerm. A 1 Gb network with modern switches and good cabling is necessary. If you are working on a terminal server, you could choose for a 10 Gb network between SQL/File server and RD/Terminal server. When checking your network, please check at least: Network card of the pc Driver of the network card on the pc Network card of the server(s) Driver of the network card(s) on the server(s) Network cabling in between pc s, servers, switches, router(s), Don t use WIFI connection between client and server! Wi-Fi does not guarantee a stable and fast network performance! Virtualization Ballooning This is a phenomenon we know from VMWare ESX(i), but it will probably exist on other Hypervisors under another name. Ballooning appears when the VM s are trying to use more memory than the available memory for the hypervisor. It then will try to use the hard disk as extra memory. But as the hard disk is much slower than real RAM memory, the VM s running with this memory from the hard disk will be running slower.
You can analyse ballooning in the Performance graphs (Memory) in vsphere Client which is connected with the ESX(i). VM Backup In a lot of cases, VM s are fully back upped with scripts running on the hypervisor or running from a remote backup machine (e.g. VeeAm). Running such backup scripts during production hours could cause performance issues.