RE: [xep-support] XEP performance issue

Hiral,

My guess is that important factors impacting performance are the complexity of your FO, the number and nature of referenced graphics
and the number of tables present in the document.

We call XEP from a roll-your-own servlet on a Windows2000 Server (4 GB of RAM) where fairly complex documents of (on the average)
500 pages containing 50 vector graphics and 50 bitmap graphics are generated in about one minute.
This excludes all kind of pre-processing of the original input, where graphic conversion (such as EPS into PDF) takes the biggest
part of the resources. Pre-processing can take up to two minutes for a 500-page document, resulting in a total processing time
comparable to the one you mention.

We found that disk I/O and available memory is more important than CPU speed.

Could your performance problem be related to memory shortage, maybe disk swapping?
Our empiric rule-of-thumb (which I will not endeavour to prove) states that a XEP thread may need up to 1 MB of RAM per page to be
produced. As we set a maximum heap size of 3 GB to the JVM, we allow only 5 PDF generation threads to run simultaneously. This is
done by queueing requests on the servlet (we also found a few memory leaks in our code :-/).
With the queueing mechanism, there have been no apparent performance problems when considering the individual jobs. Of course, when
there would be 100 requests pending, the queue would also take considerable time to be emptied.

Best regards,

--
Jacques Deseyne
User Documentation Dept.
S.W.I.F.T. - Society for Worldwide Interbank Financial Telecommunication
Avenue Adele, 1
B-1310 La Hulpe
Belgium
+32 2 655 3111
http://www.swift.com
 
This e-mail and any attachments thereto may contain information which is confidential and/or proprietary and are intended for the
sole use of the recipient(s) named above. It is not intended to create or affect any contractual arrangements between the parties.
If you have received this e-mail in error, please immediately notify the sender and delete the mail. Thank you for your
co-operation. 
________________________________
	From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com] On Behalf Of Hiral Parikh
	Sent: Tuesday, November 16, 2004 3:31 PM
	To: xep-support@renderx.com
	Subject: [xep-support] XEP performance issue
	
	
	Hi, 
	We are preparing PDF documents from FO files using XEP 3.8.1, XEP Cocoon Connector 1.2 and Cocoon 2.1.5.1. 
	Cocoon's JVM has been allocated around 2.1 GB of memory. 
	Following are the results of our testing: 
	Concurrent Users: 1 
	Time to process 400-pg book: ~4 minutes 
	Concurrent Users: 10 
	Time to process 400-pg book: Initially, the first book started with 4 minutes but then the processing time took longer and
longer and the last (165th) book took around 2 hours.
	How many concurrent users does XEP support before its performance slows down? 
	Is there any fine tuning we can do to improve this? 
	We are also planning to install XEP 4.0 but I am not sure if that will make any major changes in  performance. Your early
reply and help is greatly appreciated.
	Thanks, 
	Hiral Parikh 
	____________________________________________________ 
	Hiral Parikh 
	Sr. Software Engineer 
	Ames-On-Demand 
	30, Dane Street 
	Somerville, MA - 02143 
	617-684-1042 

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html