Hello Alex, unfortunately this is OM question We are using custom client side JS to measure network characteristics ping/jitter/upload/download to made this check more "realistic" we are measuring both upload/download+processing time i.e. while downloading we are generating new byte sequence, on uploading read every byte being sent maybe this might be improved
On Thu, 12 Nov 2020 at 15:23, Ninnig, Alexander < alexander.nin...@rechnungshof.rlp.de> wrote: > Hello, > > to check the performance I just startet several network tests via > openmeetings. > What's weird: the network-test via openmeetings4 shows significally better > download-rates (20 Mb/sec) than openmeetings 5 (4 Mb/sec). > Those values seem to be low altogether, because I am doing these tests in > a gigabit-network. > > * Both openmeetings-servers are virtual machines (VMware, VM-Version 11) > with 8 CPU-cores and 8 GB RAM and VMXNET3-LAN-Cards. > * Both are connected to gigabit-switches. > * Openmeetings 4 runs on Ubuntu 18.04.5 LTS, openmeetings 5 runs on Ubuntu > 20.04.1 LTS. > * Clients are configured to open the website directly (not using proxy). > * I entered some commands to display the ubuntu-network-adapter-details > and the results are pasted below. Both servers show "Speed: 10000Mb/s" and > "Duplex: Full". The openmeetings5-server additionally shows some > docker-network-details, I'm not familiar with. > > I guess this is a linux-question, not an openmeetings-question, but maybe > someone in here experienced similar behaviour and found ways to increase > the performance. > > - why are the upload-rates way better than the download-rates? > - why are these values so low (in a gigabit-environment)? > > > > ---------- > > openmeetings 5-server > > ethtool ens160 > Settings for ens160: > Supported ports: [ TP ] > Supported link modes: 1000baseT/Full > 10000baseT/Full > Supported pause frame use: No > Supports auto-negotiation: No > Supported FEC modes: Not reported > Advertised link modes: Not reported > Advertised pause frame use: No > Advertised auto-negotiation: No > Advertised FEC modes: Not reported > Speed: 10000Mb/s > Duplex: Full > Port: Twisted Pair > PHYAD: 0 > Transceiver: internal > Auto-negotiation: off > MDI-X: Unknown > Cannot get wake-on-lan settings: Operation not permitted > Link detected: yes > > dmesg |grep eth0 > [ 2.272277] vmxnet3 0000:03:00.0 eth0: NIC Link is Up 10000 Mbps > [ 2.295532] vmxnet3 0000:03:00.0 ens160: renamed from eth0 > [ 476.320685] eth0: renamed from vethc10076e > [196875.071160] vethc10076e: renamed from eth0 > [196916.660163] docker0: port 1(veth095d6f5) entered blocking state > [196916.660166] docker0: port 1(veth095d6f5) entered disabled state > [196916.660313] device veth095d6f5 entered promiscuous mode > [196917.010394] eth0: renamed from veth426fe1f > [196917.030295] IPv6: ADDRCONF(NETDEV_CHANGE): veth095d6f5: link becomes > ready > [196917.030352] docker0: port 1(veth095d6f5) entered blocking state > [196917.030355] docker0: port 1(veth095d6f5) entered forwarding state > > ---------- > > openmeetings 4-server > > ethtool ens160 > Settings for ens160: > Supported ports: [ TP ] > Supported link modes: 1000baseT/Full > 10000baseT/Full > Supported pause frame use: No > Supports auto-negotiation: No > Supported FEC modes: Not reported > Advertised link modes: Not reported > Advertised pause frame use: No > Advertised auto-negotiation: No > Advertised FEC modes: Not reported > Speed: 10000Mb/s > Duplex: Full > Port: Twisted Pair > PHYAD: 0 > Transceiver: internal > Auto-negotiation: off > MDI-X: Unknown > Cannot get wake-on-lan settings: Operation not permitted > Link detected: yes > > dmesg |grep eth0 > [ 2.450005] vmxnet3 0000:03:00.0 eth0: NIC Link is Up 10000 Mbps > [ 2.457827] vmxnet3 0000:03:00.0 ens160: renamed from eth0 > > ---------- > > Best regards, > Alex > -- Best regards, Maxim
