[xep-support] Generate pdf

Nikolai Grigoriev grig at renderx.com
Wed Jan 30 08:56:13 PST 2002


Emmanuel,

> A first study, show us that FOP have a problem in charge 
> capacity and need memory. I would like to have some 
> bench about your product XEP

In general, XEP is not so different from FOP in this respect. 
It consumes slightly less memory, but may be even slower.
However, XEP is thread-safe by design, and its formatting 
functions are static; therefore you can format several documents 
in parallel with a single instance of XEP classes, instantiating
all static structures (fonts, hyphenation data, parsing data) 
only once for several concurrent threads. Your documents
are small, and your users are many, so this feature may be
quite useful in your case.

> Could you send me some elements for an application who have 
> 600 concurrents users. The pdf file generate is only one page 
> for each user.

To format a single page normally takes about 2-3 MB of net Java heap,
and 2-3 seconds of CPU time (though the figures depend greatly on layout 
complexity and JDK version - 1.3.x is _much_ better in this respect). 
If you plan to run XEP in 600 parallel processes simultaneously, you are 
very likely to incur into memory problems. At these loads, some 
dispatching/synchronization schemes will be necessary: you will have 
to limit the number of XEP processing threads somehow e.g. by buffering 
user requests in a semaphore-controlled queue, limiting the number of working
sockets that a network connection may open, etc. etc.

Needless to say, the figures above are very approximate. The only reliable 
method to determine actual memory consumption is to conduct experiments 
on your machine. The evaluation version contains classes that will help 
you in benchmarking XEP's impact on your system. 

The standard command-line interface to XEP, com.renderx.FO2PDF.Driver,
can accept several files as arguments. The files are processed one after 
another in sequential order, using one and the same instance of XEP 
without re-initializing XEP classes or restarting Java. This will let you 
estimate net overheads of XEP when running it as a component.

There is a more evolved driver class, also available in the evaluation version:
com.renderx.FO2PDF.MTDriver. It has the same interface as the previous one,
but the files are processed in parallel threads. Don't be afraid by
progress indication messages from separate threads being mixed up: 
in Java API, each thread is given its own SAX-based logging interface. 
Running this class with many sample documents as arguments will let you 
study the effects of several formatting threads running simultaneously. 
In our experiments,  up to 15-20 one-page documents could fit into the default
Java heap of 64 MB on Windows NT / JDK 1.3.1.

Best regards,
Nikolai Grigoriev
RenderX

-------------------
By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html



More information about the Xep-support mailing list