Notes on reliability and performance/caching
Notes on performance: three-step
Basically, the PARTapplicationServer improves performance (search and index browsing).
If CADENAS_DATA is located on an extra file, caching should be activated for the PARTapplicationServer. See Section 1.3.5.8.3.7, “ Caching index files of $CADENAS_DATA on PARTapplicationServer ”.
If the client has a poor network connection to the PARTapplicationServer, then PARTdataManager Client caching should be activated (Squid or RFS). See Section 1.3.5.8.2.4, “Caching on client side or at secondary locations ”.
Backup server strategy implemented by CADENAS
You can find details on this under Section 1.4.4.1, “ Connected servers " dialog area ”.
Setting up PARTapplicationServer as a service has the advantage that it is automatically started when the server computer is started and Windows mechanisms are used to monitor stability, e.g. restart in case of a crash (after one minute [can be further reduced via registry]).
On this see Section 1.3.5.7, “ Set up PARTapplicationServer as a service ”.
PLINKDB usually runs on an existing DB server whose availability is guaranteed by the customer (DB-specific strategies)
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/share/data Poolverzeichnis=/server/share2/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/share/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.
The ports set in the configuration files for the PARTapplicationServer and the search server are different by default, so that you can run in parallel on one server during the changeover phase.
Slowing down the search when using a virtual hard disk
When testing on a virtual machine, please note that the C disk on the server is not really local, but is located in the network. (The speed may be higher with a "real" C disk)
If caching is used, all search indexes are cached on the PARTapplicationServer. This makes sense because access to local resources 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.
