坦白讲，您的服务器是不是也越跑越慢？
说实话，我见过太多这样的场景了：花了几千块租的云服务器，刚开始跑得飞快，结果上线不到三个月，用户一多就卡得像幻灯片。您是不是也遇到过这种情况？页面加载要等好几秒，数据库查询动不动就超时，CPU占用率长期在90%以上徘徊。更让人头疼的是，明明配置不低，就是不知道问题出在哪。
其实啊，这真不一定是硬件的问题。就拿我们服务过的一家电商客户来说，他们用的是Ubuntu 20.04，跑着Node.js写的Express应用，配置是4核8G的云服务器。按理说带个日活几千的网站绰绰有余，可一到促销活动就崩。后来我们帮他们做了次性能优化，结果CPU占用率从85%降到了35%，响应时间从2.3秒缩短到了0.8秒。您猜怎么着？一分钱硬件没加！
今天我就把这次实战的经验分享给您，全是咱们在Ubuntu上折腾Node.js和Express应用时踩过的坑和总结出来的干货。
别让Node.js成为性能瓶颈
很多人觉得Node.js天生就快，所以装完就不管了。坦白讲，这是个天大的误解。Node.js的单线程事件循环确实高效，但一旦某个回调函数卡住了，整个进程都得等着。我们遇到过最典型的例子：一个Express路由里直接调了个同步的加密函数，结果每次请求都得等200毫秒。您想想，高峰期100个并发请求，后面的请求不就得排着队等？
解决办法其实不复杂。第一，把那些耗时的同步操作统统改成异步。比如说，文件读写、加密解密这些活儿，能用异步API就用异步API，别图省事写同步的。第二，给关键路径加上超时控制。举个例子，我们用Express的timeout中间件，给每个请求设置5秒的上限，超时就返回503。这样一来，就算某个接口偶尔抽风，也不会拖垮整个应用。
还有一个容易被忽略的点——事件循环的阻塞监控。我们会在生产环境里定期记录event loop的延迟，如果发现延迟超过50毫秒，就立刻报警。您别小看这个数字，50毫秒的延迟意味着用户已经能感觉到卡顿了。用toobusy-js这个库就能轻松实现，它会在服务器负载过高时主动拒绝新请求，给您留出喘息的空间。
Express中间件的排列有讲究
说到Express，很多人写路由的时候，中间件顺序都是随便排的。其实这里头门道多着呢！就拿我们优化过的那个电商项目来说，他们把日志记录中间件放在最前面，每次请求先写日志再处理业务逻辑。您想想，写日志是I/O操作啊，虽然异步了，但毕竟有开销。正确的做法是：把静态文件服务、请求体解析、压缩这些轻量级的中间件放前面，把身份验证、业务逻辑这些重的放后面。
另外，千万别在中间件里做重复计算。比如每个请求都要查一次用户信息，那不如用个缓存中间件，把用户数据存在内存里，有效期设个5分钟。我们实测过，光这一项优化，就把数据库查询量降了60%！
Ubuntu系统层面的调优不能省
很多人觉得系统调优是运维的事，跟开发没关系。但说实话，您要是自己搭的服务器，不懂点系统层面的东西，性能优化永远差口气。就拿我们常用的Ubuntu来说，默认配置其实是为通用场景设计的，跑Node.js应用的话，有几个地方必须改。
第一个是文件描述符限制。默认情况下，Ubuntu每个进程只能打开1024个文件描述符，但Node.js应用尤其是Express框架，每个连接都要占用一个。您算算，1024个并发连接就顶天了，稍微多一点就报错。我们一般会把这个值改成65535，用ulimit -n 65535命令就行。别怕改坏，重启一下就生效了。
第二个是内核参数。比如说net.core.somaxconn，这个参数控制的是TCP连接队列的长度，默认128。但咱们的Node.js应用在高峰期，瞬间可能涌入几百个连接，队列满了就直接丢包。我们一般改成1024或者更大。还有net.ipv4.tcp_tw_reuse，开启后能快速回收TIME_WAIT状态的连接，对高并发场景特别管用。
第三个是swap分区。很多人觉得内存够用就不设swap，这是个坑。Node.js应用一旦内存泄漏，没有swap的话系统会直接OOM Kill掉进程。我们建议至少配置2G的swap，虽然慢，但总比服务挂了强。
实战案例：一个Express应用的优化全过程
光说不练假把式，我给您讲讲我们优化过的那个案例。客户是个做在线教育的，他们的核心功能是视频课程列表页，用的是Express+MySQL。上线后用户反馈说，晚上8点高峰期打开页面要等6秒多，用户流失率直接涨了30%。
第一步，我们用clinic.js这个工具做了性能诊断。发现瓶颈在数据库查询上——每次请求都要查3张表，而且没有索引。解决方案很简单：加联合索引，把查询次数从3次降到1次。这一步就把响应时间从6秒降到了2.5秒。
第二步，我们发现静态资源（图片、CSS、JS文件）都是通过Express路由提供的，没有用CDN。我们把这些文件迁移到了阿里云OSS上，前端直接引用CDN地址。结果响应时间又降了0.8秒，因为Express不用再处理这些静态请求了。
第三步，我们对视频课程列表做了缓存。用node-cache这个库，把热门课程的列表数据缓存30秒。您别觉得30秒太短，对于高峰期来说，这30秒内可能有上千个请求，缓存能减少99%的数据库压力。最终，页面加载时间稳定在1.2秒左右，用户满意度从68%提升到了92%。
您看，整个过程没有加一行硬件，就是靠这些系统层面和应用层面的优化。如果您也想让自己的Node.js应用跑得更快，不妨从这几个地方入手试试。记住一句话：性能优化不是一锤子买卖，而是要养成持续监控的习惯。等您亲手把响应时间从5秒优化到1秒以内，那种成就感，比加薪还爽！
