Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Reporting] Optimize images buffers handling on PDF generation #136537

Merged
merged 3 commits into from
Jul 20, 2022

Conversation

dokmic
Copy link
Contributor

@dokmic dokmic commented Jul 18, 2022

Summary

Resolves #129719.

The original idea was to reuse the virtual file system to pass forward the image buffers to the pdfmake library. But it's only supported in version 0.3, which is still in the beta.

After inspecting the version 0.2 source code and the underlying pdfkit library, there was discovered a more elegant way to achieve the same result. The thing is that the pdfmake doesn't perform any transformations of the image source and just forwards that down to the pdfkit. The trick was to convert the transferred ArrayBuffer to a Buffer instance to avoid inefficient instantiation on the pdfkit side.

After running some local tests against sample data and measuring memory consumption using process.memoryUsage, there was some decrease in memory usage.

For maintainers

@dokmic dokmic added review (Deprecated) Feature:Reporting Use Reporting:Screenshot, Reporting:CSV, or Reporting:Framework instead release_note:skip Skip the PR/issue when compiling release notes Team:AppServicesUx v8.4.0 labels Jul 18, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-services (Team:AppServicesUx)

Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dokmic these changes look great, good job digging into the pdfkit library - hopefully a new release will come out soon!

Just curious, what magnitude of memory reduction where you seeing?

Otherwise happy for this to be merged.

content,
content: _.cloneDeepWith(content, (value) =>
// The `pdfkit` library used underneath is using `Buffer.from(new Uint8Array(src))` construction to cast the image source.
// According to the Node.js docs, it will create a copy of the source `ArrayBuffer` which should be avoided.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

@dokmic
Copy link
Contributor Author

dokmic commented Jul 20, 2022

Just curious, what magnitude of memory reduction where you seeing?

@jloleysens It's hard to get a relative value out of the measurements I took because all the values vary. But I saw a decrease in numbers for the rss value. That seemed like ~3x less memory for the PDF generation, which matches the changes.

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

✅ unchanged

History

  • 💚 Build #58712 succeeded 763f2e5466a251f263b9789260b8b080ae96dd1d
  • 💔 Build #58256 failed 9abb97d4819bc73b4f1fe1234e2919abea3e1042

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@dokmic dokmic merged commit 816264d into elastic:main Jul 20, 2022
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jul 20, 2022
@dokmic dokmic deleted the feature/129719 branch July 21, 2022 08:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting (Deprecated) Feature:Reporting Use Reporting:Screenshot, Reporting:CSV, or Reporting:Framework instead release_note:skip Skip the PR/issue when compiling release notes review v8.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Screenshotting] Optimise how image buffers are held in memory for PDFs
5 participants