FOP Scalability
* This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. * I have FOP 0.20.3 running successfully on my web server and was wondering what the best way to control the scalability of it. There is a possibility that 30 + users may be requesting a PDF page at the same time and as you all know FOP is not too kind on memory usage. The PDF being produced are only 10 pages max so its just the cost of the processing on the web server that is the problem. I have seen ideas about limiting the number of FOP processes running at one time but I dont want to have users waiting for minutes for their PDF page to be displayed. Does any one have any other ideas ?
RE: FOP Scalability
Title: RE: FOP Scalability * This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. * I realise that more servers could be an answer, but unfortunately this is not likely to happen Is there a way to limit the memory allocation that FOP uses. (but then that poses the problem of what to do if we run out) It is imperative that the FOP does not fail, as it generating recipts to our users.. Answers on a postcard ... -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: 10 May 2002 12:42 To: [EMAIL PROTECTED] Subject: Re: FOP Scalability You could have additional servers (can be low-cost) and use JMS to post jobs to a queue. These additional servers will listen on the queue (automatic load-balancing through use of JMS), generate PDFs and send a message back that the file is ready to be taken by the front servlet. I have FOP 0.20.3 running successfully on my web server and was wondering what the best way to control the scalability of it. There is a possibility that 30 + users may be requesting a PDF page at the same time and as you all know FOP is not too kind on memory usage. The PDF being produced are only 10 pages max so its just the cost of the processing on the web server that is the problem. I have seen ideas about limiting the number of FOP processes running at one time but I dont want to have users waiting for minutes for their PDF page to be displayed. Does any one have any other ideas ? Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch The original of this email has been scanned for viruses by the Government Secure Intranet (GSI) virus scanning service supplied exclusively by Cable Wireless in partnership with MessageLabs. GSI users - for further details, please contact the GSI Nerve Centre, or browse GNC 003/2002 at http://www.gsi.gov.uk/main/new2002notices.htm In case of problems, please call your organisations IT helpdesk. *** This email has been received from an external party and has been swept for the presence of computer viruses. ***
Re: FOP Scalability
I've never really done this for real, but I think I'd do it like this: On the first HTTP-Request, the job gets sent on the JMS queue. The user receives a Please wait.. page with an automatic refresh and and ID that will be returned to the server upon refresh. Use the ID in a message selector to see whether the job with the respective ID has already finished. If not, send the Please wait... again. I think this should work, but I may be wrong. I'm sure there are others on the list who have done similar things. I think I remember some posts on one of the FOP lists. Browsing the mail archive might be interesting. This is an interesting suggestion - but how does the notification to the Front Controller allow a user to know when the document is ready without some type of polling? We have a similar setup, but a polling applet is being used - which we would love to get rid of. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch
FOP scalability
Does anyone know how efficient FOP might be when running on Sun Solaris box? If I am using XSL template objects to optimize performance, how might response times vary with increased number of users? Assume the Solaris box is a single 420R with 4 cpus and 4GB of RAM. Any help is this regard and ideas about making my FOP-based rendering solution more scalable is greatly appreciated. Mike Zahigian, Sr. Programmer/Systems Analyst Amgen Business Information Systems (805) 447-2819 mailto:[EMAIL PROTECTED]