OK, welcome to our next session about fast and lighter container image uploading.
I'm happy to introduce you about D4C.
I want you to see, the leverage there are the three things for faster and lighter container
image collecting.
Some products like IoT, now use containers in low bandwidth network.
To stop or operate containers users need to put images.
We continue images and transfer to be a similar in talks or ISP in talks, but such
in a talks sometimes only limited bundleizing.
If you want to use more applications or libraries, the size of the content images is increasing.
Images size causes some problems in operating in a lower bundleized networks.
It causes network congestion or cost increases and it takes much time to provision a
operating image.
So, the performance takes to much time.
So, right way to understand the first image operating is required.
Current images have player-based image, but some messages already pointed out that player-based
image has a limitation to provide efficient provide updates if sent to it.
This video describes the time to update image from post-based 1, 3, 1, 2, 1, 3, 1,
2, putting image takes much time, especially in all bundleized networks.
Apologies to improve time to update images has already proposed 1, 5, 1, they do the
application.
Like starlight or ZTE, it turns first only required files or chunks, as like this here,
servers sends only a new or update file to the client.
But this works the star room to reduce data size for image operating.
Fireware audiences, the application can not handle partial modifications on files if
it is sent to it.
200 applications is sent to the default see, my default see due to the data encosing, which
can handle such a partial modifies as a data.
You provide right-hand processing, this is a data encoding best image operating approach.
In default see, servers generates a data between now or the image and a new image.
This data is bundled into 1 content called update bundle.
Then grant, because this update bundle and receive it, then apply the data to all the
image.
And then now, grants can launch a container from a new image.
This video shows components in default see, servers generates some data in your
advance and stores them.
When client requests, it spreads bundle, server sends the stored data or merge is
then, merge data as required.
Then, client receives update bundle and starts content with snapshot programming and
update file system called DCFS.
The default see uses merge strategy.
This is a technique to generate quickly as quickly as possible.
In default see, the data generation is performed in a 5-oriented approach.
If file is operated, the data encoding algorithm generates a data.
If the file is newly created, the default see compress the file and bundle it bundle them into
a data bundle.
And containers require manifest on the configs.
So, updates and manifest context are also bundled into update bundle.
I mentioned in the previous slides, default see uses data encoding to get a better
compression.
But to utilize data encoding, we need to solve an issue.
The update is generating data takes much time.
This video describes a compression ratio and the time to generate data.
DSDF generates better more compressed data, but it takes much time to generate data.
And as a file size increases, the time is also increased.
Longer generation increases over a period of time.
So, we need to solve a question.
How to provide decreased data quickly.
So, as a solution, default see data generation approach is generating some data in advance
and merging them on request.
I found that merging data does not take much time compared to generating data from scratch.
In this method, data is between version i and version i plus 1 is generated in advance
and merging them when the request is being requested.
In Korean, to request version with version 0 and version 0 and 2.
From version 0 to version 1.
Sabah already generated the corresponding data so simple responses.
But in Korean, to request a data between version 1 to version 3.
Sabah does not have the actual data.
But the Sabah can provide it by merging version 1 to version 3.
And version 2 and version 3.
So, the Sabah merge is 8 and response the result.
So, quarantine implementation and default see supports two data and code links.
DSL and XDXDXDXDX3.
To support multiple data and code links, default see provides a primary system with a simple API.
The programming needs to implement three functions.
Generate and merge.
Generate, simply generate data from base or predated file.
And apply, also simply apply data on base file and provides a place file.
The SAMH function merge is very important in default see is data generation strategy.
This receives two data files and merge them and generate one data.
This is used on Sabah side.
And default see has two supporting two programs, BSV and XDXDXDXDXDXD.
But this does not provide the merge function.
So, default see present없이 profiles inventory, magnify.
And XSDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD vendor's,
Video script current surroundings is playing very well with this data link.
Now, D4C has D3FS to provide a faster data apprine.
D4C applies data tasks when the file is opened.
And so there is no need to apply all the data
to thousands or more files at all once.
In a problem, when a process works,
the vector is easily or get database D3FS
and it turns the corresponding metadata is the metadata
embedded in the database apprine to bundle.
So then, when the process opens the file,
the corresponding all file and the data file is applied
to and the new file is generated.
This file is stored on a low-car storage.
And competing really, really,
if the vendor process is a file,
simply, D3FS CpCopy data contents
from the stored results and it adds it to the process.
So I implemented D4C for continuity
and performed some evaluation on these environments.
The first is the data size reduction
to operate images.
This figure shows the data size,
is action, is out.
I compared the reduction with fire-oriented approaches
by generating a compressed file, compressed to fire,
instead of data to fire.
So it just shows that D4C provides data
only from 5 to 40% size compared to fire-oriented process.
It means that D4C can provide 20 times compression
at the most.
As well, but as notably as a pilot operating
from 0.1, fire-oriented approaches
has a 6440 megabytes, but the D4C
is BSDF only generates only a 33 megabytes.
This is very huge reduction on operating.
And this figure shows the breakdown over the size reduction.
From this video, we can see huge reduction
on executable fires on the shared libraries.
But this blue one, post-to-base, both points,
post-to-base points in the exploit BSD.
Doesn't want to reduce so much.
This is because BSDF is designed for shared libraries
or executable fires.
But this post-to-base point index point
BSDF is bit encoding, bit encoded.
So the BSDF cannot handle it quite three.
I also evaluate time to generate data.
As well, fire-taughts, 0.1, it takes about 30 minutes
to generate data as is BSDF.
Each shows generating data's own request is not protocol.
And mass power mass, left figure shows the time
to mass change to data's.
By default, this it takes only 25 seconds.
And this is 65 time-fast-adザing the data for almost scratch.
And the size, the margin of data's
and generate from scratch, scratch, data's
is almost the same.
So it means the margin strategy can provide data's
much quickly and there is no side effects.
Finally, as an entire animation evaluation,
I measure the time to create images.
This is an entire result.
And notably, as a fight-out show,
operating from 0.0 to 0.1, 5-on-it-stop-rout
is took two minutes, but the BSDF takes only 12 seconds.
This is almost 10 times faster operating.
Also, we need to clear about the performance
on the applications.
I will measure the performance on postways and fight-out.
The first is the post-faith and the left table shows
the result.
Both DCFs and GATF5 system provide
it's almost the same results.
And the light is a fight-out.
This is in this, basically, an e-finance code,
which means it means the fight-out is launched repeatedly.
And the e-finance performance is not,
it's almost the same, but the time-to-road libraries
is showed the different result.
The first time to road libraries takes much time
with DCFs, but the following launch does not take much.
This is because a DCFs price and data on the BSDFs
at the first fight-out and catch it, catches the result
on low-cost storage.
So the first road takes some time,
but the following will not, does not take.
So once the container starts and the,
I think, out of one, once the container starts and the following
performance will not be decreased.
Next step is to work on this.
The current, the FFC implementation,
is just a pro-conscent on the rocks, many features.
And she had to, sometimes, realize,
and the more important issue is, how to decide
the data generated in advance.
Currently, each event is owned by operators,
but I think there are some approaches to decide
the data to generate in advance.
Well, as a large improvement, I'm seeking a combination
with the DD chunk, providing updates chunks
with their time coding, will be beneficial,
but it has the same problem, how to choose a base
and operate chunks to generate data.
Sometimes, this presentation.
The default is objective is reducing data
insights on the time to operate container images.
Solution is utilizing data encoding
and evaluation shows, 20-time compression,
20 times compression, and almost 10 times
operating, first, 10 times, first operating,
compared to the final oriented approaches.
The next step is implementing more and more.
That's all, thank you for listening.
Thanks for your talk.
Are there any questions?
Hi, thank you for your talk.
Can you explain the trade-offs?
Because you are trading off a network bandwidth
to upload and download the images,
but what's the exchange?
Like, is in the client, you have more CPU
to understand what needs to be dealt
or where is the trade-off, where we get the trade-off from?
It must be somewhere.
Ah, as a total of current containers,
does not require dedicated servers and users can simply
pull with contents URL.
But before see, the clients are dedicated to servers
and users need to generate their tasks
who are put in advance, the money
is then by themselves.
This is one thread of in my approach.
Yes, you mentioned, or in the graphs,
you showed the trade-offs were either time saving
or data saving.
Is there a sweet spot you have found during the trials?
Is there like a middle way between efficiency
and also the bandwidth savings?
D4C saves both time.
Is designed to both time and the data size.
And it can be achieved if it can be achieved.
If the data is generated in the other ones
and the users operate the server by themselves.
So if the corresponding data to operating
is not generated or not, it does not exist,
the server needs to pull the image from the industry
and generate their tasks from scratch.
So in such case, the time is time much increases.
But the data size will not increase.
OK, thank you very much.
Thank you.