apache / apache/cloudstack

Storage bandwidth is wasted during template uploads/imports

Open
#5,697 6 comments 0 reactions 0 assignees View on GitHub
component:secondary-storage component:templates no-issue-activity status:stale type:improvement
Dominant language
Java
Stars
3.1k
Forks
1.4k
Avg merge
6d 19h
Merged PRs (30d)
32

Description

At the moment when a template is being imported (via url or upload) there is a phase called "Installing template" or something similar. From what I noticed this phase calculates a hash and saves it to the database by reading the downloaded file over the storage network.
During this phase the template is not usable and I believe that should not be the case. I understand that the hash has a purpose and I am not saying it should be removed but I believe this should be an optional task that should be done in background.

In the following examples I do not consider disk speeds, just network speed/bandwidth.
For normal templates this is not necessarily noticeable. Consider this scenario (best case):
Template size: 4GB
Ingress bandwidth: 100 mb/s
Storage bandwidth: 1 gb/s
Download time required: 5.45 seconds
Installing template time required: ~0.6 seconds

Most templates (not ISOs) however are considerably larger, some could be even up to 500 GB (I do have a few templates that I have to import with very large sizes).
In such a case, installing template time required would be about 75 seconds (best case).

During this time (installing template time) the whole bandwidth available for the storage network (if it even is on a separate NIC) would be used up by this process resulting in bad performance for the cluster.

Ways to fix this would be:
1. either compute the hash as the transfer is happening.
2. make it optional (maybe even opt-in) and do it in background only (maybe even limit the bandwidth used for this)

Contributor guide

Open the contributing guide

Research direction

Start by tracing the template URL/upload import path around the “Installing template” phase, then identify where the downloaded file is reread from storage and where its hash is saved. Compare the transfer and storage-read steps. Done means template availability is not blocked by a separate full storage read, while the required hash remains correct and the proposed background or bandwidth behavior is defined.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
cloud, infrastructure, performance
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.