Document Generator Pre-Built Function

Hi, great question!

Usually, if the Document Generator function itself is being too slow, it either takes a long time to succeed, or it runs longer than the function timeout, resulting in either a client-side timeout (timeout exception on the client side, 444 in the logs) or a server-side timeout (504 response).

However, a 503 “Timed out - server too busy” error indicates that the OCI Functions service itself is too busy. This would affect any function, not just Document Generator. I'm more of a Document Generator expert than an OCI Functions expert, but I think you could try enabling provisioned concurrency to keep a certain number of functions running and ready to respond to your requests.

If you do experience slowness with the Document Generator function itself, here are a couple things you can try:

• Reduce the number of paragraphs in the template. Currently (not necessarily in the future), performance for Word templates is often limited by the number of paragraphs.
  • Pay special attention to paragraphs in loops, since they are multiplied when the template is processed.
• Use Excel templates. We tried a new approach in our Excel implementation, which appears to have improved performance.
• Generate the document in parts. Split the data into batches, invoke the function for each batch, and finally use a different tool to merge the results back into one document.

I know those aren't great answers, so the final option is to wait for performance improvements in future releases. Our September release included better performance for Word, and we are continuing to work on it!

P.S.: Sorry we missed your post in Oracle Cloud Customer Connect. We only recently realized people were asking questions there, and now we're making improvements, including the new “Document Generator Pre-Built Function” category which you've posted this in. Thank you for the post!

Thanks for the answer and some tips. Good that there is now a category in this developer forum, as the Customer Connect forum hardly gets any attention.

Anyway, I get the timeouts when I first call the Document Generator. The startup can be really slow. Once it is started, it is okay.
However, after some time without any calls, the service goes back to sleep, and the whole slow startup process has to start again.

I've seen more questions about this on the developer forum, with some hacks to send a request to a simple “Hello World” document every x minutes just to keep the service alive.

Here is my APEX debug test output that demonstrates the startup time.

A simple document takes 90 secs the first time, between 2-3 sec running it again.

I will try provisioned concurrency and see how that helps.

Almost missed your replies, had to adjust my notification settings!

Yes, that sounds like the “cold start” described in the provisioned concurrency doc. That concept applies to any OCI function, whether pre-built or deployed by the customer.

I'm surprised it takes 90 seconds, though. I've taken a note to review cold start times and see if we can see the same thing. Debug logs should tell us whether the delay lies in the Document Generator code, or if it's taking that long for the OCI Functions service to provision a new Docker container before running Document Generator.

If you want to try a periodic keep-alive request, even an invalid request with an empty body should work. It would still hit the function and keep it alive, though it would return a 400 error.

Maybe the provisioned concurrency is relatively new. I don't remember seeing this option when I created the Document Generator Function. The option is now just a checkbox in the OCI console, very nice.

I haven't tried it yet, as I'm fist waiting on a #IF directive before I can seriously try the Document Generator Function.