All three applications on one server

The easiest scenario is installing all tree applications on a single server. In this case, you only need to set up and maintain a single system. Transferring data between apps in this configuration causes no additional effort. On the flipside, this can also lead to problems. Running a resource-intensive analysis can, for example, negatively impact search speed.

This section expects using this solution, although idiosyncrasies of other solutions will be explained in special sections.

FACT-Finder Analytics on a separate Server

In this scenario, Analytics is running on a separate system as not to impact your shop performance. In our experience, this is the most practical variant for most customers.

With this setup, Analytics' access to the search logfiles has to be ensured. The search application no longer needs its logfiles on the following day, so these can usually be transferred in a nightly job. This frees memory on the search system. A shared network memory is another alternative.

All three applications on separate Servers

In this scenario, Analytics and the UI have their own servers. The previous remarks in regards to data transfer apply in this case, too.

This variant's advantage is increased fine-tuning ability for server-sizing. Also, having separate systems enables you to, e.g. easily duplicate the search apllication later on, to create a staging or load-sharing system. Since the UI only communicates via APIs and doesn't need other data, this part is easily sectioned off.

As a disadvantage, this increases communication time between UI and search client.

Running multiple search applications

As mentioned before, FACT-Finder business logic resides with the search application. Should you wish to distribute load across multiple systems, or add a staging system to the live version, this application needs to be duplicated. There is no need for additional UI or Analytics applications.

Staging Application

If you need a staging environment, for example to test search configurations, the application needs to set up as shown in the above graphic. Since you are only making changes to the staging environment, this is the only connection the UI applcation needs.

Transferring configurations can be performed with either the built–in deployment function or by synchronising the resource folders, e.g. via rysync. To use the deployment feature, the search applications need to use separate ports and both have access to the hard disk memory. When synching resource folders, logfiles can be excluded. If you want both instances to have separate databases, export data and search databases need to be excluded as well.

Load sharing

To have multiple search applications process search queries requires the above setup. You can add additional applications to this scenario, like for example the prior staging environment. In that case, the different instances will have separate tasks. Should you choose this option, you need to take increased care of which data is shared or synchronised with which systems.

One instance in this configuration is the master instance. You choose whether it used used productively or as a staging environment. Connect the UI to this instance and it will distribute resources to slave instances. This can be achieved with a shared network memory. Since all apps use the same search databases, these need to be imported only once. The importing app can then make the databases available to all others. During import, the instance in question can be removed from the load sharing setup or you can reduce the number of assigned search queries as not to overload the system.

A load balancer should be set before productive search clients to effectively distribute queries. If you are using the Personalization module, this needs to be performed in the sticky-session-mode.