截至 2026-06-05，官方 Compute 指南已经包含 Linux Server 入门文档，但该页面明确标注 RhinoCompute on Linux 属于 Rhino WIP，不建议用于生产工作。

因此教学中建议这样定位：

• Windows/IIS：生产主线。
• Linux：实验、评估、未来兼容性验证。
• Docker/容器：适合快速体验，不建议作为生产运行方式。

官方 Linux 入门文档提到的系统包括：

• Ubuntu Server 24.04。
• AmazonLinux 2023。
• Debian 13 的步骤可能适用，但不应默认视为完整支持。

官方也说明仍在处理的事项包括：

• Grasshopper 中 RhinoCode 相关脚本组件。
• 3dm 以外文件导入导出。
• 第三方插件管理。
• 其他 WIP 问题。

概念上分为：

1. 安装 .NET 依赖。
2. 添加 McNeel 软件源。
3. 安装 rhino-compute 包。
4. 配置 RHINO_TOKEN 和 RHINO_COMPUTE_KEY。
5. 使用 systemd 启动服务。
6. 用 Hops 或客户端调用 Linux Compute。

服务命令示例：

sudo systemctl start rhino-compute
sudo systemctl stop rhino-compute
sudo systemctl enable rhino-compute
sudo systemctl status rhino-compute
sudo journalctl -u rhino-compute -f

Linux 日志目录：

/var/log/rhino-compute

官方文档说明容器适合入门，但不建议生产使用。核心原因是容器通常缺少标准 systemd 服务管理，不适合作为需要随系统重启、受服务管理器托管的长期 Compute 服务。

容器适合：

• 快速验证 Linux 包安装流程。
• 测试 API Key、Hops 连接、基础 GH 定义。
• CI 中做有限的 smoke test。

容器不适合：

• 直接承载生产用户请求。
• 运行复杂第三方插件。
• 依赖长期稳定授权、日志、重启恢复的场景。

无论 Windows 还是 Linux，运维上都应关注：

建议为每个业务请求生成 request id，并在外层服务日志中记录：

• 用户或租户。
• 业务任务类型。
• Compute URL。
• 请求体大小。
• 超时时间。
• HTTP 状态码。
• Compute 响应耗时。

Compute 自身日志通常记录进程、加载、异常和请求状态。外层业务日志和 Compute 日志结合，才能定位“是业务输入错了、网络错了、Compute 子进程错了、还是 Grasshopper 定义错了”。

容量规划不要只看 CPU 核心数。还要测：

• 单个 compute.geometry 子进程启动后占用多少内存。
• 加载 Grasshopper 后增加多少内存。
• 加载第三方插件后增加多少内存。
• 单次典型请求峰值内存。
• 并发请求下 GC、序列化、网关超时表现。

经验做法：

• 从小 childcount 开始压测。
• 逐步增加并发，观察内存和 P95 延迟。
• 找到“再增加子进程反而变慢”的点。
• 以测试结果决定 VM 规格和 idlespan。

1. 在测试机安装同版本 Rhino、Compute、插件。
2. 用代表性 GH 定义和自定义端点跑回归。
3. 检查授权、日志、API Key、请求体限制、超时。
4. 在维护窗口更新生产。
5. 更新后先跑 smoke test。
6. 观察日志和核心小时用量。

• 是否明确 Linux 当前是 WIP，不作为默认生产主线？
• 是否知道 Linux 日志在 /var/log/rhino-compute？
• 是否为请求链路设计了 request id？
• 是否通过压测确定 childcount，而不是凭 CPU 核心数猜？

• Getting Started with Rhino.Compute on Linux
• Deployment to Production Servers
• Compute FAQ