Hardware you can use to deploy the Knowledge Center varies from the particular needs & conditions that you will use it in. Below is the set of recommendations and considerations that will help you to achieve a better understanding how the different components our your environment influence the Knowledge Center performance.
Overall application is light on CPU when in comes to finding relevant knowledge to your search requests. This leads to lower dependency on CPU performance. Any modern processor with multiple cores will do the job. These days, two key parameters of the CPU are: speed and number of cores. In this case, you should choose a CPU with more cores than a slightly faster one. This allows the Knowledge Center to service concurrent requests more efficiently.
A modern CPU with 4 or 8 core CPUs is recommended.
This solution is designed to process tons of data and select only relevant data for each one of your queries. In this case, memory is one of the resources that is intensively used. When planning your host memory you need to ensure that RAM size will be enough to host all your running applications and some extra is left for the system to host the OS filesystem cache.
The absolute minimum of 8Gb RAM must not be crossed. It is recommended to use hosts with 16 Gb. With optimization and running multiple applications on the host, you may end up with 32 or 64 Gb hosts.
Discs or Storage
Disks play a key role in the system performance as well. Being data-intensive and doing a lot of the read-write operations, Genesys Knowledge Center Server is highly dependent on the speed of the disk operations.
There are several common ways to improve performance of read-write intensive applications:
- Use the OS cache to minimize the number of read operations required (see recommendation above in the Memory section).
- Using faster disks; high-performance (15K) spinning disks are a good choice. Usage of SSD disks will burst the performance of your cluster even mlore.
- Using RAID 0 to improve the speed over any type of disk you are using (no need to go further with redundancy features of RAID, as data replication is the integral part of the solution itself).
The amount of disk space consumed by the Genesys Knowledge Center solution can be estimated using the Sizing Calculator.
We recommend keeping all your nodes within a cluster in the same network, avoiding cross data center communication. Replication of the data between datacenter is a separate concern and deserves a separate solution.
The key parameters of the network you need to watch for are:
- latency: the Knowledge Center Cluster is the self-managing solution that distributes the load between all available nodes. By sending a request to one node of the cluster, your are employing all nodes (to the extent that it makes sense) to execute your request. Keeping the latency low will guarantee you the maximum speed of distributed execution.
- reliability: minimizing the number of disconnects in the system will guarantee that the Knowledge Center Cluster is fully concentrated on serving the request of your internal and external customers instead of doing house-keeping duties such as replacing dead nodes and relocating the data.
- bandwidth: being quite light in network communication during ordinary work (executing the searches), this solution can be demanding on the network bandwidth while indexing huge amounts of data or recovering from node failure.
Genesys Knowledge Center Server does not require any enormous hardware configuration to run on. A medium-sized box is the best option to run this application.
Another general recommendation is to keep your hardware set up as solid as possible:
- adding a high performance, huge RAM, SSD RAID 0 enabled server to the cluster of outdated servers will not provide any noticeable or stable performance improvement overall of the solution. The speed of newly-added servers are completely compromised by the old hardware that executes parts of the same requests making the overall response and performance to be almost unchanged.
- putting one server into a higher latency network segment can improve some access parameters in that particular segment but will result in overall system performance degradation.
The best shot for the deployment of the cluster is using similar hardware for all servers and putting them into similar network conditions. This will ensure the most balanced use of your resources.