2026 Shiny Server R 语言应用服务器租用并发对比全解

2026 Shiny Server R 语言应用服务器租用并发对比全解

给 Shiny 应用挑服务器，最容易错的地方不在配置单上，而在对并发模型的想象上。多数 Web 框架默认是"一个进程接住一堆请求、内部用线程池摊开"，Shiny 不是这样。它的底座是 R，R 的解释器一次只做一件事，于是扩展方式变成了"多进程、每进程单线程"，核数、内存、磁盘三者的账也跟着全部改写。本文把这套账一层层拆开：核数到底对应什么、内存按什么口径估、数据在进程里被复制几份、开源版在哪一个规模上开始吃力、超时参数怎么调、什么时候才真的需要第二台机器，以及哪两类场景压根不该用 Shiny。

R 会话一次只算一件事：单线程模型下的核数换算

Shiny 的每一次 reactive 重算都会落到一个 R 会话里去执行，而 R 的解释器是单线程的。一次 renderPlot 的重算、一次 dplyr 聚合、一次模型打分，在它跑完之前，这个 R 进程里的其它活儿全部排队。核数在这个模型里的含义非常直白：能同时算几个用户请求，就等于有多少个 R 进程能同时跑在核上，而不是"这台机器有多少核就能并行多少"。想让并发能力翻倍，办法是加进程，不是给单进程加线程。

这里有一个必须说清楚的例外。R 的矩阵运算走的是 BLAS，OpenBLAS、MKL 这类实现本身是多线程的，一个 lm() 或者一次矩阵乘法可能瞬间把机器上所有核吃满。如果二十个会话进程同时做矩阵运算，而每个进程又默认开满线程，实际线程数就是二十乘以核数，上下文切换和缓存失效会把单次响应时间整体抬高。在 Shiny 这种多进程形态下，更常见的做法是显式把 BLAS 线程数压到 1 或 2（通过 OMP_NUM_THREADS、OPENBLAS_NUM_THREADS 这类环境变量，具体取值需压测验证），把并行度留给进程层面，而不是留给线程层面。

核数和会话数同样不是一回事。用户在浏览器里看一张图，绝大部分时间并没有请求发往服务器，他在调筛选器、在看数字、在截屏。真正占用 CPU 的只有那几百毫秒的重算。一台 8 核机器带 60 个会话完全可能，只要这 60 个人不是同时按回车。所以核数按"峰值同时重算数"配，内存按"同时在会话数"配，这是两条必须分开算的账，把它们混在一起估，是 Shiny 选型里最常见也最贵的一个错误。

会话与进程的三套映射：一应用一进程、一应用多进程、一会话一进程

Shiny Server 的调度器决定了会话怎么落到进程上，这直接决定了内存怎么算。三种映射关系对应三个产品层级，混着谈就会算错账。

开源版只有 Simple Scheduler，它把一个 R 进程关联到一个应用，参数只有一个：该进程最多接受多少个并发会话。写成 simple_scheduler 15 就是上限 15 个连接，第 16 个用户直接拿到 503 页面。注意这 15 个会话是挤在同一个 R 进程里的，R 单线程，其中一个会话跑一个 5 秒的查询，另外 14 个会话的请求就一起等着。开源版没有排队机制，超出上限是拒绝，不是让用户等。

Shiny Server Pro 多出 Utilization Scheduler，允许一个应用由多个 R 进程支撑，三个参数分别是单进程最大连接数（默认 20）、触发新进程的负载比例（默认 0.9）、进程数上限（默认 3）。新连接会被路由到当前连接数最少的那个进程。它解决的是"一个进程扛不住多少连接"的问题，但它不是真正的按负载调度，它看的是连接数，不看 CPU，也不看这个连接背后的活儿重不重。

Posit Connect 走的是另一条路，每次会话或渲染开一个独立的 R 进程，跑完按配置回收。这个模型隔离性最好，一个用户跑崩了不影响别人，代价就是本文反复强调的那笔内存账：每个会话都要有一份自己的数据。

所以估算内存时，按"一会话一进程"算是最保守也最不容易出事的一档，它同时覆盖了 Connect 的实际行为，也是开源版在多副本部署下的上界。反过来，用开源版共享进程确实让数据只占一份，但你换来的是并发被串行化。省下来的内存，会在响应延迟上被讨回去。

被低估的一笔账：数据副本按会话数线性复制

十个用户加载同一份 1GB 数据集，占用可能是 10GB 而不是 1GB。这句话在一会话一进程的模型下成立，真实数字往往比 10GB 更难看，原因有三层。

第一层是格式膨胀

R 的 data.frame 不是紧凑的列存，每一列是独立的向量对象，字符列进全局字符串池，因子是整数向量加一张水平表，行名、属性、对象头都占地方。同样一份内容从 CSV 文本变成 R 里的 data.frame，放大 2 到 4 倍是常见的（预估区间，需用 lobstr::obj_size() 在你自己的数据上实测）。数据文件大小不等于内存占用，照着文件大小估内存，误差能到一个数量级。

第二层是复制语义

R 是 copy-on-modify 语义。在大对象上做一次列赋值可能触发整份复制，一条较长的 dplyr 管道会在中途留下若干中间对象，而 R 的垃圾回收不一定马上回收它们。于是稳态内存和峰值内存能差出 1.5 到 2 倍。配内存必须按峰值配，按稳态配的结果是在高峰期被 OOM 杀掉进程，用户会话当场断线。

第三层是共享只发生在进程内部

十个进程同时读同一个 data.rds，操作系统的 page cache 只缓存一份磁盘内容，它省的是 IO，不是内存。每个进程一旦把数据读进自己的 R 堆，就是独立的一份。换 NVMe SSD 能显著改善冷启动读盘，因为每个新会话都要重读一遍数据文件，但它一点也不会减少常驻内存。

正确的做法是实测。起一个会话，把用户会点的路径完整走一遍，读这个 R 进程的 RSS，或者用 gc() 输出里的 max used 字段，拿这个数字乘以并发会话数。任何不经过这一步的估算都只是猜测。

举个具体的反例。某个看板把 800 MB 的明细表在 global.R 里读成 data.frame，实测对象大小 2.4 GB，走完筛选加排序的交互路径后进程 RSS 峰值到过 4 GB。按文件大小估，一个会话是 800 MB，三十个会话配 32 GB 内存看起来绰绰有余；按实测估，三十个会话需要 120 GB，中间差了四倍。这种量级上的判断失误，只有实测能挡住。测试脚本也要覆盖最坏路径，只测首屏不测重算，测到的是稳态不是峰值。

把数据挪出 R 进程：库内聚合、提前物化与列式懒加载

既然内存按会话数线性放大，最有效的优化就是让常驻在进程里的东西变小。四条路径，各有各的适用边界，也各有各的代价。

库内聚合最直接。把明细留在 PostgreSQL 或 DuckDB 里，Shiny 只发 SQL，让数据库把 GROUP BY 做完再把聚合结果交给 R。1GB 明细进去，几十 MB 的聚合结果出来，单会话常驻内存立刻降一个数量级。代价是你得把原本写在 R 里的计算逻辑改写成 SQL，或者接受混合形态，重活儿在 SQL 里，轻活儿在 R 里。对多数报表类 Shiny 应用，这笔改写是划算的。

提前物化适合访问模式固定的场景。用定时任务把常用维度组合预计算成汇总表，Shiny 启动时只加载汇总结果。牺牲的是实时性，换来启动快、内存稳。数据一天更新两次的业务，几乎都不需要用户点一下就算一遍全量。

列式懒加载是中间路线。用 Arrow 的 open_dataset() 或 DuckDB 的视图，只扫描被选中的列和分区，不要把整张表拉进内存。对"用户只看某一个地区某一段时间"这类交互，能裁剪掉的部分往往是九成以上。

共享内存是唯一能真正打破"每个会话一份"的办法，bigmemory 这类包可以让多个 R 进程映射同一块物理内存。但它只支持数值矩阵，字符串、因子、嵌套结构都处理不了，写入还需要自己加锁。除非数据本来就是纯数值矩阵并且几乎只读，否则这条路维护成本偏高，不建议作为首选方案。判断标准很简单：如果你为了让数据共享而要重写一半的数据处理代码，那说明应该先试试库内聚合。

Shiny Server 开源版开始吃力的四个具体信号

开源版什么时候开始吃力，可以从四个具体信号判断，每一个都和多进程每进程单线程这个模型直接相关。

第一个信号是单次重算的时长。开源版一个应用只有一个 R 进程，一次重算超过 1 到 2 秒（工程经验值，需压测验证），同进程其它会话的响应就会被明显拖慢。这不是慢一点的问题，是串行排队，第 10 个会话前面排了 9 个 2 秒的任务，就要等 18 秒。用户体验上是"点什么都没反应"。

第二个信号是会话上限被打满。simple_scheduler 的数字一到，新用户拿到 503，没有排队，没有等待室。对内部系统，可以让用户过一会再来；对有外部用户的系统，503 就是一次事故。

第三个信号是需要隔离。开源版没有认证体系，也没有按用户、按应用的资源限制。任何一个人写了个循环跑全量数据，全应用的用户一起卡住。只要出现"某个用户的操作影响到了别人"这种情况，开源版就已经不够了，这不是调参能解决的。

第四个信号是重启期间的内存叠加。touch restart.txt 触发重启后，Shiny Server 会为新版本起新的 R 进程，而旧进程要等它上面的最后一个连接断开才退出。发版那一刻，同一应用的内存占用会出现短暂叠加，官方文档在讲 Utilization Scheduler 时明确提到资源可能临时翻倍。如果你的机器内存余量只有两成，一次普通发版就可能把机器压到 OOM。

粗略的经验分界（预估，需结合压测）：长期同时在线会话在 20 到 30 以下、单次重算在几百毫秒、用户群固定且可信，开源版够用。超过这个区间，或者出现上面四个信号中的任意一个，就该评估 Shiny Server Pro 或 Posit Connect，两者的授权费用需询价，公开渠道差异较大，以实时报价为准。

Shiny Server Pro 的 utilization_scheduler 与 Posit Connect 的调度和认证

Pro 版的 utilization_scheduler 三个参数前面已经列过，这里补两个实际使用中容易误解的点。第一，它把新连接路由到连接数最少的进程，而不是负载最轻的进程。假如某个进程上挂着一个跑了半分钟的模型任务，它只有 1 个连接，反而最容易被选中承接新会话，新会话进去就排在那个半分钟任务后面。第二，maxProc 默认值是 3，不显式配置的话，一个应用最多只有三个 R 进程，再多的用户照样 503。这两个点决定了"上了 Pro 就能无限扩"是一个错觉，参数得照着自己的会话画像调。

认证是 Pro 的另一条分界线。Pro 支持 PAM、LDAP 与 Active Directory、SAML、OAuth 以及代理认证等几种方式，开源版没有内置认证，通常只能靠反向代理在前面挡一层。做内部数据看板时，认证决定了"谁能看到哪张表"，这不是能用别的办法绕过去的功能。

Posit Connect 的差异不在调度器，而在它把 Shiny 当成了一种内容类型而不是唯一内容类型。除 Shiny 应用外，它还托管 R Markdown 与 Quarto 的定时渲染、Plumber API、Python 内容与 Jupyter 笔记，带版本管理与回滚、按内容的进程隔离、调度与分发。代价有两项：授权费用（需询价，公开渠道差异较大，以实时报价为准）和运维复杂度的明显上升。更关键的是它按会话开进程，内存账是所有方案里最贵的一档，前面所有关于数据外置的建议，在 Connect 上都是必做功课而不是优化项。

取舍可以这样说：需要认证和一个应用多进程，选 Pro；还需要定时渲染、API 托管、多语言与版本回滚，选 Connect。只是内部几个人用、数据都在数据库里聚合好了，开源版加一层反向代理就够了。

app_idle_timeout 与 app_session_timeout：回收速度对上重载代价

Shiny Server 有三个超时参数，两个管进程，一个管会话，混着用才有效。

app_init_timeout 是等待一个 R 进程启动的秒数，默认 60 秒，超时判定启动失败并关闭连接。app_idle_timeout 是最后一个连接断开后 R 进程还能留多久，默认值为 5 秒（以官方文档口径为准，不同版本可能有差异）。app_session_timeout 是单个会话空闲多久被踢下线，默认值 0，也就是永不自动断开。

app_idle_timeout 是最直接的成本杠杆，两个方向都有明确代价。设短，保持默认那几秒，进程很快回收，内存立刻释放，同样规格的机器能撑更高的峰值并发，代价是用户一旦断线重连就要重新经历一次冷启动，加载几十个包、读入那份数据、渲染首屏，慢的时候是十几秒白屏。设长，比如 600 秒，用户来回切换几乎无感，代价是内存在这段时间里一直被占，等于用常驻内存买掉了冷启动时间。

取舍要看一个乘法：可接受的重连次数乘以单次冷启动耗时。冷启动是 3 秒的话设短几乎没有代价；冷启动是 20 秒的话就得设长，同时用别的方式省钱，比如把数据挪出进程让冷启动本身变短。这两个动作是配套的，只调超时不优化启动，等于在两难之间选一边硬扛。

app_session_timeout 解决的是另外一半问题。用户开着浏览器标签去吃饭，连接没断，会话就一直挂着占位，idle 计时器根本不会启动，因为那计时器要等最后一个连接断开才开始走。设一个合理值，比如 30 到 60 分钟（经验区间，需按业务确认），可以把这类僵尸会话清掉。它和 idle 是互补关系，只调其中一个，另一半漏洞仍然漏内存。

global.R 预加载与冷启动开销：包越多，会话首屏越慢

R 应用的冷启动开销有三段，分别是 R 解释器起来、library 把包加载进来、数据读入内存。第三段最容易优化，第二段最容易被忽略。

library(tidyverse) 会连带拉起几十个子包，从 ggplot2 到 readr，加载时间跟着包的数量一起增长，具体秒数取决于机器配置和包版本，需实测。改成只 library(dplyr)、library(ggplot2) 这种按需引入，冷启动能省下可观的一截。量化方法很简单，用 R -e 加 system.time 把每个包的加载时间量一遍，把超过半秒的挑出来逐个审。

数据读取的格式选择影响更大。1GB 的 CSV 用 read.csv 解析可能要几十秒，而 readRDS 读同样内容的二进制序列化通常快一个数量级，qs、fst 这类格式还要更快。同一份数据，格式不同，冷启动能差出十几秒，这十几秒直接决定了你敢不敢把 app_idle_timeout 设短。

global.R 的位置是关键。它在 R 进程启动时执行一次，里面的对象在该进程的所有会话之间共享，只要会话不去修改它们，R 的 copy-on-modify 语义让这种只读共享几乎零成本。把数据读取和包加载放进 global.R 而不是 server 函数里，是 R 应用特有的、收益很大的一个优化点。

但它的边界要看清楚。这种共享只在多会话共用进程的模型下成立。开源版一个应用一个进程，十个会话共享同一份 global.R 数据，内存只有一份，global.R 优化既省内存又省启动。Posit Connect 一个会话一个进程，global.R 每个会话都要执行一遍，数据仍然是十份，global.R 只省启动不省内存。想在 Connect 上省内存，还是得回到库内聚合和提前物化那几条路。

另外不要忘了 app_init_timeout 默认只有 60 秒，冷启动超过它，用户会被直接判为启动失败。冷启动实在压不下来的时候同步调大这个参数是必要的，但那只是把问题藏起来，用户感受到的依然是漫长的等待。

从峰值并发倒推整机规格：一张分档对照表

按前面的口径，整机规格可以从"峰值并发会话数 × 单会话常驻内存"倒推出来。下面这张表给的是工程经验区间，不是实测数据，落地前必须用你自己的应用压一遍。

看这张表要注意两件事。第一，内存列比核数列更值得加预算，因为 Shiny 的瓶颈几乎总是内存，而不是 CPU，加核数带来的收益在会话数到达内存上限之前会很快衰减。第二，表里给的内存已经含了大约三成余量，用来吸收 copy-on-modify 的峰值、发版时的进程叠加以及 R 垃圾回收的滞后，如果压测发现峰值内存接近表里的数值，就往上跳一档，不要恰好卡着配。

swap 对这类负载基本没有帮助。R 进程的内存访问模式偏随机，一旦开始换页，单个会话的响应会从几百毫秒掉到几秒，用户看到的就是整个应用卡死。与其给大 swap，不如留足物理内存并在 systemd 或 cgroup 层面给单个 R 进程设上限，让它在失控时被单独杀掉，而不是拖着整机一起 OOM。

在租用层面，Shiny 这类内存优先型负载的报价随内存规格、地域（中国大陆、中国香港等）与带宽形态差异较大，需询价，公开渠道差异较大，以实时报价为准。一万网络深耕 19 年（成立于 2007 年），可以按内存加配比核数更激进的比例来配这类机器，但具体规格仍然要以你自己的压测数字为准。

什么时候该上多机，粘性会话为什么不能省

上多机的触发条件只有一个：单机会话数乘以单会话常驻内存，超过了这台机器可用内存的七到八成。在那之前加机器带来的只是运维复杂度和成本，不会带来容量之外的收益，因为瓶颈根本不在 CPU。

一旦决定横向扩展，粘性会话就是硬性要求，不是可选项。Shiny 的会话状态存在进程内存里，reactiveValues 里的内容、用户上传后暂存的中间对象、会话内缓存的查询结果，全都在那个 R 进程的堆上。反向代理如果把同一个会话的下一次请求转发到另一台机器，那台机器上没有这个会话，用户看到的就是应用重新初始化，未保存的输入丢失。

实现方式是在反向代理层按 cookie 或源 IP 做哈希，把同一个会话固定到同一台后端。同时要注意 Shiny 用的是 WebSocket，代理必须放行 Upgrade 与 Connection 头，并把读写超时设得足够长，否则长连接会在空闲期被代理掐断，表现为"放着不动过一会就掉线"。

粘性的代价要说清楚。一旦粘住，负载就不能再按实时压力重新分配，某台机器可能因为分到几个重活儿用户而偏重，其它机器偏轻。所以横向扩展时要按"每台机器的会话数上限"而不是"平均会话数"来规划，给每台机器留出足够冗余，让最重的那台也不至于压到内存上限。

两个反例值得记住。把 Shiny 放进自动伸缩组却不配粘性，等于让会话随机掉线，规模越大掉得越频繁。另一个反例是以为有了 Shiny 的 session allowReconnect 就能解决，它能缓解进程重启导致的断线，前提是用户回到同一个进程或同一台机器上，换机器它救不回来。

横向扩展之后，监控的重点也要跟着变。单机时代看整机内存就够了，多机之后要按机器分别看三个量：活跃会话数、R 进程数、每个进程的 RSS 峰值。这三个量里最容易被忽略的是进程数与会话数的差值，它代表了被 idle 计时器吊着还没回收的僵尸进程。差值持续变大，说明 app_idle_timeout 与 app_session_timeout 的组合有问题，或者是某台机器的回收逻辑没有生效。建议在内存用到七成时就触发扩容评估，不要等到出现 503 才动手，因为 Shiny 的容量曲线在接近上限时是非常陡的，多一个会话就可能让整机进入换页或者 OOM。

两类场景别用 Shiny：高并发公开报表与逐行大数据

Shiny 适合的形态是"少数人、交互式、每次看的东西不一样"。离开这个形态，它的成本会迅速变得不合理。

第一类是高并发公开报表。如果日均几万次访问，而所有用户看到的内容基本一样，那每一次访问都开一个 R 进程重算一遍同样的图，是纯粹的浪费。正确做法是用 R Markdown 或 Quarto 定时渲染静态页面，或者用 bindCache、memoise 这类缓存把计算结果按参数缓存起来，再由 CDN 分发。判断标准很直接：如果九成用户看到的是同一张图，动态计算就是在烧钱。

第二类是超大数据量的逐行处理。R 的强项在向量化与统计建模，逐行循环是最慢的一条路径。千万级明细在 R 里跑循环，耗时会从秒级涨到分钟级，整份数据还要被拉进内存。正确做法是在数据库里用 GROUP BY 与窗口函数把聚合做完，R 只接收聚合后的结果集做可视化。这个改动往往能把单次重算从几十秒压到几百毫秒，顺带把单会话内存降一个数量级。

