What is Chronon?

Chronon is like a DVR for your Java applications.

Chronon Recording Server

Chronon records every change made by every single line of code in your program while it is executing, from the very beginning to the end of the program. The recording is saved to a file and can then be transferred across machines and also shared amoung team members

Chronon Time Traveling Debugger

Team members can use the Chronon Recording file to play back the entire execution of the Java program on their desktops and find the root cause of any issues instantly.

Chronon Performance

Minimal overhead

The Chronon Recorder puts minimal overhead on your applications. The overhead is not much more than what simple logging inside your application, making Chronon suitable for even the most intensive applications. We have spent years perfecting our ‘prediction’ technology which analyses your java bytecode as it is loaded and creates predictions as to how it will execute. Thus only the most minimal, non-deterministic portions of your applications are recorded and even those in a highly compressed format. Thats much, much less than what traditional logging would generate.

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.

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.

Advantages over Logging

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

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

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

Not Affected by Lines of Code

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.