slow performance - timeout on 1000+ records

  • Hi,

    I'm investigating the possibilities to migrate from Crystal Reports reporting to JSReport for our accounting solution. Currently I have a POC in which i can print a very simple report containing 50 client records.
    Since some of our customers produce reports containing 50.0000+ records, I did some tests with somewhat larger data: up to a 1000 records (8 display fields) it works, but given 2000 records i already get a timeout.

        public static string Generate(string jsonData)
            ILocalUtilityReportingService rsu;
            var rs = new LocalReporting();
            rs.RunInDirectory(Path.Combine(Directory.GetCurrentDirectory(), "jsreport"));
            rs.Configure(cfg => cfg.AllowedLocalFilesAccess().FileSystemStore().BaseUrlAsWorkingDirectory());
            rsu = rs.AsUtility().Create();
            jsonData = "{\"klanten\":" + jsonData + "}";
            var customerReport = rsu.RenderByNameAsync("klanten", jsonData).Result;  // HERE Timeout Error: pdf generation not completed after 30000ms (1). 
            return string.Empty;

    I'm working from within .NET, with chrome-pdf, handlebars engine.
    For now my data is provided in a json string, but data is pulled out of ms sql server.

    Before I invest more time in the POC: any ideas or examples whether it is possible to work with such large data (output will sometimes be 100's of A4 pages)

  • The performance and render time is based mainly on the report js/css/html complexity. You can render 1000pages in 3seconds but it can also take 3 minutes.
    Try to increase the timeout (cfg.ReportTimeout) and see how it actually takes.
    It could also help to check the logs, where is the rendering stuck. This is typically in the chrome-pdf html->pdf conversion, but I may be wrong.

  • @Bart-Slegers - we moved from Crystal to JSReport almost 3 years ago. Obviously, these are two completely different architectures; so comparisons aren't really valid. The number of records is almost irrelevant. For our reports they take approximately 5 pages per seconds. One other reason for performance degradation was dynamic headers or footers (for example, if the footer says page x of y). We found some settings that speed footers up.
    But if we estimate that the number of pages is going to be very large, then we split the job and submit to JSReport in parallel, and then merge the parts using PDFSharp.
    Overall, we found that using some analysis, and asking questions on this forum, we were able to achieve acceptable performance even in very complex reports.
    Note: We are only JSReport customer; @jan_blaha doesn't pay me for saying good things about his software; although I don't mind ;)

Log in to reply

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.