# goecs: a server benchmark suite that treats a VPS as the subject under test

> The Go rewrite of the Fusion Monster evaluation project bundles CPU, memory, disk, routing, and streaming-platform checks into one binary, and its most interesting design choice is orchestrating around dependencies it does not control.

**oneclickvirt/ecs** — VPS Fusion Monster — Server Benchmark (Go Edition) Aims to be the most comprehensive and fastest server benchmarking project, built in Go with zero external dependencies.  VPS 融合怪服务器测评项目 · Go 版本 致力于成为最全面和最快速的服务器测评项目，使用 Go 语言实现，零环境依赖。

- Repository: https://github.com/oneclickvirt/ecs
- Website: https://t.me/+UHVoo2U4VyA5NTQ1
- Stars: 2,371 · Forks: 152
- Language: Go
- License: GPL-3.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/oneclickvirt-ecs

## One shell command, no package manager

The install path is a single curl invocation that downloads `goecs.sh`, runs its `install` subcommand, and then invokes the binary with a language flag. The README sets three defaults before the download: dependencies are not installed, the package manager is not updated, and the run is non-interactive.

```bash
export noninteractive=true && curl -L https://raw.githubusercontent.com/oneclickvirt/ecs/master/goecs.sh -o goecs.sh && chmod +x goecs.sh && ./goecs.sh install && goecs -l=en
```

The `-l=en` flag selects English output, which matters because the project ships parallel documentation in `README.md` and `README_ZH.md` and treats the two as equal citizens rather than one being a translation afterthought.

The CDN variant swaps the raw.githubusercontent.com host for `cdn.spiritlhl.net` with the upstream path appended, and there is a shorter link form that redirects to the same script. There is also a variant for the case that motivates most of the fallback logic in this project: a host that is online but has no working local DNS. It passes a DoH URL to curl along with a `--resolve` pin for Cloudflare's resolver, so the script can fetch itself on a machine that cannot resolve anything.

```bash
export noninteractive=true && curl --doh-url https://cloudflare-dns.com/dns-query --resolve cloudflare-dns.com:443:1.1.1.1,1.0.0.1 -L https://raw.githubusercontent.com/oneclickvirt/ecs/master/goecs.sh -o goecs.sh && chmod +x goecs.sh && ./goecs.sh install && goecs -l=en
```

That last block is worth reading twice. A benchmark tool that fails to install on the broken host you most wanted to test is useless, and handling that case is more thoughtful than the feature list suggests.

## Zero shell dependencies, twenty Go modules

The repository description advertises the project as built in Go with zero external dependencies. The `go.mod` file tells a more nuanced story. It declares Go 1.26.5 and roughly twenty direct requires, including a terminal UI toolkit built on bubbletea, bubbletesa components, and lipgloss for styling, an HTTP client, and `golang.org/x/term`.

```
go 1.26.5

require (
	github.com/charmbracelet/bubbles v1.0.0
	github.com/charmbracelet/bubbletea v1.3.10
	github.com/charmbracelet/lipgloss v1.1.0
```

Both statements are true at once, and the resolution matters for how you read the rest of the documentation. The zero-dependency claim is about the shell environment the benchmark runs in, not about the Go module graph. The README is precise about this: no additional shell file dependencies unless necessary to install the environment, with the environment installed only to measure more accurately, and the claim that in extreme cases the project can be fully measured with no environment dependencies at all.

That is the design goal stated honestly. Installing fio or sysbench onto a fresh VPS changes what you are measuring, because packages bring libraries and daemons with them. The tool tries hard to give you a number on the machine as the seller shipped it, and falls back to installing supporting tools only when a specific check needs one.

## CPU, memory and disk tests that wrap other tools

The compute tests are not reimplementations of the classic benchmarks. They are front ends. The `cputest` module supports sysbench in both its lua and golang versions, plus geekbench and winsat. The `memorytest` module supports sysbench, dd, winsat, mbw, and stream. The `disktest` module supports dd, fio, and winsat.

The pattern is consistent enough to be worth naming: goecs supplies the orchestration, the concurrency, the result formatting, and the translation into the output format that makes two different VPS providers comparable, while the actual load generator is whichever tool suits the platform. On Windows that means winsat throughout, which is the only one of the three with a native path there.

This has an obvious consequence for interpreting results. A goecs memory number is a sysbench or mbw or stream number that goecs formatted, and which of those ran depends on what the script found on the host. Two runs on different hosts are comparable because the project normalizes the presentation, not because the underlying workload was identical. The README's own advice for first-time users is to start with `README_NEW_USER.md`, which exists in the tree for exactly this reason.

## Network tests borrowed, rewritten and renamed

The network side is where the project's lineage is most visible, because each module names its origin in the README. The three-network return path test is described as modified from `zhanghanyun/backtrace` to `oneclickvirt/backtrace`. The three-network route test is modified from NTrace-core to `nt3`. The three-network ping test is modified from `ecsspeed` to `pingtest`. The speed test is based on public data from two speedtest projects and developed into `oneclickvirt/speedtest`, with a note that the upstream version avoids shared-CDN user-profile cache reuse and follows temporary upload redirects.

