Skip to end of metadata
Go to start of metadata
Chronon 3
Running into performance issues?
Check out Chronon 3 beta with 10x performance improvement!
Information below NOT for Chronon 3

The information below is applicable to the Chronon 2 recorder, not Chronon 3.

Use 64 bit

This is the number one way to get better performance. Using more memory will greatly increase the performance of Chronon.
We recommend using a 64 bit JVM in all stages of using Chronon, ie, use a 64 bit JVM while recording, unpacking and also use a 64 bit version of Eclipse.

Dont forget to set the -Xms and -Xmx values for the JVM to a high value so that it can actually take advantage of all the memory on your system.
A lot of systems have 4 gb or more memory but they dont set the -Xms and -Xmx JVM arguments thus not allowing the JVM to take advantage of all that system memory.

Use Compressed Pointers

If you are using a 64 bit Sun Hotspot VM update 14 or higher, use the -XX:+UseCompressedOops option. It will have a visible, positive impact on the performance of Chronon.

Increase Permgen

You might want to use -XX:MaxPermSize=600m to increase the permgen size. Replace 600m with a number that works for you.

Use in Production and Highly Performance Sensitive Systems

Production systems or systems which are highly sensitive to performance may not want to have the Chronon Recorder running all the time.

In those cases, you can use the Dynamic Start/Stop feature of the Chronon Recorder, from within the Chronon Recording Server to start the recorder only when needed.

Usually in these cases users prefer to start the recorder the very first time they hit a bug.
In this case, the recorder is started, the bug is reproduced only once, and then the recorder is stopped again.
On stopping the recorder, any extra resources used by it are cleared.

Now that the bug is captured in a Chronon Recording, it can be shared among developers who can debug the issue in parallel.

This approach of starting the recorder on hitting a bug, although not as optimal as running it all the time, is still much better than the alternatives.
Currently those alternatives basically boil down to looking at huge log files and turning up the logging level and even adding more logging to the code.
In any case, the bug still needs to be reproduced tons of times before it can finally be debugged.
The value Chronon adds here is that you only need to reproduce the issue once, and then you can use the Chronon Time Travelling Debugger to debug it instantly.

Scaling with Hardware


More memory

As mentioned above, putting more memory in your system will dramatically improve the performance of Chronon.
You will need a 64 bit system to take advantage of the extra memory, since a 32 bit JVM doesnt allow using more than 1.2gb of memory.

More cores

All parts of Chronon are highly multithreaded and benefit greatly from multiple cores.
A quad core machine will perform much, much better than a dual core machine.

Scaling Software

Note:

The settings described here can be configured in the Eclipse plugin by going to Window> Preferences> Chronon> <component>

In the case of running standalone, the settings for the recorder can be configured in the Recorder Configuration File.

Recorder

The performance of the recorder is greatly affected by the amount of memory allocated to it.
At minimum, we recommend giving the jvm 1 gb of memory when running with the Chronon recorder.

Also the more cores you have, the more flusher threads you can spawn, which can keep clearing up the memory buffer used by Chronon.
The best way to think about the number of flusher threads is , number of cores - number of application threads.
So if you have a single threaded application running on a quad core machine, you should use 3 flusher threads.

Read more about how the recorder scales with system resources.

Unpacker

Unpacking is highly cpu and memory intensive. The unpacker is fully concurrent and is designed to scale with more resources you can throw at it, so that you can unpack faster.
Since the unpacker is fully concurrent, the number of unpacker threads should be equal to the number of physical cores on your box, ie 4 threads for a quad core machine.

Also unpacking speed is highly dependent on the memory.
The unpacker is designed to flush out data in huge chunks only, so as to increase the unpacking speed and decrease disk IO.
For this purpose it keeps a lot of data in memory and if you give the jvm too little memory, you can run into a cycle where the Java GC is constantly interrupting and not letting the unpacker proceed.
For optimal performance give between 2-3gb of memory to the unpacker.
Set the -Xms value same as or near the -Xmx value, othewise the Java GC will still try to keep kicking in to keep the JVM from using too much memory.

For unpacking large recordings, it is highly recommended to use the Standalone Unpacker provided with the Chronon Recording Server download, instead of using Eclipse.
If you use Eclipse to unpack very large recordings, it is very likely that you will run into an Out Of Memory error unless you edit eclipse.ini and set the -Xmx values manually.

Some Notes:

  1. It is normal for the unpacker to take a little long to unpack large recordings (>100mb in packed size).
  2. We highly recommend using the JRockit JVM, instead of the HotSpot JVM, when using the standalone unpacker.
    The unpacker is highly dependent on memory, and setting a -Xmx value of 8g instead of 2g can result in the unpack time dropping from 1 hour to 10 minutes.
    The Hotspot jvm doesnt handle heaps >2g very well and will stall. The JRockit jvm on the other hand will have no problems handling bigger heaps, and is thus recommended. 
  3. The Chronon Recorder on the other hand,  wont run into issues with large heap sizes even on the HotSpot vm because it uses a custom memory management scheme which doesnt impact the Garbage Collector.


 

Eclipse Time travelling debugger

Since when you open a recording for the first time, the unpacker runs in the same process as eclipse, the rules about memory allocation for the unpacker apply to eclipse too.
You can give eclipse more memory by editing the eclipse/eclipse.ini file.
When you install the Chronon plugin, it automatically increases the amount of memory eclipse can use.

You will also notice improved performance while debugging if you give eclispe more memory, since disk IO will be greatly reduced.

Note that just by setting the -Xms and -Xmx to a high value, eclipse does not start taking up more memory in your system.
Setting those to a high value only allows the JVM to use all the extra memory on your system when needed.
It is no use having a system with 4gb of memory if you dont allow eclipse to use any of it.