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

High Startup Resources #3704

Closed
sidhant92 opened this issue Aug 8, 2022 · 5 comments
Closed

High Startup Resources #3704

sidhant92 opened this issue Aug 8, 2022 · 5 comments
Assignees
Milestone

Comments

@sidhant92
Copy link

Hi, I am trying to deploy Micronaut v3.5.4 to production. What I noticed is, that when I try to directly run the jar it takes about ~700 ms to startup and around ~25% CPU when given a single core. But the same changes to ~1800ms and 300% CPU when starting the same jar with datadog-java agent.
Is this really expected because it is beating the purpose of fast startups and low resources overhead?

@sidhant92
Copy link
Author

The used memory just after bootup is also significantly more

@mcculls mcculls self-assigned this Sep 9, 2022
@mcculls
Copy link
Contributor

mcculls commented Sep 9, 2022

Hi @sidhant92 the tracer does need to use CPU and heap during startup (and warmup of the application) to analyse which classes to instrument for tracing purposes. We are looking at ways to reduce this overhead and I'll update this issue when we have something you can test.

@mcculls
Copy link
Contributor

mcculls commented May 15, 2023

The 1.14.0 release contains a number of startup improvements that could help here

@mcculls mcculls added this to the 1.14.0 milestone Aug 31, 2023
@mcculls
Copy link
Contributor

mcculls commented Aug 31, 2023

Startup overhead was reduced by #5026 - this feature also lets you persist type-matching data using DD_RESOLVER_CACHE_DIR=<writable-directory> which means less overhead when restarting.

There have been further minor improvements since then, I recommend trying the latest release 1.20.0

@mcculls mcculls closed this as completed Aug 31, 2023
@sidhant92
Copy link
Author

@mcculls is there any possibility of caching the entire bytecode transformations? for example once I run with the agent, it does all the transformations at runtime and from future runs I dont need to do this?

Use case: due to the agent during initial boot CPU requirement is high to bring the container up within a certain time period. Want to reduce that time to bring the container up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants