To create a new container of a docker image, is the of this image impact the creation time of container ?
1 Like
To an extent yes, but in most cases where you have a large image it’s the time to pull the image from a registry that is most significant. For an individual node though, that overhead only happens on the first pull and even when that images changes it is likely you will use existing layers from the image cache.
The word ‘large’ of course is a relative term, as are ‘fast’ and ‘slow’ when considering performance. In general though it is good practice for images where you control the build, to keep them a small as possible. This is not only because of resource use but also a sensible security measure to reduce the attack surface. There are lots of techniques to achieve that from choosing the right base image, multi-stage build, the order and number of Dockerfile commands, and so on. If you google docker image size you will find many good sources of information on this subject.
In more extreme cases when you are deploying to a cluster, you might consider pre-loading images as those nodes come up.
1 Like
@goffinf you mean more the size of image is, more the creation time of container is ?
As I said, the size of the image does have some impact on container start-up time (i.e, a larger image might take longer to launch than one that is smaller) but tbh this is only one of a number of considerations, … and you haven’t even said what you mean by ‘large’ or ‘small’ yet. Do you have some specific images in mind. Have you tried launching containers from them ? … what did you observe ?
You may be falling into the trap of early optimisation before you really know whether you are actually focusing on the right thing or even if you actually have a performance issue … which you very well may not.
What I was suggesting in my earlier response was that the start up time of a container that is 100MB and one that is say, 1GB, may very well be different and the larger one may take longer to become available, but it is unlikely to be really significant.
Also, let’s be very clear, what I’m comparing here is 2 images that basically run the SAME process but have simply been built differently. Perhaps one has been optimised with a multi-stage build process to leave behind only the minimum software needed, and the other (larger) image has not. But fundamentally these two container perform exactly the same function.
It’s not really reliable for you to extrapolate in any more general sense when comparing images that do very different things. Indeed it would be perfectly possible for an image of larger size to start and be ready to receive requests before a smaller one. It depends on so many other things, such as the language, dependencies on other services, what work might be required during start up, and so on. Imagine one tiny container starts but as part of its initial work needs to connect to a database. It might have to wait for the database to become ready, create or wait for a connection to become available from a pool, the caller container may need to authenticate, it might need to inject some initial data, and so on … it could take any length of time. On the other hand, a container launched form an image many times the size of the small one, but which has no such dependencies and no significant work to do on launch, may be available in a fraction of the time of the smaller container. Does that make sense ?
What I would strongly encourage you to do is, build your containerised application, push your images to your favoured registry, create the flow to launch you app (pulling from your registry), and observe the behaviours (if necessary capturing timings under various load conditions). If things don’t happen as you expect then you will have an idea where the problem is, and a repeatable baseline approach to retest once you have made some adjustments.
I would avoid making any judgements at all about performance until you’ve actually run your stack ‘in the wild’.
HTHs
Fraser.
1 Like
we can say also that a Docker image is built up from a series of layers, each layer represents an instruction/command in the image Dockerfile and has a specific size. Some of the defined instructions on the Docker image may not used in the creation of a container.