CMS Fiona as well as the webserver and most databases can be configured to use the available system resources more efficiently.
The CMS settings referred to in this section can be modified in the tuning.xml configuration file.
Regarding performance, the database is a critical component, because the editorial system (i.e. the Content Management Server) as well as the export (i.e. the Template Engine) access it.
The Content Management Server serves the requests of the GUI users. For the response times to be as short as possible, a master server starts a configurable minimum and maximum number of slaves. Each of these slaves processes an also configurable number of requests and is then (if further requests exist) replaced with a new slave by the master server. Each of these slaves connects to the database on its own.
The export is also performed by a configurable number of slaves working simultaneously and using its own database connection.
Whether the database is able to handle the required number of connections to the Content Manager and the Template Engine slaves depends, on the one hand, on the database licence. Normally, the licence restricts the number of connections.
On the other hand, the number of connections that can be used efficiently is influenced by the available RAM (with memory access) or the network load (with network access). Local databases are always faster than databases attached via the network.
Particularly Oracle databases are often operated with the default (not optimized) values for the cache sizes, for example. Furthermore, the performance of an Oracle database can be enhanced significantly by placing Control Files, Redo Log Files, Temporary Files, Rollback Files, and Data Files on different harddisks. This analogously applies to databases by other vendors.
The export is a computationally expensive task performed, as said above, by several slaves. Since every slave potentially can take the computing time of one cpu and also performs other simple tasks (such as reading and writing files), the export should be configured to use two slaves per CPU.
Indexing and searching are also computationally intensive processes. If the Search Server has been integrated into the editorial system and the live-server side, the corresponding indexes are updated each time content is modified. However, normally the indexing process does not have a relevant impact on performance because content is more often requested than added (except when a large amount of data is uploaded).
If a large number of search requests is issued via the live pages, the load caused by this can be compensated by installing faster or additional CPUs.
For the live server we recommend to increase the number of processes provided if the requests cannot be answered fast enough.
Websites that contain many dynamic components such as PHP or Java pages require more computational power which can be provided by installing a faster or an additional CPU. This also applies even to a larger degree if SSL is used since encryption is computationally expensive as well.
Please contact JustRelate if you wish to optimize your database or your Trifork Application Server in the context of your CMS Fiona projects.