Recommended args in jvm

[Murilocb123]

I have a tomcat server with Birt Report running, but I have performance loss, is there any recommended configuration to use with the birt report on the servers? The number of requests in one day is very large.

I know that this is something you discover by testing it, but I would like to know the opinion of people who are more experienced with the tool.

My birt version is 4.4

[hvbtup]

Can you provide some numbers, please?
From my experience, the number of requests/day is quite irrelevant.
What actually matters is the number of concurrent requests.
You'll have to find a way to limit this. This may include writing your own BIRT server software.
Pls note that too many reports at the same time will not only cause performance loss regarding BIRT itself (OS memory, JVM heap, CPU stress), but also to your database.

[MuriloIPM]

Hi, I'm the same person as the question, one is my personal account and the one I'm talking about is my professional account. We have around 16289 reports printed in 11 hours of a day, giving 24 reports per minute. It depends a lot on the report, but most take less than a minute, some take much longer, but these normal reports usually take about 10 seconds.

[hvbtup]

Probably you should consider tuning your reports as a first step (and your SQL statements if these are using JDBC).
We are generating lots of lab analysis reports with quite complex layouts, these usually take only 2-4 seconds.

What I can say for sure is that when the JVM is near full heap memory usage, it will slow down significantly, because it has to spend most time with garbage collection.
As I already told you on Stackoverflow, it is important to limit the degree of parallelism.
You can also consider to use more JVM processes or more server machines.

And it can be useful to divide the reports into two (or more) classes (as we did):
a) small/normal reports
b) big reports

We consider a report "big", when it needs a lot of time or memory (in many cases, both).

For example you can use one JVM A for the small and normal reports and a second JVM B for the big reports.

If you give both VMs 1 GB of heap, then A can probably handle 10 parallel reports, and B should handle max. 2 parallel reports.

Of course these numbers are made up, but it may work as a starting point.

Anyway, you have to experiment and run realistic load tests.

[hvbtup]

Note: The numbers you have given are bigger, but comparable to the numbers of some of our clients. I'm not sure, but some of our clients are running ~5000 reports on a single machine per day.
I think your numbers are in a range where a single machine is not enough.

If you calculate optimistically and assume that every report takes just 10 seconds (ignoring the long-running monsters) and they are distributed evenly around these 11 hours, and you create 16000 reports in that time:

11h = 11 x 60 x 60 secs = 39600 secs

16.000 reports x 10 secs/report = 160000 secs.

So in this optimal case, you are running 4 reports in parallel at any given time.

This could work on a single machine under these assumptions.
But the assumptions are much too optimistic, because there will always be peak loads - and the long-running monster reports.

So what I would do as a first step:

• Use a second server for the monster-reports
• Give the JVMs enough heap size
• Use some kind of resource management to limit the number of concurrent reports to e.g. 8 for the small/normal report process and to 1 or 2 for the big-report process.

Limiting the number of concurrent reports may seem counter-intuitive, but it can improve the throughput.
Compare this to the situation for virtual servers (VMs, not JVMs):
When the expected work load is high, one should adjust the number of virtual CPUs for VMs to the number of physical CPUs -- overprovisioning is only good as long as the VMs are idle most of the time.