LORE Performance Issues

This page contains the performance analysis and tuning issues for the LORE project. It features both results of performance evaluations and open issues.

Most of the performance investigations should be application driven. As long as LORE is used for ad-hoc querying, the main performance issue is the efficient execution of the user queries. As soon as LORE is used as persistent repository for other applications, issues such as transaction through-put, scalability, and resource management become more important.

Performance issues

The following list contains the major topics for which we have some performance results or where we have identified the need to improve LORE's performance.

• Influence of Locking and Logging
  First comparisons using the tester suite indicate a 10 to 15% increase in response time having locking and logging enabled in single-transaction usage. Note that the tester application always connects and disconnects the database for each statement, which adds a substantial transaction overhead.

  Future investigations should investigate response time efficiency of real application transactions both in single-transaction and multi-transaction settings. Of special interest are lock contention and deadlock frequency in real multi-transaction applications.

• Performance comparison between native LORE and LORE/O₂ and (eventually) LORE/SQL3
  What is the overhead of using a general object-oriented (object-relational) database system as storage and execution engine versus a native implementation which is specifically tailored for LORE?

  A preliminary performance comparison between an older version of native LORE and LORE/O₂ is available.

Evaluation settings

In the following, we list different environments which can be used to perform in-depth performance evaluations.

• Benchmark databases
  In order to investigate the database performance, we need to have a test suite of different databases and queries and update statements. The evaluation should allow to investigate overall performance (transaction per seconds) as well as scalability. For a start, the evaluation can be based on some standard benchmark such as OO7 or TPC-D. In addition, it should provide for the investigation of LORE specific topics such as general path expressions, dataguides, the use of lindex and vindex etc.
• Application databases
  For some investigations it may make more sense to use an actual, typical application. For example, in order to identify performance bottlenecks due to the chosen concurrency control approach, it is best to run typical workloads against a typical database.

Evaluation tools

The following list describes some tools which can be used for investigating certain performance aspects.

• Profiling with gprof
  Profiling allows to identify performance bottlenecks due to inefficient and/or frequently called code fragments. Based on the profile information, the performance of the implementation can be improved.
• IO Performance using iostat
  Together with counting logical and physical reads within the buffer manager, iostat helps to identify IO bottlenecks.
• Lock manager performance with lshow
  LORE's lshow allows to indentify pages for which too many lock requests are issued.