That's probably related to IO contention, iText does a lot of small reads. If
you do everything in memory what do you get? In any case, iText doesn't lock
anything and any thread performance problems should be addressed to the JVM.
Paulo
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Robert Meyer
> Sent: Sunday, August 03, 2008 10:52 PM
> To: itext-questions@lists.sourceforge.net
> Subject: [iText-questions] iText & multithreading delays
>
> I'm having problems using iText in a multi-threaded environment.
>
> I built a small test app to see how iText would perform when
> used on a machine with multiple cpu's, and the results were
> not what I expected.
>
> The test code is fairly simple; I built a class that extends
> Thread:
>
> class mythread extends Thread
> {
> }
>
> and within that class's run method, I do some simple iText
> things, like:
>
> create a PdfReader.
> create a PdfStamper.
> loop thru all pages of the input document, stamping
> some text on each page.
> close the Stamper.
> close the Reader.
> output a line to the console reporting the total elapsed time
> since the run() method was entered.
>
> The main code of this test application handles the details of
> creating a fixed number of instances of the 'mythread' object,
> (the actual number is hardcoded in the module), and reads a simple
> text file that drives the process (the text file contains one
> line for each pdf file to be created).
>
> I've been careful to ensure that none of the threads attempt to
> use the same input file, or create the same output file.
>
> The text file contains 10 lines of input, meaning 10 pdf files
> will be created.
>
> I'm running the test on a machine with 2 quad-core Intel processors,
> for a total of 8 cpu's.
>
> Here's the interesting (and not so thrilling) part: as I increase
> the number of threads that will be used to process files (and
> therefore
> increase the number of cpu's that will be used), the time required for
> each thread to complete increases significantly.
>
> here are some approximate values of thread count vs. elapsed run
> time per thread:
>
> threads - elapsed time (in ms) per thread
> 1 - 800
> 2 - 1600
> 4 - 4500
> 8 - 10000
>
> This seemed very strange to me, and I immediately assumed the problem
> was that I was doing something wrong regarding my use of threads.
>
> With that in mind, I replaced the 'mythread' class and all it's iText
> calls with something that was iText-free, but still opened files and
> gobbled up a bunch of cpu time.
>
> This time I got what I was expecting: as more threads/cpus were
> allocated
> to the job, the amount of work accomplished increased accordingly -
> and not
> just a little. And this time, the amount of elapsed time
> taken for each
> thread to complete remained consistent, regardless of the total number
> of threads being executed.
>
> Believing now that my thread handling was not the problem, I put the
> iText
> code back in place, and started looking at where the delays were
> occurring.
> I soon discovered that the delays were happening in the
> Stamper.close()
> function, in PdfStamperImp.java.
>
> I grabbed the iText source, added some print statements in various
> places
> throughout the Stamper.close() function, and determined that the code
> causing the delays is within this loop (in the close() method in
> PdfStamperImp.java):
>
> for (int k = 1; k < reader.getXrefSize(); ++k) {
> PdfObject obj = reader.getPdfObjectRelease(k);
> if (obj != null && skip != k) {
> addToBody(obj, getNewObjectNumber(reader, k, 0), k != rootN);
> }
>
>
> At this point I thought it would make more sense to post my
> problem here
> and hope that someone can offer some explanation as to why processing
> slows down drastically as more threads are used.
>
> Thanks in advance for any assistance.
> Robert Meyer.
Aviso Legal:
Esta mensagem é destinada exclusivamente ao destinatário. Pode conter
informação confidencial ou legalmente protegida. A incorrecta transmissão desta
mensagem não significa a perca de confidencialidade. Se esta mensagem for
recebida por engano, por favor envie-a de volta para o remetente e apague-a do
seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de
usar, revelar ou distribuir qualquer parte desta mensagem.
Disclaimer:
This message is destined exclusively to the intended receiver. It may contain
confidential or legally protected information. The incorrect transmission of
this message does not mean the loss of its confidentiality. If this message is
received by mistake, please send it back to the sender and delete it from your
system immediately. It is forbidden to any person who is not the intended
receiver to use, distribute or copy any part of this message.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
