Loading...
 

Performance (infrastructure)

Performance Infrastructure

If applications are to be developed and used with InstantView®, care must be taken to ensure that performance is accepted by users. Because the CyberEnterprise® architecture is multi-tiered, various bottlenecks can occur:

  • InstantView® code (see also here)
  • Database
  • Network
  • connected tools (e.g. MS-Office)

The pure InstantView® code is usually processed very quickly. Nevertheless, care should be taken that no unnecessary loops, queries, etc. are performed. As the InstantView® code also regulates access to the database, it is particularly important to ensure that there are no long open transactions, otherwise locking conflicts may occur. Since the ClassiX® objects are very strongly interlinked, a few simple instructions can ensure that a large number of objects are locked and therefore no longer accessible for others.

The database itself is usually also sufficiently fast. However, problems can occur if very complex queries are executed that are not accelerated by an index. Another bottleneck can be the cooperation between the ObjectStore server and the cache manager on the client side, if many different objects are touched. In this case, the pages on which the objects are located and which are probably not kept in the client cache are copied to the client via the network.

For the reasons mentioned above, there are two ways to increase performance. On the one hand, a maximum fast network and a lot of RAM should be used on the clients to maximise the transfer rate and the client cache. On the other hand, the objects should be placed in the database in such a way that on the one hand the objects that are often used together are close together (on one page), so that they are transferred in one go. On the other hand, the objects should be distributed in such a way that the objects not needed in a transaction are located on other pages so that they are not lured along.

Resource Management

Process CPU load Hard disk utilisation Network load Memory usage
Server Not intensive. Intensive. Intensive. Not intensive.
Low usage for communication with client.
Client Can be intensive;
depending on the application 		ObjectStore does not access the local hard disk.
The application itself, however, has the option. 		Can be intensive. Can be very intense.
Mapping of many data into virtual memory.
Cache Manager Not intensive. Not intensive. Not intensive.
Sends and receives short messages. 		Not intensive.

In summary, in addition to generally fast processors, what matters is a lot of working memory on the client side, fast hard disks on the server side and a fast network connection between client and server. The transfer of data from the server to the client can be controlled by the environment variable CX_GLOBAL_FETCH_POLICY, a separation between purely reading and writing - and thus potentially blocking - access to the database can be set by the environment variable CX_DB_DEFAULT_MODE.

In the following, possibilities are shown for identifying and eliminating possible weaknesses in performance: