How to configure server bandwidth limits based on periods

Manually adjusting bandwidth caps throughout the day wastes your time. You might throttle traffic too early, causing congestion during peak hours. Or you leave high limits overnight, wasting capacity. This inconsistency hurts website performance and page load speed.

You can configure server bandwidth limit changes automatically. Use Linux traffic shaping tools like tc with cron scheduling. This approach lets you set different limits for different periods.

This guide shows you how. You will identify your network interface, write tc rules, automate them with cron, and test results. Proper configuration can reduce server response time during busy periods. Your initial server response time improves when congestion drops. Faster server response time means happier visitors.

Let’s begin.

Prerequisites and Tools

Before you create time-based limits, you need two things. Identify your network interface. Choose the right shaping tool. Proper configuration reduces server response time when traffic spikes. Getting these elements right helps you control server bandwidth efficiently.

Identify Network Interface and Usage

Find your interface with one of these commands:

• ip a — Shows all interface details with IP addresses.

• ip link show — Displays interface state and MAC address.

• nmcli device status — Lists device status for NetworkManager.

Your interface is usually eth0 or ens33. Pick the one with your public IP.

Next, measure real usage with nload. This tool reads counters from /proc/net/dev. It does not capture packets, so overhead stays low. Understand your website traffic patterns. You see incoming and outgoing traffic as ASCII graphs. Current, average, min, and max rates appear alongside total bytes.

nload reads /proc/net/dev to get traffic counters. This method has minimal overhead and does not require root privileges to run.

Run nload eth0 to watch usage. Accurate measurement helps you improve server response time. Use this data to choose your peak and off-peak network bandwidth limits. Understanding your current consumption helps you set effective caps.

Choose a Shaping Tool

tc with HTB (Hierarchical Token Bucket) is the standard Linux solution. HTB lets you set guaranteed and ceiling rates for different traffic classes. Using HTB helps you maintain good server response time during congestion. You can prioritize SSH over HTTP or give a management subnet higher priority. The table shows main use cases:

For simpler rules, use TBF (Token Bucket Filter). It applies one rate without classes. Alternatives include iptables --limit and cgroups. But tc with HTB offers the most flexibility for time-based rules.

With these prerequisites, you can reduce server response time. You now know your interface and tool. The next section shows how to write the tc rules.

Configure Server Bandwidth Limit Using tc

Now you will write the actual rules. This section explains the two main disciplines and shows you how to set different caps for different hours. You will learn how to configure server bandwidth limit changes that respond to your daily traffic patterns.

Understand HTB and TBF Disciplines

HTB stands for Hierarchical Token Bucket. It organizes bandwidth into a tree of classes. Each class has its own token bucket. Tokens arrive at a fixed rate. Packets transmit only when enough tokens exist. This mechanism enforces your rate limits precisely.

HTB extends the simple token bucket into a hierarchy. You can create parent and child classes. Each class carries its own parameters. The table below explains the two critical values:

The rate value assures a class receives at least that much capacity. The ceil value sets the absolute ceiling. When a class needs more than its rate, it borrows from its parent. Borrowing continues until the class reaches its own ceil or the parent’s ceil. This design distributes unused capacity efficiently.

Consider a simple example. Leaf class #10 has a rate of 200 kbps and a ceil of 400 kbps. Leaf class #20 has a rate of 200 kbps and a ceil of 200 kbps. Class #10 can borrow up to 200 extra kbps. Class #20 cannot borrow at all because its rate equals its ceil.

TBF stands for Token Bucket Filter. It applies a single rate without classes. TBF suits simple scenarios where you need one cap for all traffic. HTB offers more flexibility for time-based rules because you can adjust individual classes.

HTB operates in two stages. First, it satisfies the guaranteed rate for every child queue. Second, it allows children to borrow tokens from parents. This hierarchical satisfaction process ensures critical traffic always gets its minimum. Less important traffic can use spare capacity when available.

Write Rules for Peak and Off-Peak Hours

You will create two rule sets. One set applies during peak hours. Another set applies during off-peak hours. Start with peak hours. Suppose you want a 10 Mbps cap. Use these commands:

tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 8mbit ceil 10mbit

The first command creates the root queue. The second command defines the parent class. The third command creates a child class. You can add more child classes for different port groups.

