hello experts,
Context
My client would be using AEM Forms (6.5v on Prem, OSGi based) setup with add-on for only generating PDFs. The PDF would be generated using OutputService/ FormService/ AssemblerService API based on 3rd party incoming xml input (based on mapped XDP template).
Some stats to help provide better tuning tips, client have following as load parameters:
- 500 PDF will be generated per week (peak load included)
- some 2 to 5 high resolution static PDF will be merged too
- actual PDF size could be 10 MB to 50 MB (it also includes images and promotional PDFs)
Please provide following tuning tip:
- What could be ideal AEM start up parameter as tuning tip for JVM arg - Xmx, PermGen etc?
- any guidelines for the usages of APIs - com.adobe.fd.output.api.OutputService, com.adobe.fd.forms.api.FormsService and com.adobe.fd.assembler.service.AssemblerService
- any other AEM Forms - Document Services API tuning tip?
- xml payload tuning tip
- PDF generation tuning tip (for Unix based AEM Forms setup)
Views
Replies
Total Likes
The load mentioned and the use case explained is a typical implementation that most customers leverage with AEM Forms document services. This document[0] provides a basic guideline for performance tuning with AEM Forms instance.
These document services use XMLForm processes under the hood, so you may want to tune this value (the current default value for PoolMax is 4). The actual value to set depends on the hardware configuration and the expected usage in your environment.
For optimal use, the lower limit of PoolMax should not less than the number of available CPUs. Generally, the upper limit should be set to twice the number of CPUs cores on your server.
So if the number of cores on the system is 4, then you can set the value of XMLForm service processes to 8 max. This will ensure eight parallel processes are spawned to cater to the incoming requests. You can set this value under xmlform.bmc.name config on the configuration manager with a Maximum number of processes to launch value.
Thank you for taking out time to respond, appreciate helping us. Few in-line follow up questions:
The doc you referred is for AEM Forms 6.4 ours is 6.5 (found here [1]) however apart from JVM tuning tip like 8g java heap there is not much info. So was wondering if more details are available?
>> For optimal use, the lower limit of PoolMax should not less than the number of available CPUs. Generally, the upper limit should be set to twice the number of CPUs cores on your server.
I see you are referring to config -
http://localhost:4502/system/console/configMgr/com.adobe.document.XMLFormService however here is one confusion:
1. there is no parameter to configure for lower limit of PoolMax.
There is just one:
- Maximum number of processes to launch (XMLFormService.poolmax) - which is set to 4
- So please clarify if this is what you meant to be twice the CPU core no#?
2. I do not find any documentation from Adobe for XMLFormService? so was wondering what is the use of {Maximum memory size for pdfl} (XMLFormService.PDFLMemorySize) how and what can we configure this as well?
thank you for your response.
The details mentioned in this performance-tuning document are generic, and customers need to tweak these parameters/do capacity planning based on the anticipated load. So you may have to test the load against a set of values of heap/core/XMLForm processes and then fine-tune these values based on the result/observations.
XMLForm service processes have to be set to a single value (i.e, max), but I gave an example so that you can decide on any value minimum and maximum based on the number of cores. So if the number of cores on the system is 4, then you can set the value of XMLForm service processes to 4(lower limit) and 8 (higher/max limit).
The PDF Library (PDFL) is used for creating, manipulating, and printing PDF files, but we never updated this memory size for any of the customers, given the use-case. May have to check internally- please raise a support ticket to get more insights.
thank you for the follow up.
>> The PDF Library (PDFL) is used for creating, manipulating, and printing PDF files, but we never updated this memory size for any of the customers, given the use-case. May have to check internally- please raise a support ticket to get more insights.
Sure, we are approaching Adobe support for the same. In general XMLFormService config doc is missing, that should also be created/ updated and made public.
Views
Likes
Replies
Views
Likes
Replies