GRW Distributed Mode

The default and simplest configuration of Genero Report Writer is to operate in what is called non-distributed mode.  Genero Report Writer uses Java, and in this mode, each time you produce a report, a new Java Virtual Machine (JVM) is started.  If we analyse what the JVM is doing as it produces a report, we would see that there is a startup/initialisation time, and there is a time spent producing the actual report.  This startup time can be greater than the time spent doing the unique processing for the actual report!!!  If multiple reports are produced, this startup processing time is repeated for each report.  Distributed mode is a configuration that sees the report engine started as a daemon process and this start up processing now only occurs once as the daemon is started.  When more than one report is produced, this can lead to the time spent being much much smaller.

The actual performance increase will vary depending on the type and quantity of reports.  In older versions of the documentation, we had the following …

… a 500 file PDF batch completed in 17 seconds rather then in 7 minutes …

… which gives an illustration of just how much performance improvement is possible.  It isn’t necessarily a 5%, 10% improvement, it can potentially be a very large percentage.

There are actually three modes that Genero Report Writer can operate in that is documented on this page.  The default non-distributed mode, and two distributed modes, local distributed mode and remote distributed mode.  Both distributed modes have a daemon process started, in local distributed mode this daemon is started on the same machine as the application generating the report, in remote distributed mode the difference is that the daemon is started on a different server.

The documentation gives some good examples of why you should consider distributed mode.  These include …

• It processes short reports faster. For each report in non-distributed mode, the startup time of the JVM can exceed the processing time of the report, resulting in poor overall performance. In distributed mode, the JVM is started and initialized once; for short reports, the performance improvement can be dramatic.
• It processes reports from multiple users faster, when many users start reports on the same server.
• It saves on system resources. Using a single JVM saves resources, as each JVM allocates its own memory

and it lists the advantages of a local distributed architecture …

• Local distributed mode provides for faster processing times.
• Local distributed mode allows you to manage your system on one machine..

.. and for remote the advantages it lists the following advantages  …

• Your IT policy might require the GRE and application sit on separate machines.
• Remote distributed mode allows for improved scalability. Formatting graphical reports is CPU intensive, and CPU is usually expensive on a server optimized for IO (such as servers running the DVM and/or the database.)
• Remote distributed mode allows offloading the report processing to a cheaper machine, such as a standard PC.
• The required fonts might sit on a specific machine. Specifically, a dedicated report formatting PC could be installed with Windows™, which has the additional advantage of handling fonts and printers in a user-friendly way.

The key things to consider when implementing distributed modes is …

• where are the required files required to produce the report located ? (.4rp, image files etc)?
• where is the resultant report file located ?
• what is required for the preview to work ?
• what happens if an error occurs whilst processing the report ?
• how is the daemon process started and stopped.
• what happens if the daemon process stops.

Apart from using fgl_report_configureDistributedProcessing to tell the reporting engine where the daemon is, any coding and configuration changes will need to include the above considerations.

I would expect that most production systems would evaluate and consider using a form of distributed mode for their use of Genero Report Writer.