Kieker is a monitoring and analysis framework implemented primarily in Java, but is also supports other programming languages on the monitoring side, like C, Perl, C#, or VB. The Java monitoring side can use an extensive set of methods to store measurements in files, queues, or databases. For non JVM languages, the Kieker Data Bridge (KDB) provides access to these different methods via a set of connectors for different programming languages or transfer protocols. The KDB provides connectors accepting binary or textual measurement records via TCP or JMS, which are interpreted and compiled into Kieker IMonitoringRecords
. Kieker analysis reader components use a similar approach to deserialize measurements form a data store or message queue. While the two different tools realize similar behavior, they are implemented quite differently. This results in a duplication in code and features, which is an undesirable situation and should be resolved by a common infrastructure. This post discusses the present state in Kieker and sketches different solutions to improve the framework.
Present Kieker Reader Implementation
The present reader implementations differ greatly in the way they receive records. The JMSReader
accepts only ObjectMessage
s of IMonitoringRecord
s and discards JMS TextMessage
s, the PipeReader
handles in-memory IMonitoringRecords. Only the DbReader
and the FSReader
s relies on functionality provided by AbstractMonitoringRecord to deserialize records from files or the database.
AbstractMonitoringRecord
provides primarily two static methods, which are actually factory methods, to produce an IMonitoringRecord
from a given input. Due to the age of Kieker the method supports two different construction models. The first method is createFromArray
, which requires a class object representing the type of the record and an array of objects, which are used to initialize the record. The second method is createFromStringArray
, which requires a class object for the record type and a String
array containing String
serializations of all values.
Both methods use a getConstructor call for each deserialization attempt, when utilizing the new IMonitoringRecord.Factory
API and check the presence of this interface for every call. This is quite expensive. I wrote a small program to determine the impact of different operations in Java. The program is far from perfect and the results are not calibrated. However, certain operations are that expensive that the results are still valuable.
gitlab@build.se.informatik.uni-kiel.de:rju/reflectioncost.git
Presently, the program test four different Java reflection API based cases. First, it measures the cost of the query for a constructor of a class object and its invocation. Second, it measures only the cost of the invocation of the constructor. Third, the cost for class.isAssignableFrom
is measured, which is used in Kieker to check whether a class has a given interface. And fourth, the cost for a change of access rights of a field is determined. The test was executed on a QuadCore Xeon machine, but the system performance is not important to understand the results.
# | Case | Calls per micro second |
---|---|---|
1. | find and call constructor | 2.7543 |
2. | call constructor | 27.0715 |
3. | class has interface | 326.8133 |
4. | access privileged info | 1.0281 |
It is pretty obvious by this test, that querying for a constructor with getConstructor
is very expensive, as the second test shows that calling the constructor is almost 10 times faster than querying and calling.
public static final IMonitoringRecord createFromArray(final Class clazz, final Object[] values) throws MonitoringRecordException { try { if (IMonitoringRecord.Factory.class.isAssignableFrom(clazz)) { // Factory interface present final Constructor constructor = clazz.getConstructor(Object[].class); return constructor.newInstance((Object) values); } else { // try ordinary method final IMonitoringRecord record = clazz.newInstance(); record.initFromArray(values); return record; } [...] }
As the above code snippet shows, the present createFromArray
call is expensive. Florian and Jan already worked on a caching feature to reduce the constructor queries.
The other very expensive call is a call of java.security.AccessController.doPrivileged
which is used in case number 4. It is used to allow access to static constant array property in a monitoring record, which contains a list of all logged data fields in form of class types.
This call is also very expensive and in addition not good practice for Java programs. If the property must be public accessible, for whatever reason, it is better to make it public instead of making it public at runtime. A getter for the TYPES
array cannot be used with the present API, as the getter can only be called after object is constructed. The code in AbstractMonitoringRecord.createFromStringArray
requires the TYPES array before construction. the getter getValueTypes
cannot be defined as static. Therefore, the only direct solution would be a public accessible TYPES array. However, there are other solutions possible based on annotations, which are available in Java 5.
Kieker Data Bridge Deserialization
The Kieker Data Bridge (KDB) provides connectivity to the Kieker infrastructure for non JVM languages. Its execution can be divided in three phases: initialization, record processing, and termination.
The initialization phase processes command line parameters, which steer the configuration. In context of the deserialization the important actions are. Loading jars providing IMonitoringRecord
types. The KDB registers all jars at its class loader and subsequently reads a mapping file for IMonitoringRecord
types. The mapping file contains entries for each record type in form of an positive integer id followed by an equal sign (=) and the full-qualified class name of a record type. This style is similar to the mapping file for FSDirectoryReaders
, which prefix lines with a $. The mapping file is read and for each entry the class loader is asked for the class representation. The result is added to a record map. The record map provided to the KDB connector, which compiles a lookup map. This map contains a reference to the constructor and the types array of a record identified by the record id as key of each entry. After that the connector establishes its service.
The lookup map compilation uses the same routines to determine the property TYPES
array and the constructor as the AbstractMonitoringRecord
, but it utilizes these costly functions in the initialization phase and not during record deserialization. In the upcoming Kieker 1.8 release, this has been fixed for the TYPES
array through an internal cache in typesForClass
used in createFromArray
, but not in createFromStringArray
. Furthermore, the constructor lookup is also expensive and should be cached too in future.
The deserialization happens in the KDB in dedicated routines, which fetch one record from the input stream or the message they process. They first read on integer from the stream of message to find the right constructor and types array. Each property is then read from the stream or message steered by the property types array. The selection of the correct reader is realized through a large if-then-else construct. Different then the processBinaryInputFile
routine of the FSDirectoryReader
, primitive types and wrapper classes are handled with separate cases, and the equality of types is tested with the equals method rather than the equals operator.
Preliminary measurements showed that type comparison with the equals operator is 1.42% to 2.02% slower than the equals method, determined by the measure.lang.CompareOperatorOrMethodMain
program located in the ReflectionCost
repository. The measure.lang.IfThenElseMain
program compared the different realizations of if-then-else type selections, while the equals operator vs. method used in these realization play only a minor role, it makes a big difference to use the condensed implementation from the file system reader where two types are checked in every if reducing the number of if-then-else structures by half. The file system reader code realized 1.4 to 1.5 operations per micro second, where the other is able to handle 1.6 to 1.68 operations per micro second. This indicates that an or-operation (||) in Java is much more expensive than a jump.
Discussion
All the test program code is available in the ReflectionCost
repository. It most likely needs some improvements to be able to really provide stable and valid results. However, the present results advise to perform some changes, or at least, the changes should be considered when discussing further Kieker design improvements.
File readers and KDB connectors share similar code for the deserialization of records. The actual interpretation of the serialized record information is done in the reader, while the AbstractMonitoringRecord
class provides the instance mechanism. The code in createFromArray
is rather complex for two reasons. First, it presently supports two record implementations, which is not really necessary, as the record types in kieker.common.record
all support the new interface. And second, it fetches the class constructor in every call. This could be improved by a cache or better, by changing the method as follows and implement the cache separately.
public static final IMonitoringRecord createFromArray(final Constructor constructor, final Object[] values) throws MonitoringRecordException { try { return constructor.newInstance(values); } catch (final SecurityException ex) { throw new MonitoringRecordException("Failed to instatiate new monitoring record of type " + constructor.getName(), ex); } catch (final IllegalArgumentException ex) { throw new MonitoringRecordException("Failed to instatiate new monitoring record of type " + constructor.getName(), ex); } catch (final InstantiationException ex) { throw new MonitoringRecordException("Failed to instatiate new monitoring record of type " + constructor.getName(), ex); } catch (final IllegalAccessException ex) { throw new MonitoringRecordException("Failed to instatiate new monitoring record of type " + constructor.getName(), ex); } catch (final InvocationTargetException ex) { throw new MonitoringRecordException("Failed to instatiate new monitoring record of type " + constructor.getName(), ex); } }
Instead of passing a class type, the method expects an already resolved constructor. Furthermore, the support for ancient Kieker record classes has been removed. For those who have private IMonitoringRecord
classes utilizing those old structures, can easily upgrade to the present interface. I implemented this modification is a local branch. It can be pushed if their is an interest for these modifications.
The FSDirectoryReader
contains only one type per file. In that case a cache for the types array and the constructor is not required. I also advice against an “behind the scene” cache if not all deserializers require it. Rather, I propose a caching method similar to the one realized in the KDB, whcih could be realized in a factory for IMonitoringRecord
s, like the present functions for record creation.
In our present code, we have four kinds of record sources: text strings, binary messages, input streams, and byte arrays. I doubt that this will change much in future. I therefore propose to define four deserialization functions in the factory, which can then be used in all the readers and connectors.
The KDB connectors are presently not able to process Kieker Configuration
objects. This should be changed in future bringing them closer to a form already provided by the readers. It might not be possible to use the readers API for the connectors, but that is yet to be seen. Maybe we can come up with a common structure usable for both context.
And finally, the present Kieker record factory is also the abstract class for IMonitoringRecord
s. It might be advisable to move the factory code to a separate class. A lot of basic Java classes implement the factory together with the class, but in many modern frameworks they are implemented in different classes increasing the readability. As IMonitoringRecord
s are in fact entity classes, it makes more sense to me to implement the factory in a different class.
Summary
This post is a short situation report on different yet similar parts of the Kieker framework, which could use some overhaul. I proposed several changes, which might be useful in future. As some of my conclusions are based on a hacked-together performance evaluation, these results might have to be revised.