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
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.
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.
The Chronon Recorder was designed from the ground-up with scalability in mind. We believe that :
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.
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.
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 allows you to :
Compare that to Chronon, where even in the suboptimal case:
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.