Replies: 1 comment 4 replies
-
podman run Would stop it from checking for a newer version of the image. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello all,
Context:
I'm working with the Quarkus and OpenJDK teams, exploring various things which we could do to optimize for being able to scale horizontally with very quick reaction times. At high level, the goal is to be able to react to an increase in load which wasn't expected by starting additional application replicas; since in the Java world starting new applications can be rather slow, people normally tend to have multiple additional nodes running as spares. By reducing the time it takes for newly started nodes to make themselves useful we hope to reduce such waste.
Another goal of this initiative is also to save resources and memory at steady state, but such aspects will follow later and are not relevant to the following discussion, other than to provide context of where I'm eventually headed.
Goal
To best evaluate among all the crazy ideas to improve bootstrap times, I need to make sure we measure bootstrap times reliably.
In particular by "bootstrap time" I mean the wallclock time between triggering the request for a new application node and it being able to successully respond to external input.
My main focus is in optimising the actual Quarkus and OpenJDK code to simply start faster, use less memory in the process, etc.. as that's where I'm relatively competent with, but I've only used podman to run tests so admittedly I'm not an expert in it.
As we expect our audience to primarily target podman, and primarily develop web applications or wep APIs, I want to make sure whatever we plan works well in synergy with podman; to make sure of this I've decided that our measurement stopwatch should start from
podman run ...
, and stop when we get a successful reply to an HTTP request.Doing so far
I'm using
--read-only --rm
as that should help improve timings, and should match expected use case so I'm not considering it cheating; it's useful for me to try to minimize the container run times so to better spot which of our application changes are worth it.I'm also limiting resources, to better reflect typical use:
--cpus 4 --cpuset-mems=0 --memory 400m
: we want to optimize for smallish systems and highly dense microservices. I might reduce this further, as other upcoming optimisations might make further reductions realistically achievable for our end users.I'm mapping the 8080 port to the host:
-p 8080:8080
, I need this to hit that HTTP endpoint and verify its readiness.Question 1: checking the base assumption, suggestions
Is this reasonable so far? Would you have suggestions for any other flag I should use in this context?
In particular I'm not sure how to measure the base overhead of podman: how to separate the portion of time in which the new container is being "setup" (pardon if that's the wrong terminology) from the time my application is booting. I can of course derive deltas from different varsions of my application, but would there be a way to measure the podman portion?
Question 2: networking
To my horror, when recently travelling and running my measurement scripts in a location where network was very spotty, I noticed all my bootstrap times where significantly slower than usual.
I'm suspecting that some non-local network traffic is triggered during the container initialization. Is this plausible, and how could I prevent this?
I understand that preventing this call from happening might not be a "realistic scenario" anymore, but it would help to make sure my comparisons are fair and reproducible, so if there's a way to either disable this or emulate this reliably that would be great.
Many thanks!
Beta Was this translation helpful? Give feedback.
All reactions