Forum How do I...?

Prince is slow when running in AWS Lambda

yossarian21
I set up Prince as an AWS Lambda, following the guide referenced by Prince's documentation: https://medium.com/@bruce_39084/setting-up-prince-on-aws-lambda-and-api-gateway-4d524dcb035b

I am finding Prince to be very slow in this environment. For just the prince run (log right before prince executes and right after), it takes 2-4s the first time the lambda runs (Duration: 3269.74 ms according to Cloudwatch) and 260-400ms on subsequent runs. This is generating a simple "hello world" PDF that takes ~80ms to generate when running Prince on my laptop.

Is there any way to get information from Prince about what it is spending time on?
mikeday
We are investigating this ourselves, Lambdas do have some startup cost and overhead but it's difficult to say at the moment whether there could be other factors involved.
alfie
Hi yossarian21,

Could you please try upping the RAM allocated? I have found that going from the default 128Mb to 1024Mb significantly increases speed.
yossarian21
Hi,

I had the Lambda memory set to 256 MB. Increasing to 1024 MB seems to improve the performance by 50-100ms on average (some data points generating a simple PDF: 189ms, 193ms, 144ms, 209ms, 148ms) so I will try allocating a higher memory baseline.

We also added a lambda "warmer" via an event that runs every 5 minutes and invokes the Lambda. This keeps the Lambda alive (avoiding Lambda cold start problem) and also avoid slow Prince first time execution times when the Lambda is alive but Prince has not run yet. I assume there is a startup cost in finding and caching fonts the first time Prince runs on a new environment.

I think we're in the ballpark now in terms of performance.
alfie
That sounds like good news.

Yes you're right, there is a startup cost on the first request, but having a job to keep it warm sounds like a great idea. Thanks for the tip!
peterh
In our side, we're using Lambda as well, and are having issues with performance. With HTML that's around 4-6 mb, it's taking over a minute. I know the html is pretty large, and has lots of css in it. Is there a way to improve the performance?

Here's how long it takes:
Duration: 158784.52 ms Billed Duration: 158785 ms Memory Size: 4048 MB Max Memory Used: 410 MB

I've got the memory up to 4048, but it's only using 410 MB of that, so I don't think it's a memory issue.

Thanks.
mikeday
Is the HTML referencing any remote resources like images or style sheets that will require HTTP requests? How big is the final PDF file?
tdhanai@zscaler.com
Hi mikeday, I have a similar issue. We are creating a PDF file from a document with a lot of images and creating the PDF file is taking around 20-26 seconds. Without images, same document takes around 550ms.

I'm not doing it using Lambda though, I'm using prince on the terminal and the time I've given is what prince takes to create the PDF file. I'm on a Macbook Pro 2021. Would you say it could be faster on a server?
mikeday
Are the images local files or being downloaded over HTTP? How big are they?
tdhanai@zscaler.com
Downloaded over HTTP. They are ranging from 50kb to 200 kb. There are more than 200 of them. I tried using local files, which is significantly faster and gives around 6.5 seconds, but it still is not good enough.
mikeday
What format are the images? JPEG will typically be faster than PNG as PNG images must be decompressed and recompressed to embed in PDF.
tdhanai@zscaler.com
Most are PNGs. Is there a way to use PNG images as is? Without decompressing and recompressing? How much more space would you say a 100kb PNG would take without compressing, compared to a compressed PNG.

Edited by tdhanai@zscaler.com

mikeday
Currently PNG will always be processed by Prince so I would expect them to be slower than JPEG in general, although it's difficult to know how significant that factor is for your particular document without testing.
tdhanai@zscaler.com
Could you tell me how PNGs are compressed here?
mikeday
I'm not sure how to answer the question; PNGs are compressed using the "deflate" compression algorithm as implemented by zlib.
tdhanai@zscaler.com
Thanks for your help.