 |
|
Notes on reliability and performance/caching
Notes on performance: three-step
Basically, the PARTapplicationServer enhances performance (search and index browsing).
If CADENAS_DATA is located on an extra filer then caching should be enabled for the PARTapplicationServer. On this see Section 1.3.9.9.3.6, “ Caching index files of $CADENAS_DATA on PARTapplicationServer ”.
If there is a slow network connectivity to the PARTapplicationServer then a PARTdataManager client caching should be used (Squid or RFS). See Section 1.3.9.9.2.3, “Caching on client side or at secondary locations ”.
Backup server strategy implemented by CADENAS
Details on this can be found under Section 1.4.4.1, “ "Connected servers" dialog area ”.
Setting up PARTapplicationServer as service is advantageous, because it is automatically started at start of the server and Windows mechanisms for monitoring the stability (e.g. restart at crashes) are used. (Restart delay can be adjusted via registry.)
On this see Section 1.3.9.8, “Set up PARTapplicationServer as service ”.
PLINKDB is mostly running on an already existing DB server whose availability is guaranteed by the customer (DB specific strategy)
There are some possibilities for the storage location of the pool directory:
Pool directory on the server, but with different share than CADENAS_DATA
CADENAS_DATA=/server/freigabe/data Poolverzeichnis=/server/freigabe2/data/pool
CADENAS_DATA on a dummy directory. In this case the pool directory may point to the server.
CADENAS_DATA=c:/dummydir Poolverzeichnis=/server/freigabe/data/pool
The only important thing is that the location of the pool directory is not under CADENAS_DATA; because then the RemoteFileSystem is responsible for the pool directory and thus it is ReadOnly.
Ports for PARTapplicationServer and SearchServer, configured in the configuration files differ by default, so that it is possible to drive parallel on one server, which could happen in the changeover phase.
Slowed down search when using a virtual disk
When testing on a virtual machine you have to consider, that the C disk on the server is not really local, but rather is in the network. (When testing on a real C disk the speed is possibly higher.)
When caching is used, all search indices are saved on the PARTapplicationServer. This makes sense, because accessing a local resource is faster.
Using a VM the process differs: Caching happens from the net into the net and then parts are loaded from there. This could act as a brake.
Better use an ESX host with local disks, still better an ESX host with local SSDs. In this way search times can be reduced again, especially if a search results in as many parts that they do not fit into the memory. Furthermore then there is no network bottleneck.
