# 一个工具网站到底需要多大的服务器？

URL: https://caijiao.org/posts/124
Source: docs/posts/124.md
Description: Omni Calculator 2026 年 6 月估算访问约 1429 万，但决定机器规格的不是访问量，是每个请求要不要干活。10015.io 几乎不请求服务端，TinyWow 250+ 工具靠的是把处理留在客户端。多数工具站一台 1 核 2G 起步就够，先算带宽再定规格。

Omni Calculator 在 2026 年 6 月的估算访问量约 1429 万，支持 30 多种语言。这个数字很容易让人得出"得上一堆机器"的结论。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页没有弹窗也没有注册引导，主体就是一张分类网格。*

但把请求拆开看会发现，它每个页面做的事情极其固定：读一份配置、套模板、算出结果、返回 HTML。这类请求消耗的主要是 CPU 时间里很小的一截和几十 KB 带宽。访问量涨十倍，机器规格不需要跟着涨十倍。

工具站的服务器规格，取决于一件和访问量无关的事：**每个请求里有多少活是在服务器上干的。**

## 先把流量分成两类

第一类：只发文件。HTML、JS、CSS、wasm 文件、图片。服务器做的事是读盘、压缩、发出去。这种请求的瓶颈是带宽和连接数，CPU 几乎不动。CDN 缓存命中之后，连这一步都不经过你的机器。

第二类：要干活。上传文件、转码、压缩、跑模型、读写数据库。这种请求才吃 CPU 和内存，也才决定你的机器规格。

一个站如果 95% 的请求属于第一类，那它的服务器规格可以非常低——一台 1 核 2G 的机器加上 CDN，能扛住的量级会超出直觉。terrific.tools 30 天里有 3.4 万次会话、4.1 万次浏览，跑在很普通的机器上就够。

## 10015.io 把这个比例做到了极致

10015.io 的原则是**几乎所有工具在客户端运行，极少请求服务端**。图片压缩、格式转换、文本处理，全部在浏览器里跑完，服务器只负责把 JS 和 wasm 文件发出去。

结果是它的工具数量从 1 涨到 50 多个，服务端的负载几乎没变——新增一个工具，只是多几个静态文件。

这也是为什么"工具站要多大服务器"这个问题对它基本不成立。它 50 多个工具、Chrome 和 Firefox 扩展，靠 AdSense 拿到约 300 美元的 MRR，服务器开销在这份收入里占的比例低到不用讨论。

重活留在浏览器里的具体做法是：[WebAssembly](/webassembly/) 跑编解码器，ffmpeg 编译成 wasm 之后连视频转码都能在客户端做。服务器只发文件。

## 真正需要加配置的只有三种情况

**第一种，必须接收用户文件。** 一旦文件要上传到服务器，你就有了三份压力：入站带宽、处理时的 CPU 和内存、以及落盘后的存储空间。存储这一项会持续增长，TinyWow 明确写了"上传的文件 1 小时后自动删除"——这不只是隐私承诺，也是成本控制，不删的话磁盘会一直涨。

**第二种，计算结果要持久化。** 有数据库写入时，需要关注磁盘 IO 和内存（页缓存大小直接影响查询速度）。用 SQLite 的话一台机器足够；写并发起来了才需要考虑独立数据库服务。

**第三种，有服务端渲染且没有缓存。** 每个请求都要在服务端跑一遍渲染，CPU 就真成了瓶颈。缓解办法是缓存策略——渲染一次缓存一段时间，而不是每次重算。

三种都不占的工具站，规格可以一直很低。

## 一个具体的算法：先算流量，别猜规格

工具站的带宽可以手算出来，不必靠猜。

拿 terrific.tools 的 30 天数据做例子：4.1 万次浏览。假设每次浏览平均下载 200 KB 首屏资源（HTML 加 JS 加 CSS，压缩后），一个月就是约 8 GB 出站流量。这个量级在任何一台 VPS 的配额之内。

再看请求数。3.4 万次会话分摊到 30 天，平均每分钟不到 1 次。这种密度对任何能跑 Web 服务的机器都是空闲状态。

把数字摆出来之后，"需要多大服务器"这个问题就失去了意义——真正的变量是那 200 KB 里有没有必须在服务端生成的部分，以及有没有文件要上传。

## nginx 那一层能省掉的东西

很多"服务器不够用"其实是配置没做对。三件具体的事：

静态文件交给 [Nginx](/nginx/) 直接 serve，不要穿过应用层。nginx 用 `sendfile` 零拷贝发文件，比任何应用框架都快，还省一个进程的内存。

开启压缩（gzip 或 brotli）。工具站的 JS 和 wasm 文件是主要体积，`gzip on` 加上正确的 MIME 类型列表，传输量能降到三分之一左右。wasm 文件尤其要记得加进压缩类型里，很多默认配置漏了它。

给静态资源设长缓存头，配合文件名的 hash。这样回头用户第二次访问几乎不产生请求。

这几项做完，同样的机器能多扛几倍的量，而且对 Omni Calculator 那种把 SEO 当命脉的站来说还有额外收益——它的广告负责人 Alexander Utz 说过，页面速度对他们没有商量余地，整个增长依赖 SEO，Core Web Vitals 直接影响排名。

## 内存和 CPU，谁先不够用

工具站在这两项上的表现很典型：内存先到上限，CPU 长期空闲。

内存被吃掉的通常是三样——应用进程本身、数据库页缓存、以及处理文件时的临时占用。其中第二样是好事，内存给缓存用得越多读越快；第三样才是需要盯的，一个大文件被整体读进内存就能把 2G 吃光，所以处理要分块。

CPU 则基本是用不上的，除非你把转码留在了服务端。出现 CPU 长时间跑满，第一反应应该是"这个活是不是该搬到浏览器里"，而不是升配。

## 我给的起步方案

一个人做工具站，起步一台 1 核 2G、20G SSD 的机器足够，前面挂 CDN 扛静态流量。用 [Docker](/docker/) 部署，应用、nginx、定时任务在 compose 里一次拉起，换机器时整体搬走。

等出现具体信号再加：内存常驻超过七成就加内存，CPU 长时间跑满就加核或者把更多计算搬到客户端，磁盘涨得快就检查文件清理策略。

别按访问量猜规格。先去确认你的请求里有多少属于"只发文件"那一类——这个比例才是答案。