For off-peak hours, you want a 50 Mbps cap. Delete the old rules first. Then apply the new configuration:

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 50mbit ceil 50mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40mbit ceil 50mbit

The rate parameter sets the assured bandwidth. The ceil parameter sets the maximum. Your server can burst above rate when the link has spare capacity. This borrowing mechanism improves your server response time during sudden spikes.

Real-world tests show HTB performs well. When two clients transmit simultaneously on a 100 mbit link, each receives roughly 50-59 Mbits/sec. When one client stops, the other jumps to about 75-77 Mbits/sec. The borrowing mechanism works as designed.

CAKE offers another option. It provides fair per-host allocation by default. With triple-isolate, one client with a single connection gets 50 mbit. A second client with ten connections also gets 50 mbit total. Without shaping, bandwidth fluctuates between 6-14 mbit per client. Latency suffers significantly. Proper shaping reduces server response time dramatically.

These rules control your server bandwidth effectively. You can adjust the numbers to match your measured usage. The next section shows how to automate these changes with cron.

Automating with Cron

Manual rule switching defeats the purpose of time-based bandwidth control. You need automation. Cron handles this task reliably. It runs your tc commands at exact moments you choose. This section shows you how to build a script and schedule it properly.

Write a Script for Rules

A single script simplifies your workflow. You define functions inside it. Each function applies a different set of tc rules. You call the right function at the right time.

Create a file named /usr/local/bin/bandwidth-limits.sh. The script contains two main functions. One function applies peak-hour caps. Another function applies off-peak caps. Each function first deletes existing rules, then adds new ones.

#!/bin/bash
apply_peak() {
    tc qdisc del dev eth0 root 2>/dev/null
    tc qdisc add dev eth0 root handle 1: htb default 10
    tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit
    tc class add dev eth0 parent 1:1 classid 1:10 htb rate 8mbit ceil 10mbit
}
apply_offpeak() {
    tc qdisc del dev eth0 root 2>/dev/null
    tc qdisc add dev eth0 root handle 1: htb default 10
    tc class add dev eth0 parent 1: classid 1:1 htb rate 50mbit ceil 50mbit
    tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40mbit ceil 50mbit
}
case "$1" in
    peak) apply_peak ;;
    offpeak) apply_offpeak ;;
esac

Make the script executable with chmod +x /usr/local/bin/bandwidth-limits.sh. Test it manually first. Run sudo /usr/local/bin/bandwidth-limits.sh peak. Then check your active rules with tc -s qdisc ls dev eth0. You should see the 10mbit rate listed. This verification step prevents surprises later.

The script accepts one argument. You pass either peak or offpeak. This design keeps your cron entries clean and readable. You do not repeat long tc commands inside crontab.

Schedule Scripts with Cron

Cron reads your schedule from a file called crontab. You edit it with crontab -e. Each line contains five time fields followed by the command. The fields represent minute, hour, day of month, month, and day of week.

Your schedule needs two entries. One entry switches to peak rules at 9:00. Another entry switches to off-peak rules at 17:00. The entries look like this:

0 9 * * * /usr/local/bin/bandwidth-limits.sh peak
0 17 * * * /usr/local/bin/bandwidth-limits.sh offpeak

The first entry runs at 9:00 every day. The second entry runs at 17:00 every day. Cron executes the script with root privileges if you add these lines to the root crontab. Use sudo crontab -e for this purpose.

You can extend this pattern for more complex schedules. Suppose your peak period starts at different hours on weekends. You add more entries with different hour values. Cron handles each one independently.

Multiple specific time intervals can be specified with commas (e.g., 1,2,3). The line below would output “hello world” every 5th minute of every first, second and third hour (i.e., 01:00, 01:05, 01:10, up until 03:55).

*/5 1,2,3 * * * echo hello world

This comma syntax helps you consolidate entries. You might want peak limits at 8:00, 12:00, and 17:00 for different reasons. You write 0 8,12,17 * * * in one line instead of three separate lines. Your crontab stays organized and easy to audit.

After editing crontab, verify your entries. Run crontab -l to display the current schedule. Confirm both lines appear correctly. Then wait for the next scheduled time to observe the change. You can also run the script manually to test each function before relying on cron.

