Faculty of information technology

database lock – This was partially fixed by increasing the timeout.
∙ Website being sometimes very slow and unresponsive – This problem occurred
when too many write operations kept the database locked for a long period of time. It
was partially fixed by making the main daemon handle transactions in smaller bursts
and sleeping for a moment after each.
As can be seen from tables
6.3
and
6.4
, the memory usage was relatively small and
scaled very well with increasing numbers of routers. The CPU load was spiking at 0.92
during execution of operations (like changing LAN to all devices at once), but kept around
0.00 once the cs-controller finished its work. Even during the ping flood scenario, the CPU
load didn’t get over 0.05. An interesting statistic is the amount of OpenVPN overhead
during the ping test. While 8200 Kb/s was going through the tunnel, the total traffic
going through its physical interface was 13600 Kb/s. When CS was restarted while 600
devices were connected, it took approximately 7 minutes until all devices came back online
and synchronized (although 500 of them were online within 2-3 minutes). When validating
600 devices, it took 4 minutes until they were all online and synchronized.
41

---

Scenario
Memory usage
[MB]
(100 routers)
Memory usage
[MB]
(350 routers)
Memory usage
[MB]
(600 routers)
Routers are asking for
validation.
292
258
339
Routers are connected
but idle.
290
391
581
Clicked “validate” for
all routers.
297
347
756
Set LAN to public
mode for all routers.
304
403
601
Ping flood (tun: 8200
Kb/s, eth: 13600
Kb/s).
295
428
598
Table 6.3: Measurements of total used memory during various test scenarios.