还有一类边界情况值得单独提一句：需要长时间运行且不能中断的批处理任务，也不该挂在 Shiny 会话里。会话会因为超时、断网、发版而被回收，任务跟着一起消失。这类活儿应该交给独立的任务队列或调度系统，Shiny 只负责展示结果。

Shiny Server 并发会话数与进程内存的计算口径

把前面的内容收敛成一套可以直接用的计算口径，一共五步，每一步都有明确的输入。

第一步，测单会话常驻内存。起一个会话，走完用户的典型操作路径，读这个 R 进程的 RSS 或者 gc() 输出里的 max used。这个数字包含三部分：R 解释器与包的基线开销、数据对象的常驻占用、copy-on-modify 带来的峰值增量。不要用数据文件大小代替它，两者能差一个数量级。

第二步，定峰值并发会话数。它不等于日活用户数，也不等于注册用户数。按利特尔法则换算：峰值并发等于峰值时段的访问次数乘以单次停留时长，再除以时段长度。举例，日活 2000，其中四成访问集中在两小时的早高峰，单次停留 8 分钟，峰值并发大约是 2000 乘 0.4 乘 8 除以 120，约 53 个会话。日活 2000 配一台能带 2000 个会话的机器，是极其常见的浪费；反过来只看日活不看峰值集中度，又会在早高峰被打爆。

第三步，算内存总账。公式是并发会话数乘以单会话峰值常驻内存，加上系统与 Shiny Server 自身的开销，再乘 1.3 左右的余量系数，用来吸收发版时的进程叠加和垃圾回收滞后。这个余量系数是工程经验值，需按压测结果调整。

第四步，单独算核数。核数对应的是峰值同时重算数，而不是会话数。估算方法是并发会话数乘以单个会话的活跃占比，再乘以单次重算时长占会话时长的比例。多数交互式看板的这个值远小于会话数，这也是为什么这类机器可以配得"内存大、核数少"。如果算出来核数需求接近会话数，说明你的应用是计算密集型而非交互型，那更应该考虑把计算搬到数据库或独立计算节点。

第五步，校验超时与冷启动的组合。用 app_idle_timeout 决定进程回收节奏，用 app_session_timeout 清僵尸会话，用 app_init_timeout 兜住冷启动上限，三个参数要和实测的冷启动耗时一起调。冷启动超过 5 秒时，优先优化数据加载方式，而不是简单把 idle 设长。

这套口径的最大价值在于它把"日活多少"这个模糊指标，翻译成了"并发会话数 × 单会话内存"这两个可测量的量。Shiny 与其它 Web 框架选型最大的区别就在这里，别的框架可以按 QPS 估，Shiny 必须按常驻会话估。

数据来源与核对方式：Shiny Server R 语言应用配置口径

本文涉及的调度器行为、参数默认值与超时口径，均来自 Posit 公开的 Shiny Server Administrator's Guide，对应 1.5.x 版本文档：Simple Scheduler 为开源版唯一可用调度器，一个 R 进程关联一个应用，参数为最大并发会话数，超限返回 503；Utilization Scheduler 为 Pro 专有，参数 maxRequestsPerProc 默认 20、loadFactor 默认 0.9、maxProc 默认 3，按连接数最少路由；app_init_timeout 默认 60 秒，app_idle_timeout 默认 5 秒，app_session_timeout 默认 0 即不自动断开；应用重启通过 touch restart.txt 触发，旧进程保留至最后一个连接关闭，Pro 在多进程配置下资源可能临时翻倍。上述默认值可能随版本变化，部署前请以你所使用的版本文档为准。

内存放大倍数、冷启动耗时、并发分档区间、BLAS 线程数取值等数字，均为工程经验区间，标注为预估或需压测验证，不构成任何实测结论。不同数据集的对象结构差异极大，文中给出的倍率只能用于建立量级概念，不能直接用于采购决策。建议你用 lobstr::obj_size() 量对象大小、用进程 RSS 量常驻内存、用压测工具按真实操作路径跑一遍，拿到属于自己的三个数字之后再定规格。

价格相关内容一律按需询价处理，公开渠道差异较大，以实时报价为准，本文不给出任何具体金额。品牌信息为深耕 19 年（成立于 2007 年）。文中地域表述统一为中国香港、中国澳门、中国台湾。