Hi,
Regarding to my question a few days ago (iText's performance difference on
WebLogic and Tomcat). I did more research and here is how:
Observation:
1. WebLogic is hosted on Solaris 10 x86, not Windows as I thought. Sorry
for my mistake
2. The PDF service is slower when hosted on Solaris than on Windows,
using the same server (i.e. WebLogic or Tomcat). The performance difference is
more obvious (50%-70% more running time) when exporting large tables (in our
case, table with 15-20 columns and 3000 rows takes 4-8 minutes (depending on
platform). No image in PDF except a few logos)
So I profiled the WebLogic using jvisualvm. The WebLogic environment is
iText version: 2.1.7
WebLogic version: 11g
JDK version: 1.6 update 20
JVM Options:
-server -Xms768m -Xmx768m -XX:CompileThreshold=8000 -XX:PermSize=48m
-XX:MaxPermSize=128m -Xverify:none -da
CPU: 1.86 GHz
Memory: 2 GB
Jvisualvm shows that when exporting that large PDF table, the used heap size
keeping fluctuating violently between 250 and 550 MB. CPU usage also
fluctuates along with the used heap size, but ¾ of them are GC activities.
So my guess is that although itext might be slower on Solaris, the root cause
is that the table is not exported in a memory-friendly way: our code first puts
all stuff in that table into a single Element and then calls
Document.add(Element) once.
To fix memory usage issue, I used the idea in the example code: add only part
of table to Document, clear table body rows, and repeat until the whole table
is added (below is from the example code):
//inside a loop
if (row % 50 == 0) {
document.add(table);
table.deleteBodyRows();
table.setSkipFirstHeader(true);
}
Such change reduced the running time to 1/5 - 1/8 of original case's on Tomcat
6.0 hosted on Windows. The performance improvement is impressive, but such
optimization brings some questions:
1. How do you apply such optimization to nested tables? Because our
nested tables are constructed recursively, if I pass the Document into the
structure, the document.add will be called in an recursive order instead of the
sequential order I am looking for. This difference in order will ruin the
layout.
2. If first part is infeasible, my optimization would be that I will
still put everything into one element and call Document.add(Element) only once,
but I will also attach a page end event that by the end of each page, the event
catches table(s) inserted, and deletes rows already inserted. I think this way
would reduce memory usage, but is it doable?
Another question, I notice iText version 5 changed the package name, but
Spring framework API is using old "lowagie" package name. Is there any plan of
solving this incompatibility issue?
Sorry for the long message. I hope I have explained my scenario clearly.
Thanks,
George
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