Automation removes human error from your bandwidth management. Your server applies the correct caps without your intervention. This consistency directly improves your server response time during peak traffic. Users experience fewer delays because congestion stays controlled. Your server response time remains stable throughout the day. Proper scheduling also prevents wasted capacity at night. Your server operates efficiently around the clock.

Test and Optimize to Reduce Server Response Time

Testing confirms your configuration works. This section shows you how to verify your rules and explore alternatives. These steps help you reduce server response time during heavy load.

Verify Limits with iperf

iperf3 measures actual throughput through your server. Start the listening mode with iperf3 -s. Run the client test with iperf3 -c <host>. Use the --server-bitrate-limit #[KMG][/#] option to test your bandwidth cap. This tool shows the real transfer rate under your tc rules. Compare the result to your intended cap. A significant difference indicates a misconfiguration.

Proper limits reduce server response time by controlling congestion. When data arrives faster than the network can handle, packets enter an output queue. Queue delays accumulate across hops. Router buffers fill and packets drop. TCP detects loss and reduces its congestion window by 50%. This flow-control mechanism throttles data transmission. Server response time increases.

However, congestion affects server response time conditionally. Server processing might dominate total response time. Server time could be 4.8 seconds out of a 5-second total. Network contribution is only 0.2 seconds (4 percent). In such cases, eliminating network delay does not produce a noticeable improvement. Test your setup with ping to measure latency before and after applying limits.

Network traffic congestion occurs when demand exceeds available capacity. This results in slow data transmission, high latency, and potential data loss. Higher latency forces retransmissions and delays delivery of requests and responses.

Alternatives: Firewalls and Backup Software

You are not limited to tc rules. Palo Alto firewalls offer QoS profiles with time-based classes. The schedule tab lets you apply Quality of Service based on time of day. For example, limit YouTube from 7am-12pm and 1pm to 7pm. Users can watch videos as class4 only during the lunch break. This approach works at the network perimeter.

Backup software also provides scheduled limits. Arcserve allows you to set caps during backup windows. These tools manage outgoing traffic from the server during data transfers.

Managing your website traffic with these rules improves page load speed. Your initial server response time improves when congestion drops. You can handle a higher rps and more maximum requests per second. Monitor your server response time and how your server handles incoming requests under different caps. Test your server response time after each schedule change. Adjust your limits based on real data. This cycle of testing and tuning improves your server response time.

You identified your network interface first. Then you configured tc rules for peak and off-peak periods. Cron automation switched those limits automatically. Finally, iperf verified your throughput matched expectations.

This dynamic approach lets you configure server bandwidth limit changes without manual work. Proper caps control congestion on your server during busy hours. Your server response time improves when queues stay short. Faster server response time keeps visitors engaged during spikes. These adjustments reduce server response time during peak load effectively.

Adapt these examples to your own thresholds. Try 20 Mbps during daytime and 100 Mbps at night. Monitor your server response time after each change. Adjust based on real traffic data. Your server handles requests smoothly with proper scheduling.

Run tc -s qdisc ls dev eth0 now, then set your first schedule change tonight.

FAQ

What happens to my bandwidth limits after a server reboot?

Your tc rules disappear after a reboot. Cron does not reapply them automatically. Add a cron entry with @reboot to run the script at startup. This ensures your server applies correct limits immediately. Server response time stays consistent after restarts.

Can I use this method on a virtual private server?

Yes, if your VPS gives you root access. Some providers restrict network shaping. Check with your host first. The tc command needs full control of the network interface. This control helps your server manage traffic effectively.

How do I verify my bandwidth limits are working?

Run tc -s qdisc ls dev eth0 to see active rules. Use iperf3 to test actual throughput. Compare results to your intended caps. Testing helps you reduce server response time during peak load. Your server response time improves when queues stay short.

What if my peak hours differ on weekends?

Add more cron entries for weekend schedules. Use separate lines for weekdays and weekends. Cron supports day-of-week fields. You can specify 1-5 for weekdays and 6-0 for weekends. This flexibility keeps your server response time stable all week.

Can I set more than two time periods?

Yes. Create additional functions in your script for midday or evening caps. Add corresponding cron entries. Each function applies different tc rules. Your server switches automatically at each scheduled time. Monitor your server response time after each change.