Chronon Performance

Chronon 3 beta has 10x performance improvements! Check it out now.

Built to Scale

The Chronon Recorder was designed from the ground-up with scalability in mind. We believe that :

Scalability + Control over Performance > Raw Performance

This is evidenced by the rise of dynamic languages like Python, Ruby, etc which perform slower than Java but are still easy to scale. Thus although we continue to improve the performance of the Chronon Recorder with every iteration, our focus on scalability and performance control allows you to use Chronon in almost any kind of program.

Scaling with Hardware

Adding almost any kind of hardware allows Chronon to scale. E.g., adding more RAM, CPU cores or faster cores, faster disk, all allow Chronon to scale and make use of that hardware. Apparently the best and easiest way to scale Chronon is to add more RAM, which also turns out to be the cheapest hardware component available.

Choosing what to record

Additionally, Chronon also allows you to exclude portions of your program from recording. Any typical JavaEE application will run on a stack comprised of a web server, like Tomcat along with a whole bunch of 3rd party libraries like spring, hibernate, etc. Since these libraries are not written by your developers, and you probably do not have the source code for them, you cannot debug them anyway. Thus you can exclude them from recording, allowing for performance gains. You can even exclude portions of your code which are proven to be correct and which might be sensitive to performance.

For more technical details on performance tuning and scaling, please read our Performance Guide.

Using Chronon in Production and Highly Performance Sensitive Systems

It’s possible that production systems or systems which are highly sensitive to performance may not want to have the Chronon Recorder running all the time. For those cases, the Chronon Recording Server provides the Dynamic Start/Stop functionality.

What is Dynamic Start/Stop?

Dynamic Start/Stop allows you to :

  • Start/Stop recording in a running program, without pausing its execution.
  • Stopping the recorder frees up any extra resources or instrumentation done to your code.
  • Thus when the recorder is dormant/stopped, there is zero performance overhead.

Using Dynamic Start/Stop in Performance Sensitive Environments

Since highly performance sensitive programs cannot have the recorder running all the time -

  1. Recording is started at the first occurrence of a bug.
  2. The bug needs to be then reproduced only once to be captured in a Chronon Recording.
  3. Once the bug is captured, the recorder is stopped again.
  4. The Chronon Recording containing the bug can now be shared among developers to instantly find the root cause of the bug.

Advantages over traditional methods

Although not as optimal as running the recorder all the time, the use of dynamic start/stop to debug an issue is still much better than the alternatives. Currently to debug an issue on a server without Chronon, the only real option is to use log files, which has many cons:

  1. Log files to be parsed are huge, making it very tough to locate the issue.
  2. Usually finer grained, debug level logging or even additional logging needs to be added, resulting in even larger log files.
  3. The issue still needs to be reproduced many, many times, sometimes spanning the period of days/weeks before the root cause is found.
  4. All the logging statements end up cluttering the code and hiding actual business logic.

Compare that to Chronon, where even in the suboptimal case:

  1. You only need to reproduce the issue once.
  2. Our powerful time travelling debugger with post-execution logging can be used to instantly find the root cause in minutes.

Effect of Lines on Code on performance

The number of lines in your code does not have any effect on the performance of the Chronon Recorder. The performance impact and amount of data generated depends on the amount of time spent executing your code. Thus, you can have a multi-million line JavaEE program which spends most of its time waiting for I/O, so it wont generate much data and will have barely any affect on response time. On the other hand, you can have a small 10 line program that runs a super tight loop at 100% CPU usage. This will generate a lot more data.