Google Cloud E2 Performance Measured: How to Choose with Limited Budget?

Buy cloud server most afraid of what? Not expensive, but in the "cost" and "performance pit" between the back and forth.

In the Google Cloud (GCP) Compute Engine family,

E2(Efficient) Series

Definitely the most eye-catching "budget savior". Compared with the previous generation N1, it saves nearly 30% of the cost, and does not force binding to reserve a lock period. It is the first choice for many independent developers, start-up teams and enterprise testing environments.

But there is no free lunch. Why is E2 so cheap? Will its CPU dynamic scheduling mechanism drag on during peak business hours? What exactly is the choice between a shared core (Shared-core) and a standard core (Standard)?

This article through the actual measurement, architecture analysis and step pit summary, for you to disassemble E2 performance truth and selection strategy.

1. Uncover the Technical Underlying of E2: What's the Price of Cheap?

To make good use of E2, we must first understand how Google hit the price.

1. CPU dynamic resource pool (Dynamic Resource Management)

Unlike regular VMs (such as N2), which have exclusive physical CPU threads,

The E2 series is built on a dynamic resource scheduling pool within Google

. The physical CPU running at the bottom of your VM is not fixed, and the system will be based on the load of the computer room.

Intel Xeon(Cascade Lake/Skylake)

or

AMD EPYC(Rome)

Seamless switching between processors.

Pros: No need to pay a high hard hardware exclusive premium, boot to enjoy the ultimate cost-effective. Hidden danger: CPU platform is not fixed, resulting in 5% ~ 15% fluctuation in single thread performance, and Local SSD and GPU expansion are not supported.

2. "Shared core" performance burst mechanism (Bursting)

E2 entry-level three models (

e2-micro

,

e2-small

,

e2-medium

) with a shared core design:

e2-micro: Provide 0.25 physical Core computing power (usually maintain 25% CPU baseline), allowing Burst to 2 vCPU for a short time.

e2-small: Provides 0.5 physical Core computing power (50% baseline), allowing Burst to 2 vCPU.

e2-medium: Provides 1 physical Core (100 percent baseline), allowing Burst to 2 vCPUs.

core pit

Many beginners see

e2-micro

Display "2 vCPU", think it is cheap. In fact, as long as the CPU continues to be fully loaded for more than a few minutes, the system will force it back to the baseline level.

To the system instant Caton.

2. Performance Measurement and Comparison: What Can E2 Do?

Combined with the running tool (Sysbench / CoreMark) and the actual scene simulation, the performance of E2 shows a strong "two-sided":

1. Running points and CPU performance

Standard Edition E2 (e. g. e2-standard-2 / e2-standard-4): Under continuous high load scenarios, E2 Standard Edition does not deduct CPU credits like AWS t3/t4g. Even with a continuous full load of 100%, the performance is quite stable, reaching about 75% ~ 85% of N2 performance.

Shared Core E2(micro/small/medium): Very agile in the face of short HTTP request responses, but performance degradation is extremely fast when compiling code, decompressing large files, or running intensive SQL queries.

2. Disk and network I/O throughput

The network bandwidth for the E2 default quota is limited by the number of vCPUs (typically the baseline starts at 2 Gbps). For disks, because Local SSD is not supported, only Standard PD, Balanced PD, or SSD PD can be mounted. For high-frequency and high-concurrency database reads and writes, disk read/write latency (IOPS) becomes the first bottleneck of E2.

3. budget is limited, how to choose?

In order to avoid "wasting more money" or "buying the wrong hip", please take your seat according to the following scenes:

Scenario 1: Personal Blog, Hangup Script, Lightweight Agent

Preferred Model: e2-micro (Free Tier Benefits)

Memory configuration: 1 GB

Practical advice: be sure to configure 1GB ~ 2GB Swap swap partition! Memory is too small, just run a Docker or NPM installation will report OOM Killed. Ideal only for running static websites, WordPress lightweight blogs, Telegram bots, or automating scheduled tasks.

Scenario 2: Small Web application, test development environment, front-end API

Preferred model: e2-medium or e2-standard-2

Memory configuration: 4 GB - 8 GB

Practical advice: The e2-medium is extremely cost-effective (providing 1 core equivalent baseline computing power +4GB memory). Ideal as a Staging test environment or low-traffic microservice node.

Scenario 3: Medium-sized website, production-level web service, cache node

Preferred Models: e2-standard-4 or Custom Machine Types

Practical advice: use GCP's custom specification killer: if you find that the system CPU usage is very low but requires large memory (such as Redis nodes), there is no need to choose an expensive standard.

Quasi-type. You can directly order the e2-custom-2-8192(2 vCPU +8GB memory), saving about 40% ~ 50% of the cost than buying e2-standard-4 directly!

4. Pit-Avoidance Guide: 4 'Invisible Traps' of E2"

Don't take e2-micro when any relational database (MySQL/PostgreSQL) of the database server encounters sudden traffic, which consumes CPU points in an instant, and then the database response delay will soar to several milliseconds or even seconds, causing the whole station to crash.

Lack of advanced CPU instruction set support Due to the random distribution of the underlying physical machine, E2 instances cannot guarantee fixed AVX-512 and other instruction set characteristics. If your business involves deep learning inference, audio and video transcoding, or high-performance cryptography, choose the C2 or N2 series directly.

No Sustained Use Discounts (SUD) automatic discount It is important to note that the base price of the E2 series has been significantly reduced, so continuous use discount (SUD) is not supported. If you plan to run for a long time, it is recommended to directly purchase a 1-year or 3-year commitment discount (CUD), which can save 30% ~ 50% on the basis of the original ultra-low price!

Note that the maximum disk performance of the disk mount performance limit E2 is lower than that of the N2 series. When mounting a common Persistent disk, be sure to monitor the disk/write_ops_count through the Monitoring to prevent disk IO overload from dragging down the CPU.

5. Summary and Selection Decision Tree

One-sentence summary

: E2 is the "king of cost performance" on Google Cloud. As long as you don't use it to run high concurrent databases, heavy AI computing and high-frequency IO services, the money it saves can more than double the life cycle of your cloud budget.

Personal Play Ticket/Free White Piao➡Choose e2-micro (remember to add Swap)

Daily Development/Test/Light Service➡Choose e2-medium

Eating memory, less CPU production services➡Select e2-custom (customize CPU and memory as needed)

High concurrency/database/core business➡️ detour choice N2 / N2D or C2 series