当初接手内部业务扩容项目，最先卡在的疑问就是一台服务器能承载多少用户，纸面测算出来的数字看着很漂亮，上线之后才发现现实情况完全不一样。那会儿手里就一台物理机，配置不算差，8核内存32G，业务是内部后台管理系统，不是那种高并发的对外站点，最开始按文档估算，说可以稳稳扛住两千人同时在线，于是直接把新一批账号全部导入进去，没做压力测试就直接开放访问。
最开始的半天一切正常，登录人数慢慢涨到八百多，页面响应还能维持在两秒以内，运维那边看监控，CPU占用也就四十出头，内存只用了一半，所有人都觉得这次扩容算是稳妥了，甚至讨论要不要再多开几百个账号。没人留意到，后台每一次提交表单，都会连带查询三张关联数据表，数据库和应用服务装在了同一台机器上面，这个细节被直接忽略。
然后到下午两点，用户集中登录操作，在线人数跳到一千一百左右。
最先出问题的不是页面打不开，是提交保存的时候会随机超时，有时候点一次就能成功，有时候连续点三四次都没反应。刷新页面，首页还能加载，但是进入详情页面就卡住。看监控，CPU瞬间冲到百分之九十八，磁盘IO直接打满，不是算力不够，是频繁的数据库读写把磁盘给堵死了。那时候才反应过来，在线用户数不等于并发请求，很多人挂着页面只是在线，不会持续操作，但只要一小部分人同时提交数据，压力就会陡增。
临时的办法就是限制新用户登录，把在线人数压回八百以内，服务慢慢恢复稳定。那个晚上一直在翻日志，能看到很多闲置在线用户，浏览器开着页面放在一边，不会发起请求，只是占着会话连接。最开始的估算错误，就是把在线用户等同于并发请求，默认所有人会不停的操作页面，可真实场景里大部分在线用户都只是挂着，反过来，少量活跃用户，就足以把资源耗尽。
找做开发的朋友聊这件事，他那边是线上商城的应用，同规格的服务器，他们说在线用户撑不到五百就会卡顿，因为商城页面图片多、接口调用频繁，每一次刷新都会触发一堆请求。同样配置，业务类型不一样，结果差这么多，我才意识到，不存在一个固定数字可以直接套用。硬件配置、代码质量、数据库是否分离、图片和静态资源有没有单独存放，每一项都会拉扯最终能承载的规模。
后面尝试过把数据库迁移到另一台独立实例，还是原来那台应用服务器，再次放开访问，在线人数到一千三百的时候，系统依旧平稳，CPU负载维持在六十上下，表单提交超时的现象消失了。只是偶尔有用户反馈，打开带有大量历史记录的页面加载偏慢，这是查询语句本身的问题，和服务器承载上限没有直接关联。
整个过程里，最容易产生的误区就是只盯着硬件参数去猜一台服务器能承载多少用户，以为核数内存定好了上限，实际上代码漏洞、索引缺失、资源混布，随便一个点，都会让承载量大幅缩水。这次经历只代表我这套内部后台系统的情况，别的业务场景，就算硬件一模一样，结果也会完全不同，没法直接拿来参考。
后来就没有继续往上压测，业务本身也不需要接入更多人。关掉多余的监控采集项，清理过期的会话缓存，服务器维持一千出头的在线规模持续跑了好几个月，没有再出现大面积超时。
到现在还记得，当时盯着监控面板，看着在线数字一点点上涨，磁盘IO曲线猛地抬升，后台一堆报错日志不停滚动的那个下午。