WP Panel adds system kernel optimization, BBR+FQ enabled by default, cross-ocean access success rate increased by 13%

FollowingDiiamo's suggestion, the installation script of WP Panel has added a system kernel optimization step. After installation, a set of screened network and kernel tuning parameters (BBR+FQ, TCP buffer, connection queue, file descriptor) are automatically applied.

Optimization items overview

Single-core machines skip BBR: Academic research has found that on single-core VPS where CPU is preempted by host neighbors, BBR throughput may decrease rather than increase. The WP Panel installation script automatically detects the number of CPU cores and retains the system default Cubic on single-core environments without forced replacement.

Core optimization: BBR + FQ

What is BBR?

BBR (Bottleneck Bandwidth and Round-trip propagation time) is a TCP congestion control algorithm developed by Google. The Linux kernel"s default Cubic algorithm was born in 2006, and its core logic is "packet loss = congestion", drastically reducing speed upon detecting packet loss. This is outdated in today"s era of widespread fiber optics and dominant wireless networks—packet loss may not be due to congestion but simply wireless signal fluctuations or physical line noise.

BBR does not treat packet loss as a congestion signal but continuously measures the network'sbottleneck bandwidth和round-trip timeto control the sending rate. The result is that on long-distance links with packet loss but sufficient bandwidth, BBR's throughput far exceeds Cubic.

Why must FQ be used together?

FQ (Fair Queue) is the fair queue scheduler of the Linux kernel. BBR relies on precise packet pacing control. If not paired with FQ, the kernel falls back to high-resolution timer mode, causing additional CPU overhead per connection. Both must be enabled together.

Is BBR ready to use out of the box on ordinary servers?

Not exactly. The kernel of Debian 13 has the BBR module built-in (tcp_bbr), butit is not enabled by default. You need to manually write sysctl configuration and load the kernel module. The installation script of WP Panel automates this step.

Comparison test

Testing Environment

Special Notes: Vultr's Debian 13 image enables BBR by default. On the machine in the Cubic group, we manually executed sysctl -w net.ipv4.tcp_congestion_control=cubic to disable BBR for comparison.

Low concurrency test (2 threads / 10 connections / 30 seconds)

Both groups of servers run the same WordPress site. The test machine initiates HTTPS requests from China, simulating real visitors accessing the website via a trans-Pacific link.

wrk -t2 -c10 -d30s https://bbr.wp-panel.org/
wrk -t2 -c10 -d30s https://nobbr.wp-panel.org/

Why is the result better despite higher average latency?

A counterintuitive data point: the average latency of the BBR group is 793ms, while the Cubic group is 524ms. Looks like Cubic is faster?

In fact, there is inevitable random packet loss on trans-Pacific links. Cubic treats packet loss as a congestion signal, and once packet loss occurs, it halves the speed, and after dropping to the bottom, it times out and gives up—41 requests in the test failed directly due to this, and were not included in the average latency statistics. Cubic"s "low latency" is actuallysurvivorship bias after eliminating slow requests。

BBR does not treat packet loss as congestion, maintaining a stable sending pace, and almost all requests complete successfully. Only 1 timeout out of 367 requests, with a success rate of 99.7%. In contrast, Cubic failed 41 out of 313 requests, with a success rate of only 86.9%.

In other words:BBR does not make each request run faster, but allows more requests to complete.

Don't deify BBR

In tests, BBR completely outperforms Cubic in success rate, but this does not mean enabling BBR will transform your website.

BBR optimizes the TCP transport layer—that is, how data is "sent from the server." Its upper limit is constrained by the server"s hardware configuration and network bandwidth. A VPS with 1 core, 1GB RAM, and 10Mbps bandwidth cannot achieve 100Mbps performance regardless of the congestion control algorithm used.

What truly determines website experience, in order of priority:

1. Hardware and Bandwidth— CPU cores, memory size, and network bandwidth are the physical ceiling
2. Overall Server Optimization— Nginx configuration, PHP-FPM process management, database indexing, Redis caching, Swap strategy, file descriptor limits... WP Panel's installation script covers all these at once
3. TCP Congestion Control— i.e., BBR, which is the icing on the cake, not a lifesaver

Think of BBR as transmission tuning—it can transfer engine power to the wheels more efficiently, but if the engine itself is small displacement, no amount of tuning will get it from 0 to 100 km/h in under 5 seconds.

WP Panel's system kernel optimization module sets BBR as default because it isdefinitely beneficial and zero-cost— no additional hardware, no extra fees, no maintenance required. But it is just one part of the panel's overall optimization solution, not the whole story.

Single file download test

curl -o /dev/null -w "%{speed_download}" https://****/twentytwentyfive/style.css

Average of three downloads (unit: B/s):

Small file download speed, BBR is on average faster by 8.8%。

Summary

The newly added system kernel optimization in WP Panel is to set BBR + FQ as the default network transmission scheme. For WordPress sites, visitors are often distributed in different network environments, and cross-region and cross-ISP access is inevitable. The advantage of BBR in this scenario is —not to make the website faster, but to allow more people to open it smoothly。

If you haven't enabled BBR yet, you can manually enable it with just two commands:

echo "net.core.default_qdisc=fq" >> /etc/sysctl.d/99-bbr.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-bbr.conf
sysctl --system
modprobe tcp_bbr

Or, directly use theWP Panel installation script, and all optimizations will be completed automatically.