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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.