Website Optimization (2): Cloud Server Configuration

This is part of an ongoing series. Based on Renfei’s Blog 2020 Major Update, I’m covering each area separately: region selection, cloud server configuration, environment setup (JVM), caching strategy, Spring Boot configuration, and front-end page optimization.

Note: this is my personal experience, not a professional benchmark. Some of it isn’t rigorous — please bear with me.

The last post was about choosing a network. This one is about choosing and configuring a server. There are many types of cloud servers, each aimed at a different scenario; I’m only describing my own, so weigh it against your actual situation.

Analyzing the Scenario

First you need to know your requirements. Anyone who recommends a cloud server without discussing the scenario is talking nonsense. My own requirements break down like this:

The server runs Docker containers at the bottom, holding my own Spring Boot application, a MariaDB database, a Redis database, and a private Maven repository.

• Spring Boot needs between 128 MB and 512 MB of memory to start. CPU depends mainly on traffic — I get about 500 PV a day with no concentrated concurrency, so a single core is plenty.

• MariaDB’s speed will bottleneck on disk I/O; memory sits roughly between 128 MB and 512 MB. With Redis caching, few queries reach the database, and they’re all SQL I wrote myself, so I know there’s nothing huge or complex in there. A single core is enough.

• Redis mainly uses memory, depending on how much you cache. At my usage level, 128 MB is basically enough, and CPU is negligible.

• The private Maven repository is the memory-hungry one — it’s a whole stack with its own database and so on, so it needs at least 1 GB. Being a private repo, it’s read-only from the public internet and traffic is low, so one core is enough there too.

Based on the above, I need roughly a 2-core, 4 GB machine. More would be waste; less won’t run. Next, off to the cloud marketplace to see which types suit me.

Cloud Server Categories

I know Alibaba Cloud best, so I’ll use it as the example. This isn’t an endorsement — it’s just what I’m familiar with. Please judge for yourself.

Per the scenario analysis above, an ordinary server is all I need, so I pick the x86 architecture, and the “shared” category is enough. Within shared there are several series: shared standard s6, burstable t6, and burstable t5. Based on my experience, here’s how they differ:

• Shared standard: no limit on CPU utilization — you can run the CPU at 100% indefinitely. Suited to long-running compute workloads.

• Burstable: has a defined average baseline CPU performance, say 20%. Below 20% usage isn’t billed separately and accumulates CPU credits; above that, credits are consumed first, and once they’re gone you’re hard-capped at 20%. You can also check “enable unlimited mode for burstable instances”, which simply bills you. As the name suggests, it suits bursty workloads — which is my case: CPU is used when someone visits, idle when nobody does.

So by my requirements, “burstable” fits better. But there are t6 and t5 specs, differing in internal network bandwidth and CPU:

• Burstable t5: internal bandwidth 0.5 Gbps; CPU: Intel Xeon E5-2682v4 / Intel Xeon (Skylake) Platinum 8163 / Intel Xeon Platinum 8269CY

• Burstable t6: internal bandwidth up to 1 Gbps; CPU: Intel Xeon Platinum 8269CY

My scenario isn’t CPU-dependent, so I’m not sensitive to CPU performance, but the private Maven repository makes me sensitive to bandwidth. Note the wording: one says “0.5 Gbps” and the other says “up to 1 Gbps”. I tested it, and the problem is exactly that word “up to” — it states a maximum but guarantees no minimum. The t6 I bought only got “0.08 Gbps”. No need to ask which I chose: I went with burstable t5, 2 cores, 4 GB.

Peripheral Configuration

With the instance type picked, it’s time for the surrounding options: operating system, disk, and network bandwidth.

Choosing an Operating System

It’s usually CentOS or Ubuntu. Since I need to run Docker on it, and my research suggested Docker runs more efficiently on Ubuntu, I chose Ubuntu. If this were an enterprise application, I’d behave and pick CentOS. The two have different characters: CentOS feels more stability-focused with very small updates, while Ubuntu updates faster. CentOS is rock-steady and old-school; Ubuntu is young and fashionable. It’s my own stuff, so I picked young and fashionable Ubuntu.

Choosing Storage

There are three disk options: ultra disk, ESSD, and SSD. Let me explain the differences:

• Ultra disk: an ordinary mechanical disk, and the cheapest. If you’re not sensitive to disk I/O performance, this is the better value.

• ESSD: newer, a high-performance solid-state disk. Note that it has performance levels PL0, PL1, PL2, PL3 — PL0 is worse than SSD, the others beat it, and the higher the level the pricier.

• SSD: solid-state disk; IOPS performance scales with capacity. Priced in the middle of the three.

I don’t store much data, but I do run a database on it, and databases are sensitive to disk I/O, so I picked ESSD at performance level PL1.

Choosing Bandwidth

Since I configured my own VPC with a cloud switch, I skipped public bandwidth for now and planned to add a public gateway and elastic IP later.

Cloud Server Optimization

4 GB of memory isn’t much and it’s tight — if it fills up, programs crash — so I also need to configure a SWAP partition, so that when memory is full part of the disk can stand in. Alibaba Cloud doesn’t enable SWAP by default. Because Alibaba Cloud disks are replicated multiple times, using disk as memory puts heavy pressure on the cloud disk, so it’s off by default. You can still enable it manually; the usual rule is twice the memory, so with 4 GB I set up an 8 GB swap.

To check whether SWAP exists:

free -m

1. Allocate file space

Create the 8 GB of file space needed for swap at /swap:

dd if=/dev/zero of=/swap bs=1G count=8

2. Format the file as swap

mkswap /swap

3. Enable swapping on this partition

swapon /swap

Note: if /etc/rc.local contains swapoff -a, change it to swapon -a.

4. Enable the SWAP partition at boot

Edit /etc/fstab, and on the SWAP line add:

/swap swap swap defaults 0 0