本地网络Apache服务器容量测试：请求数增加无延迟上升问题排查

Hey there, let's unpack this behavior—it's a common scenario when load testing static content in a local network, and it boils down to bottlenecks hitting non-processing limits rather than straining the web server's core resources. Here's a breakdown of the key reasons:

1. Your Apache Server Isn't Hit by CPU/Memory Bottlenecks #

• If you're running Apache in a VM, the bottleneck is likely connection/network limits instead of the server's processing power. For example:
  • Apache's MPM configuration (like MaxClients for prefork, or MaxRequestWorkers for event) might be capped at a value where each request gets immediate attention from an idle worker process/thread. No queuing means no increase in latency.
  • System-level limits like ulimit -n (open file descriptors) could be restricting the total number of concurrent connections, but each connection is processed quickly since there's no backlog.
• Virtual machine network forwarding (e.g., NAT vs. bridged mode) might be the throughput ceiling. If the VM's network can't handle more concurrent transfers, Apache sits idle between requests, keeping per-request latency low.

2. Local Network Bandwidth Has Plenty of Headroom #

For your large static page (3MB text + 10MB image + 50MB video):

• Let's do quick math: A single request transfers ~63MB. Even 200 requests per minute works out to ~210 MB/s—well under the 1250 MB/s limit of a 10Gbps local network, or even the 125 MB/s of a gigabit connection. With no bandwidth saturation, files are transferred smoothly without queuing delays.
• Wired local networks have negligible packet loss, so retransmissions (which add latency) aren't a factor here.

3. Static Content Caching Eliminates Disk I/O Overhead #

Apache and your Ubuntu OS are likely caching the large static files in memory:

• Apache's mod_cache or the Linux kernel's page cache will store frequently accessed files in RAM after the first request. This means subsequent requests don't require slow disk reads—they're served directly from memory, keeping response times consistent even with repeated hits.
• Apache uses sendfile() (zero-copy) technology for static files, which lets the kernel transfer data directly from disk/RAM to the network card without copying it through user space. This minimizes CPU usage per request, so even high concurrency doesn't slow things down.

4. JMeter Isn't Bottlenecking the Test #

Since you're running JMeter on a physical machine, it's probably not hitting its own limits (CPU, memory, network) to generate enough load to overwhelm Apache. If JMeter's resources were maxed out, you'd see it struggle to send requests, but your scenario shows it's reaching Apache's throughput ceiling instead.

To confirm these hypotheses, you could:

• Check Apache's server-status page to see if workers are idle or fully utilized.
• Monitor VM/physical machine CPU, memory, and network usage with top, htop, or iftop during the test.
• Adjust Apache's MPM settings or system file descriptor limits to see if throughput increases without latency spikes.

内容的提问来源于stack exchange，提问作者EagleOne