Jump to content
Changes to the Jaspersoft community edition download ×

Recommended Posts

By: Jatan Rajvanshi - jatanr

large reports

2005-07-31 17:36

Hi Everyone,


I am in the process of evaluating Jasper Reports for our needs, and I had some performance related questions.


A big concern of mine is how Jasper Reports handles large amounts of report data. I tried to look through the forum, but did not get a clear idea on this. I do not have a working understanding of the code as yet, but I have gone through a few examples.


As an example, lets consider that I have a large report (say 100,000 records or more) and I want to show it on the screen (and further, click on a button to export it in any format). Lets first consider the displaying on the screen part. While displaying on the screen, i want to page the report with each page size, say 50 rows. As I understand, when a report is to be shown on the screen, we need to call the JasperFillManager.fillReport() method which returns a JasperPrint object. What is the structure of this object? Does filling a report mean getting all the data from the database and creating this JasperPrint object? Does this mean that this single object contains all the report data? If that is the case, what happens if the number of rows returned is really high (say 100,000 row), as mentioned above). Running out of memory is one issue, but the time taken to run such a query, and then populating this object will be huge, even though at one time, I want to display only 50 rows. So in such a scenario, how does it work? Is the whole report (100,000 rows) in the memory while only a small part of the report is being displayed on the screen? Or is the query run each time the page is navigated, so that the report data is obtained in small manageable chunks? Is the latter approach possible with the given implementations of JRDataSource (JRResultSetDataSource)?


Also, there will be a heavy reliance on stored procedures for reporting functionality. In such a case, If I want to implement the above requirement with a stored procedure, my understanding is that I will need to write my own implementation of JRDataSource for calling a stored procedure, which probably will need to take care of paging internally. Does this thought process make sense? By the look of it, it seems like I will have to do a lot of custom coding above the Jasper Reports layer so that I can call the stored procedure implementation of JRDataSource to manage paging and other functionality. This is very unclear.


Any help on the above concerns will be really appreciated. I am making the push for Jasper Reports, but I need to show substantial benefits.


Thanks a lot for your time..



By: John Armstrong - siberian1967

RE: large reports

2005-07-31 18:08

JRDatasources are very easy to implement.


Using them you can display as much or as little data as you want, you pass the JRDataSource into the XML for parsing, it is indifferent to the contents for the most part.


What you will lose with this method is the native 'page n f y' sort of functionality, basically anything that requires a full dataset for accuracy. Thats ok, it barely works anyhow (grin) and you can get around it by creating your own paging variables and attaching them to the report as attributes.


In this scenario, only what you put into the JRDataSource will be in memory (assuming your select is selective about what it pulls from the DB).


Now, when you go to export you'll need to get the entire thing. Don't worry, I regularly have customers pulling 100k+ records (3000 master reports, each with a subreport for line-items) and the performance hit is barely noticeable. Jasper is very efficient.


So go for it!




By: Jatan Rajvanshi - jatanr

RE: large reports

2005-07-31 19:24

Thanks a lot for the quick response! :)


So as I understand, I would need to implement paging if I want to go with stored procedure implementation. It makes complete sense.


Thanks a lot!



By: John Armstrong - siberian1967

RE: large reports

2005-07-31 19:41

Correct, I toyed around with that but we decided to ditch in browser reporting and only provide XML/PDF output.


Good luck! I hope you enjoy Jasper as much as we have.



By: Doug Berkland - berkland

RE: large reports

2005-07-31 20:05

JasperReports handles large amount of data fairly well. If you are running a machine that runs into problems with the large amount, recent changes have been made to JasperReports that use the hard drive to store some fo the report as it is generated to eliminate OutOfMemoryErrors that some experience.


The entire report is created before any of it can be displayed. This is so you can have summary fields (e.g. total of field X from the entire recordset) on the first page.


You shouldn't need to do anything special for paging, unless you only want to pull a portion of your dataset at once. Even using a stored procedure shouldn't require a custom implementation of JRDataSource. JRResultSetDataSource can be passed a JDBC ResultSet that was created using a stored procedure.


The "Page X of Y" works fine. The one criticism I have is that some of the report variable names lead newbies to making mistakes when they first try to implement "Page X of Y".



By: John Armstrong - siberian1967

RE: large reports

2005-07-31 20:21

Does Page X of Y work in subreports now?


When I last checked it didn't and Teodor said it couldn't since the Master had no knowledge of what the Sub was doing.





By: Doug Berkland - berkland

RE: large reports

2005-07-31 20:28

The way we use subreports, the "Page X of Y" stays in the master report. The "Page X of Y" usually needs to be at the top or bottom of the page so it isn't a problem putting it on the master report.



By: John Armstrong - siberian1967

RE: large reports

2005-07-31 20:36

Thats a nice way of saying 'Yes, its still broken' :)


Our master report is one page and the subreport can be anywhere from 1 to infinity pages long. We typically see a sub-report with 100 pages or so. Thats where sub-report Page X of Y would be great.

Link to comment
Share on other sites

  • 4 years later...
  • Replies 2
  • Created
  • Last Reply

Top Posters In This Topic

  • 3 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...