I agree. The JVM startup time may save you a few seconds, but isn't
usually the killer. It's the PDF rendering engines that tend to bog
things down a bit.
One approach we have taken is to put up a Tomcat server on a Windows box
as an appliance application and we send documents to it for processing.
Even with the passing the document across the wire with this approach
can GREATLY speed up your processing. And you get Native i connectivity
with the JT400 API's.
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------
message: 7
date: Tue, 11 May 2010 15:35:02 -0700 (PDT)
from: Nathan Andelin <nandelin@xxxxxxxxx>
subject: Re: [WEB400] PDF Performance
Aaron,
I don't think "JVM startup" is the issue, in this case. I've been
testing the utilities interactively, using QSH. I think JVM startup
only applies to the first invocation. I've been running test repeatedly
from one QSH session. If I press F12 to go back to the command line,
and try RUNJVA Hello, "Java shell already active in job.", is returned.
You evidently must use the F3 key in QSH to terminate the active JVM
instance.
We have a couple prospective customers who are asking for a grade book
solution for next fall, which would include a requirement for PDF
"report cards", that may be e-mailed to parents and students.
To really stress the utility, I tried to generate a PDF with thousand of
pages. I finally killed the utility after a couple hours. It was
generating thousands of pages per second, but in this case they weren't
PDF pages. They were memory fault pages. The system was thrashing
under memory faults.
-Nathan.
midrange.com
