Testing environment
- We will need two VMs for running client and server
- Subscription-manager
- Candlepin server
- We will also need separate network used only for communication between these two VMs
Create new network
- Start:
virt-manager
- Go to: "Edit -> Connection Details"
- Click at "+" in "Virtual Networks"
Setup new network
- Wizard has 4 pages
- Give your network some unique name
- Configuration of IPv4 (you can use default values, but make sure network is not already in use)
- Configuration of IPv6 (you can enable it and use e.g. fd00:dead:beef:55::/64, enable DHCPv6 in this case too)
- Select "Isolated virtual network" and "Enable IPv6 internal routing/networking"
Use new network
- Make sure VM (client) is not running
- Open preferences of selected VM
- Click on: "Add Hardware"
- Select: "Network"
- Change "Network source" to your new network created by wizard.
- There is no need to change other options
- Repeat previous steps for server too
Testing and final tweaking
- Start VMs login there and make sure new network interface is active and IP address(es) were assigned to it
- Try to ping from client to server and vica verse
- Modify
/etc/hosts
to simplify your further work
Traffic Control
- It can be used for shaping and scheduling of traffic
- Routers are usually responsible for this (fast, hardware)
- We can traffic control in Linux too using command:
tc
Traffic Control and some terminology
- Traffic Control in Linux can be assembled from "qdisc" (queuing disciple)
- We can simply imagine qdisc as FIFO or queue
- Qdisc can be classfull (usually used for scheduling) or it can be classless (usually used for shaping)
Netem and TBF
- Traffic Controll can be also used for simulation of condition of real network
- Qdisc called Netem can be used for simulating of delay, delay jitter, packet loss, corrupting of packets, etc.
- TBF (token bucket filter) can be used for scaling down of bandwidth
+---+---+---+------- +---+---+---+---+---+--------
| | | | | | | | | |
<--+ | Netem |<--------------+ | | TBF | |<----
| | | | | | | | | |
+---+---+---+------- +---+---+---+---+---+--------
Linux Traffic Control
- For our purpose we can use only netem for simulation of delay and delay jitter
- To list existing traffic control used at specific network inteface:
$ tc -s -d qdisc show dev eth0
Queue Length
- To get length of all queues we need to use another command:
$ ip link list
We can set new length of queue using following command:
$ ip link set dev eth0 txqueuelen 100
Netem
- To replace default qdisc with netem we have to use following command:
$ tc qdisc add dev eth0 parent root handle 1:0 netem delay 100ms
We can try to use ping, but we will get constant delay. To get more realistic result we need to set also delay jitter using following command:
$ tc qdisc change dev eth0 parent root handle 1:0 \
netem delay 100ms 10ms 25%
We will need to set same qdisc on server and client
Subman and Delay
- We can test delay using subscription-manager and curl command
$ time subscription-manager version
We can mimic recreating of TCP connection using following command:
$ time curl -k -u admin:admin "https://candle:8443/candlepin/"; \
time curl -k -u admin:admin "https://candle:8443/candlepin/status"
Proposed improvements
- If TCP connection was reused between REST API call, then result time would be twice smaller:
$ time curl -k -u admin:admin "https://candle:8443/candlepin/" \
"https://candle:8443/candlepin/status"
We could go even better, when HTTP/2 was used:
$ curl -k -u admin:admin "https://candle:8443/candlepin/" & \
curl -k -u admin:admin "https://candle:8443/candlepin/status"