Object Storage Comparison of DigitalOcean, Linode, and UpCloud

In this post, I want to show a test result of object storage services provided by DigitalOcean, Linode, and UpCloud. The result shows the average durations required to download/upload files from/to their cloud infrastructures. But, before we go into the test detail, let us overview the user features provided by each cloud provider.

DigitalOcean has the most advanced features compared to the rest. By utilizing its user dashboard, we can set a custom domain for the CDN of object storage, customize permission per object, and custom CORS headers. UpCloud has a more straightforward interface but with a unique concept for creating separate bucket domains (directories) in a single object storage subscription. Linode has the simplest features in its interface but it provides CLI tools for managing the buckets and stored objects.

Now, let us go back to the main topic. For the test, I deploy an AWS EC2 server based in Tokyo as a tester node. Then, I set separate object storages on DigitalOcean, Linode, and UpCloud based in Singapore. I choose different regions to bring up more transmission delays and check their delivered quality of services across regions. The following image shows the test environment.

Test environment

I performed the test four times. Each test consists of downloading and uploading process five times each. Each process is applied for two types of files, the image that represents the small file (110Kb) and the PDF that represents the large file (17Mb). So, each provider is tested to store 40 files and to stream back also 40 files in total. The table below shows the result.

Average download time

Average upload time

It shows that DigitalOcean has more promising results in the download test, while Linode takes the longest time in downloading large files. In the upload test, UpCloud seems to have an unstable performance, while Linode is the fastest for uploading large files and DigitalOcean is the fastest for uploading small files.

For this test, I used my own script stored in this repository.

Comments

Deliver SaaS According Twelve-Factor App

If you haven't heard of the twelve-factor app , it gives us a recommendation or a methodology for developing SaaS or web apps structured into twelve items. The recommendation has some connections with microservice architecture and cloud-native environments which become more popular today. We can learn the details on its website . In this post, we will do a quick review of the twelve points. One Codebase Multiple Deployment We should maintain only one codebase for our application even though the application may be deployed into multiple environments like development, staging, and production. Having multiple codebases will lead to any kinds of complicated issues. Explicitly State Dependencies All the dependencies for running our application should be stated in the project itself. Many programming languages have a kind of file that maintains a list of the dependencies like package.json in Node.js. We should also be aware of the dependencies related to the pla...

Configuring Swap Memory on Ubuntu Using Ansible

If we maintain a Linux machine with a low memory capacity while we are required to run an application with high memory consumption, enabling swap memory is an option. Ansible can be utilized as a helper tool to automate the creation of swap memory. A swap file can be allocated in the available storage of the machine. The swap file then can be assigned as a swap memory. Firstly, we should prepare the inventory file. The following snippet is an example, you must provide your own configuration. [server] 192.168.1.2 [server:vars] ansible_user=root ansible_ssh_private_key_file=~/.ssh/id_rsa Secondly, we need to prepare the task file that contains not only the tasks but also some variables and connection information. For instance, we set /swapfile as the name of our swap file. We also set the swap memory size to 2GB and the swappiness level to 60. - hosts: server become: true vars: swap_vars: size: 2G swappiness: 60 For simplicity, we only check the...

Rangkaian Sensor Infrared dengan Photo Dioda

Keunggulan photodioda dibandingkan LDR adalah photodioda lebih tidak rentan terhadap noise karena hanya menerima sinar infrared, sedangkan LDR menerima seluruh cahaya yang ada termasuk infrared. Rangkaian yang akan kita gunakan adalah seperti gambar di bawah ini. Pada saat intensitas Infrared yang diterima Photodiode besar maka tahanan Photodiode menjadi kecil, sedangkan jika intensitas Infrared yang diterima Photodiode kecil maka tahanan yang dimiliki photodiode besar. Jika tahanan photodiode kecil maka tegangan V- akan kecil . Misal tahanan photodiode mengecil menjadi 10kOhm. Maka dengan teorema pembagi tegangan: V- = Rrx/(Rrx + R2) x Vcc V- = 10 / (10+10) x Vcc V- = (1/2) x 5 Volt V- = 2.5 Volt Sedangkan jika tahanan photodiode besar maka tegangan V- akan besar (mendekati nilai Vcc). Misal tahanan photodiode menjadi 150kOhm. Maka dengan teorema pembagi tegangan: V- = Rrx/(Rrx + R2) x Vcc V- = 150 / (1...

Deploying a Web Server on UpCloud using Terraform Modules

In my earlier post , I shared an example of deploying UpCloud infrastructure using Terraform from scratch. In this post, I want to share how to deploy the infrastructure using available Terraform modules to speed up the set-up process, especially for common use cases like preparing a web server. For instance, our need is to deploy a website with some conditions as follows. The website can be accessed through HTTPS. If the request is HTTP, it will be redirected to HTTPS. There are 2 domains, web1.yourdomain.com and web2.yourdomain.com . But, users should be redirected to "web2" if they are visiting "web1". There are 4 main modules that we need to set up the environment. Private network. It allows the load balancer to connect with the server and pass the traffic. Server. It is used to host the website. Load balancer. It includes backend and frontend configuration. Dynamic certificate. It is requ...

Running CI/CD Pipeline with GitLab CI

GitLab allows us to deploy CI/CD pipeline runners on our own resources within our environment. This option is available not only for the self-hosted plan but also for the cloud service plan (gitlab.com). With this setup, unlike GitHub Action, we can avoid incurring additional costs for extended pipeline runtime. This is because we can deploy the runner on an on-demand server and optimize its usage. GitLab CI offers several options for setting up resources to run CI/CD pipelines. A runner can be configured to handle jobs for specific groups or projects using designated tags. It can also be set to use different executors, such as Shell, Docker, Kubernetes, or VirtualBox. A comparison table of the supported executors is available in the executor documentation . Some executors offer greater flexibility and ease of use, while others may be more rigid but enhance server security. Installing the runner in our machine For example, we will deploy the runner on an Ubuntu serve...

Armin and Eren VS Colossal Titan

The trick was unexpected and caught Bertolt off guard.

LUKI NOTES

Search This Blog