在高并发静态文件服务场景，通常优先选择 Nginx，因为其事件驱动架构在处理大量并发连接时资源占用更低。Apache 更适合需要复杂动态模块或.htaccess 灵活控制的场景，但在纯静态高并发下内存开销较大。
先说结论：静态资源占比高且并发连接数大时，Nginx 架构优势更明显；若依赖 Apache 特有模块或.htaccess 规则，需权衡性能损耗。
- 适合 静态文件占比超过 80%、并发连接数预期较高的业务场景
- 重点看 事件驱动与多进程模型的资源消耗差异
- 别忽略 操作系统文件句柄限制和 keepalive 配置对测试结果的影响
命令速用版
若需快速验证当前服务承压能力，可使用 Apache Bench 或 wrk 进行基准测试，但需在测试环境执行。
ab -n 1000 -c 100 http://your-domain/static/file.jpg
上述命令表示发送 1000 个请求，并发 100 个连接。生产环境严禁直接运行高压力测试命令，避免服务不可用。
为什么会这样
Nginx 采用异步事件驱动模型，单个进程可处理数千并发连接，而 Apache 传统模型为每个连接分配进程或线程。
Apache 的 mpm_prefork 模式为每个请求创建进程，内存占用随并发线性增长；mpm_worker 和 mpm_event 虽有所改进，但在高并发静态文件场景下，Nginx 的非阻塞 I/O 机制通常能更有效地利用 CPU 和内存资源。官方文档明确说明了 Nginx 的设计目标是为高性能和高并发优化。
分步处理
选型或优化前，先确认业务静态资源占比，再调整配置参数，最后通过监控验证。
1. 确认资源类型：统计访问日志中静态文件（css, js, img）的比例，若占比高则优先考虑 Nginx 架构。
2. 调整连接限制：检查 Nginx 的 worker_connections 或 Apache 的 MaxRequestWorkers，确保不超过系统 ulimit 限制。
3. 开启静态缓存：在 Nginx 中配置 sendfile 和 open_file_cache，减少磁盘 I/O 开销。
4. 灰度切换：若从 Apache 迁移至 Nginx，先在低流量节点部署，对比错误日志和响应时间。
怎么验证是否生效
通过监控工具观察 CPU 使用率、内存占用和请求响应时间，而非仅看 QPS 数字。
1. 检查响应时间：使用 curl -w "@format.txt" -o /dev/null -s http://url 获取首字节时间，对比优化前后数值。
2. 监控系统资源：使用 top 或 htop 观察 worker 进程内存占用，高并发下 Nginx 通常内存增长更平缓。
3. 查看错误日志：确认 access.log 和 error.log 中是否有大量 timeout 或 connection reset 错误。
常见坑
配置不当可能导致性能不升反降，需注意系统级限制和日志写入开销。
1. 文件句柄不足：未调整 ulimit -n 可能导致高并发时无法建立新连接，报错 Too many open files。
2. 日志写入阻塞：高并发下同步写入 access.log 会消耗大量 I/O，建议改为异步写入或降低日志级别。
3. Keepalive 配置错误：客户端或服务器端 keepalive 超时时间不匹配，可能导致连接频繁重建，增加 CPU 负载。
常见问题
Apache 完全不能用于高并发场景吗？
不是，Apache 的 event MPM 模式也能处理较高并发，但同等硬件下资源效率通常低于 Nginx。
迁移到 Nginx 需要重写所有配置吗？
是的，Nginx 配置语法与 Apache 的.htaccess 不同，需要手动转换 rewrite 规则和权限配置。
静态文件性能差异有多大？
公开资料中没有看到可靠的量化数据，具体差异取决于硬件配置、文件大小和网络环境，建议自行基准测试。
参考来源
- Nginx Official Documentation, Architecture, https://nginx.org/en/docs/
- Apache HTTP Server Documentation, Multi-Processing Modules, https://httpd.apache.org/docs/