The three-network framing is the part that makes this more than a throughput number. Chinese hosting buyers have learned to distrust a single-path ping, and the three carriers whose paths are traced are the ones that matter for routing quality into that market. A VPS can have good bandwidth and unusable routing, and only a multi-path test separates the two.

Two other checks round out the network side. Streaming platform unlock tests run concurrently against `UnlockTests`, with logic modified from RegionRestrictionCheck, which answers a question specific to VPS resellers: whether the IP address is recognized as residential or datacenter by a streaming service. Email port testing through `portchecker` covers a failure mode that costs real time later, a provider that blocks port 25. Concurrent IP quality and security information lookups come from binaries compiled into `securityCheck`, and the address itself is gathered by a self-developed STUN client.

## Root, non-root, and offline are all supported paths

The README lists three run modes: root or admin, non-root or non-admin, and offline. Supporting non-root matters more than it sounds. Some of the network tests need raw socket access, and some hosting providers hand you a VPS where the only user you ever get is an unprivileged one, so a benchmark that requires root would simply refuse to run on exactly the machines worth measuring.

The offline mode is the honest counterpart to the streaming and speed tests. When there is no usable network, the project falls back rather than reporting a misleading zero.

The DNS handling deserves a note because it is a small design decision with real consequences. When the host is online and local DNS is confirmed unavailable, the tool falls back to built-in DoH or DoT without rewriting resolver files, and temporary DNS or network errors preserve the system DNS. Both halves of that matter. Rewriting `/etc/resolv.conf` on someone else's rented machine is a side effect a benchmark has no business leaving behind, and treating a transient timeout as proof that DNS is broken would send the tool down a recovery path it did not need. Preserving the host's configuration and only escalating on confirmed failure is the conservative choice.

The Dockerfile reflects the same philosophy from the container side, and it is worth reading as a whole because every `apk add` is a package you were trying to avoid on the bare host.

## Compiled for eight architectures, tested on three

The README separates what the project can compile for from what it has been tested on, and the gap is large enough that the table should be read rather than skimmed. Compilation is supported for amd64, arm64, arm, 386, mips and mipsle, mips64 and mips64le, ppc64 and ppc64le, s390x, and riscv64. Testing is claimed for amd64, arm64, and s390x.

Operating systems follow the same shape. Linux, Windows, MacOS, FreeBSD, and Android are listed as supported for compilation; Linux, Windows, and MacOS are listed as tested. OpenBSD and NetBSD are called out as pending with a specific reason, that some of Go's official libraries do not support those systems, particularly the networking ones. Given how much of this project is network measurement, that explanation is consistent with the rest of the design.

The last three release tags, v0.2.12, v0.2.11, and v0.2.10, were all published on 2026-09-10, within a few hours of each other, and all three changelog entries concern the speedtest path: aligning private speedtest rows, making fallbacks bounded and authoritative, and suppressing malformed payload logs. Three same-day patches in one subsystem is a reasonable signal about where the instability currently lives, and the last push on the same date says the tree is still moving.

## Conclusion

goecs is a good fit for the specific question of whether a VPS is what its seller claims, because it runs without a package manager and works on hosts where installing benchmark dependencies would change the numbers. Its limits follow from the same design: the routing and streaming checks need network access to third-party endpoints, and the CPU, memory and disk numbers depend on optional external tools that a zero-dependency install does not bring along. Start with the one-click command and the language flag, read `README_NEW_USER.md` before drawing conclusions from a first run, and treat the three September 2026 release tags as evidence of active work on the speedtest path rather than a settled tool.

## FAQ

### What is goecs and what does it benchmark?

goecs is the Go edition of the Fusion Monster server evaluation project, aimed at VPS buyers. It covers CPU, memory, and disk throughput, three-carrier return path and routing, ping, speed test, IP quality, email port reachability, and streaming platform unlock checks.

### How do I install and run goecs without a package manager?

The one-click command downloads `goecs.sh`, runs its `install` subcommand, and invokes `goecs` with a language flag. The README states that it will not install dependencies or update the package manager by default, and that the run is non-interactive.

### Does goecs really have zero dependencies?

It has zero shell dependencies on the host. The `go.mod` file still requires about twenty direct modules, including a bubbletea terminal UI stack, and some checks fall back to external tools such as fio or sysbench when the host already has them. The README frames the environment install as something done only to measure more accurately.

### What happens if the VPS has no working DNS?

The install command has a variant that passes a DoH URL and a resolved Cloudflare address to curl, so the script can fetch itself on a host that resolves nothing. At runtime, confirmed DNS failure falls back to built-in DoH or DoT without rewriting resolver files, and temporary errors leave system DNS untouched.

## Sources

- [License: GPL-3.0](https://github.com/oneclickvirt/ecs/blob/master/LICENSE)
- [oneclickvirt/ecs on GitHub](https://github.com/oneclickvirt/ecs)
- [Project website](https://t.me/+UHVoo2U4VyA5NTQ1)
- [README](https://github.com/oneclickvirt/ecs/blob/master/README.md)
- [Releases](https://github.com/oneclickvirt/ecs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oneclickvirt-ecs