Register   |  Login
  Search

db4o runtime statistics

Posted @ 10/12/2009 10:31 AM By Adriano Verona
Posted in | 3 Comments
Once a project hits production status and gets deployed it is in the wild (at least from the point of view of the development team) and it requires constant monitoring from IT. The more important the process, the more  important becomes the ability to monitor the application behavior so IT members can take proactive actions and avoid potential problems.

Also, monitoring support can be a life/time saver during development, allowing developers to spot performance issues, wrong assumptions and the like before the application reaches the magical production status. Traditional  enterprise applications (such RDBMS, application servers, EJB containers, etc) has been delivering such monitoring capabilities either through well established platform mechanisms (MBeans, Performance Counters) or custom approaches.

While db4o provides API hooks to add custom logging for performance relevant figures, until now there's been no out-of-the-box way to have an ad hoc look under the hood before getting into real coding, or a convenient, standardized mechanism to monitor and display these values for a long-running process over a period of time.

We are proud to announce that starting with version 7.12 various "Runtime Statistics" will be exposed by db4o; we do believe that such statistics can provide useful information for developers and/or IT administrators who can consume this information either through the platform infrastructure (you can learn more details about .Net and Java specifics) or an API.

As of version 7.12 the following statistics will be made available:
  • Queries
    • # class scans / sec
      A class scan means that db4o will need to read each object of a given class in order to figure out whether the object should be included in the
      result set of a query. In this case indexing the parent referencing field would avoid this costly operation and improve query times.

    • # queries / sec
      Number of SODA queries executed per second.

    • Average query execution time
      The time to retrieve the list of ids for the matching objects (this doesn't take the time to activate the objects into account)

    • # unoptimized native queries / sec
      Number of native queries (per second) that were not optimized. Developers should strive to run only optimized native queries in order to
      get the best possible performance.

    • # native queries / sec
      Total number of native queries (either optimized or not) executed per second.

  • FreeSpaceManager
    • average slot size
      The average size of free storage slots available.
      Smaller slots are less likely to be reused.

    • # free slots
      A high number of free slots indicates a high level of fragmentation.

    • # reused slots / sec
      Number of reused free slots per second.

    • # bytes in free space management
      A high value (with a high value of #free slots) is a good indication that defragmenting the database may bring performance improvements.  

  • Reference System
    • # objects in reference system
      Total number of objects in the db4o reference system.

  • IO
    • # bytes read / sec
    • # bytes written / sec
    • # reads / sec
    • # writes / sec
    • # syncs / sec

  • Networking
    • Bytes Sent/Received
      Bytes sent/received from/to clients.

    • Connected Clients
      Number of currently connected clients.

    • Messages sent
      Number of messages sent from/to db4o clients and servers. Developers can use this statistic as an indicator whenever their object models are
      driving db4o to exchange too many messages between clients / server. This statistic is also useful to help developers to tweak
      prefetchDepth/ prefetchObjectCount configuration in order to minimize messages exchange between client / servers.  

  • .Net Specific (For more details about .Net specifics follow the link in the end of this post)
Note that since gathering these statistics does introduce some performance overhead (for most of then this overhead is so small that it is immeasurable) each set of runtime statistics (Queries, FreeSpaceManager, ReferenceSystem, etc.) must be configured independently (so you can decide which ones you want to track and pay the performance hit only for that ones).

One selects the category(ies) he is interested in publishing statistics for by adding an object of the respective xxxxxMonitoringSupport() class to db4o configuration as in the following sample:

IEmbeddedConfiguration config = Db4oEmbedded.NewConfiguration();

// Query
config.Common.Add(new QueryMonitoringSupport());
config.Common.Add(new NativeQueryMonitoringSupport());

// Networking
config.Common.Add(new NetworkingMonitoringSupport());

// IO
config.Common.Add(new IOMonitoringSupport());

// Reference System:
config.Common.Add(new ReferenceSystemMonitoringSupport());

// FreeSpaceManager
config.Common.Add(new FreespaceMonitoringSupport());

Last, but not least, these statistics are per object container (database file) so you can monitor as many open databases as you want.

If you can't wait for this functionality we invite you to go and download db4o continuous build version and give it a try, but please remember that it's a work in progress for while, so you may expect to see changes in the API and / or list of actual statistics supported.

For more details on how to consume these statistics, samples and more details, please, read the following blog posts:

Have fun! (and provide feedback ;)

Db4o team!
Return TopTrackbackPrintPermalink
Previous Entry: New typehandler on the block: System.Guid
Next Entry: Watching over db4o's shoulders the Java way

Comments

Was it good for you, too?Join the discussion » ,but you need to login first before you make comments.