低配虚拟机运行网站的性能调优，不是单纯把并发数调大，而是先找出请求慢在应用、磁盘还是资源争用，再减少重复工作。只有 1—2 个虚拟 CPU、内存约 1—2 GB 的实例尤其要留意：缓存可以减少动态计算，但过多工作进程会抢内存，最终触发换页甚至进程被系统终止。
先确认瓶颈，再决定改什么
观察网站正常访问和高峰时的 CPU、内存、磁盘等待与响应时间。Linux 上可用 top 或 vmstat 查看 CPU 和内存压力；free 查看可用内存，iostat（系统已安装时）观察磁盘等待。不要只看某一瞬间：连续记录几分钟，并同时检查网站日志中的慢请求和错误。
- CPU 长时间接近满载、但内存充足：优先减少动态请求和重复计算。
- 可用内存持续偏低、swap 持续增长：先降低进程数量或内存占用，不要继续增加并发。
- 磁盘等待偏高：检查日志量、数据库读写和存储空间；单纯加缓存未必能解决写入瓶颈。
缓存要分层，避免缓存错内容
先处理静态文件
CSS、JavaScript、图片等内容通常适合由 Nginx 直接提供，并设置合理的浏览器缓存时间。文件名带版本号或内容指纹时，可对这类文件设置较长缓存；发布后更换文件名，浏览器才会请求新版本。HTML 页面更新频繁，不宜不加区分地设成长缓存。
再考虑页面和数据缓存
若网站每次访问都重复生成相同页面，可评估页面缓存；使用 PHP 网站时，PHP-FPM 配合页面缓存能减少脚本执行次数。登录状态、购物车、管理页面及包含个人信息的响应，必须绕过公共缓存，避免用户间内容串用。Redis 可用于适合缓存的对象或短期数据，但它会占用内存；内存紧张且缓存收益不明显时，不必为了“有缓存”而增加它。
并发参数按内存预算设置
并发进程不是越多越快。以 PHP-FPM 为例，先观察实际工作进程的常驻内存，再按可分配给应用的内存估算上限：应用可用内存除以单个进程的典型内存占用，所得结果还要留出余量。虚拟机若同时运行数据库，应先为操作系统和数据库保留空间，不能把全部内存分给 PHP-FPM。
设置后通过实际请求观察队列、响应时间和内存变化。若 CPU 已饱和，增加工作进程通常只会加重争用；若 CPU 空闲但请求排队，才进一步检查进程上限、数据库连接和外部依赖。调整应一次只改一项，便于发现副作用。
按顺序执行，保留回退空间
- 记录当前配置和一组基线：页面响应时间、CPU、可用内存、swap、错误日志。
- 启用静态文件缓存；确认资源更新后能通过版本化文件名刷新。
- 筛选可安全缓存的页面或数据，明确登录用户、表单提交等绕过规则。
- 根据进程实际内存调整 PHP-FPM 并发上限，修改后检查配置并平稳重载服务。
- 重复相同的访问观察。若错误增加、内存持续下降或响应变慢，回退最近一次修改。
压缩响应、清理不必要的调试日志也能减少带宽和磁盘负担，但应先确认不会影响排错。若瓶颈来自持续高 CPU、内存不足或数据库写入，缓存与并发调参有上限；这时应评估精简应用、拆分负载或增加虚拟机资源。
常见问题
开启缓存后页面没有更新怎么办？
检查浏览器缓存时间和文件版本。静态资源采用新文件名发布；动态页面则检查缓存失效规则，并确认管理与登录页面没有被公共缓存。
内存不足时应该先加 swap 吗？
swap 可缓解短时内存压力，但速度通常低于内存。若持续大量使用，网站仍可能变慢；应先减少进程或应用占用，再评估是否需要更多内存。
如何判断这轮调优是否有效？
在相近访问条件下比较响应时间、错误率、CPU 和内存，而不是只看单次测速。低配虚拟机运行网站的性能调优应以稳定响应和不触发资源耗尽为目标，逐项验证比盲目加大并发更可靠。