Cancel PDF rendering jobs

[lesydimitri]

Hello!

We’ve been experiencing some issues with rendering in SysReptor recently. After investigating, we discovered that the chromium process is consuming all our CPU cores. Rendering a single PDF works fine, but when a second user attempts to render something, the system becomes overloaded, resulting in an infinite loading icon for users.

We’ve been using the same setup for SysReptor for over a year, with the following specifications:

• 4GB RAM
• 2 vCPUs

While searching for similar issues, we came across this closed issue: #231

We suspect that changes in Chromium’s behaviour are increasing the load, which our minimal system can no longer handle.
What are your thoughts on this?

Additionally, we’ve noticed that navigating through different reports/designs triggers rendering jobs, but these jobs don’t seem to terminate when leaving a page before rendering completes. Is this the intended behaviour?

[MWedl]

PDF rendering is a very CPU intensive task, especially chromium but also weasyprint. Both rendering stages slow down drastically when the system is under heavy load.

We use playwright for instrumenting chromium, which already disables many unneeded features and applies performance improvements for headless rendering. Additionally, we tested to reduce the number of chromium processes (CLI args --disable-site-isolation-trials and --renderer-process-limit=1), but that did not affect rendering times and CPU usage during our tests.

Additionally, we’ve noticed that navigating through different reports/designs triggers rendering jobs, but these jobs don’t seem to terminate when leaving a page before rendering completes. Is this the intended behaviour?

We can check if we can detect cancelled HTTP requests to abort rendering.

[lesydimitri]

Hi @MWedl

Thanks for getting back to us 🙂

We played around with it some more and came to the following conclusion:

• Generating a single report works perfectly fine, even on this setup
• Generating a second report while the first one is still generating also works fine

We came to the conclusion that most likely we have some impatient colleagues, who keep clicking "refresh pdf" or reloading the publish page. This in turn spawns too many rendering processes, hogging up all CPU resources, pretty much putting the system in a deadlock.

It would be great if you could have a look into cancelling rendering jobs in this scenario. Maybe it could also be helpful to add some progress indicators in the UI.

Wishing you a great weekend,
Dimi

[Ayweth20]

Hello,
Thanks for your work :)
I've deployed a SysReptor instance with Docker but for a few days I've noticed slowdowns on my VPS.
So I decided to take a look at what was going on and I did notice that the CPU was being used at 100% for long periods (view attachments).

These high CPU utilizations follow the modification of the pentest report.
Is it possible to stop this process in background or at least limit it so that the VPS can still function correctly?
Thanks for your response.
Have a nice day
Ayweth20

[aronmolnar]

Thank you for this report. SysReptor might indeed be the culprit of the CPU usage. So far, self-hosted SysReptor installations had no timeout for rendering job and (as this ticket states) were not cancelled, even when abandoned by the user.

The upcoming SysReptor release will introduce a default timeout of 5 minutes for rendering jobs and cancel abandoned jobs.
This should resolve your issue.