Whenever an an application has been developed with ClassiX®, it is necessary to make sure, that the users accept this performance. Since the ClassiX® architecture consists of multiple layers, bottleneck situations in the following areas are possible:
Pure InstantView® code will generally be processed very quickly. Nevertheless it is necessary to make sure, that there are no redundant loops, queries etc.. Since InstantView® code also regulates the database access, it is necessary, that there are no long and open transactions, since this causes locking conflicts. Since the ClassiX® objects are cross-linked to each other, a few simple statements can have the effect, that a large number of objects gets locked and can therefore no longer be accessed for others.
The database itself is generally also fast enough. Problems can appear when processing highly complex queries, which are not accelerated via index. Another bottleneck situation can be the cooperation between the ObjectStore server and the cache manager on client side, when touching many different objects. In this case, pages with the objects and which are supposably not kept in the client cache, are copied to the client via network.
There are two ways of increasing performance. On the one hand by using a network with maximum speed and lots of memory for the client to maximize transfer rate and client cache. On the other hand by placing objects that are often used in combination close to each other (on a page) in the database, so they can be passed at once. In turn, objects that are not used in a transaction should be on different pages, so they are not also getting locked.
The following shows how to identify weaknesses and how to get rid of them.