[split] WebUI performance

[sultanoswing]

I am on a Pi4 4GB, about 15k tracks in 1k2 albums, and on my 7'' display, reloading the entire library takes about 3/4 seconds; the search results are returned within 2/3 seconds.
It depends for sure on the Pi horsepower, but also on the SD card read speed (and my current one is not high-performance)... I don't remember what were the timings when I had moOde running on a Pi3, and anyway, at that time my CD library was not yet completely transferred to it, so the volume of information was way too little to compare with yours.

Maybe today I'll reflash the 8.3.7 onto a high-speed video-grade SD card (I think it's about time, almost one year has passed since when I first considered doing it...), perform some searches, and try to see if any speed gain can be achieved.

I appreciate it...and love how we spend hours trying to shave seconds

[Nutul]

I appreciate it...and love how we spend hours trying to shave seconds

Lol,

it's sooo meaningless to check how long it takes in terms of seconds to perform a search... especially when after that you just sit back, relax, and enjoy a good listening in the 1000s of seconds

[Tim Curtis]

1. Regarding the browser accessing the moOde WebUI, you didn't mention which browser (and on which OS) you're using. Try different browsers---e.g., Chromium, Firefox, Edge, Safari, etc., whatever is available. They behave differently at different tasks. Also, if you're using privacy/security add-ons, try disabling any checking of your moOde player "site".

2. Regarding WiFi, go to the 5 GHz band if you're still using 2.4 GHz. Fundamentally, the throughput will be better and there's likely to be less interference which also affects throughput.

3. On the moOde side, using an SSD on one of the USB3.0 interfaces of an RPi4B should give very good Library performance. The RPi5B may yield even faster performance but it's a matter of diminishing returns and, for me, increasing cost/performance ratio. This is especially so since the RPi5B will almost always need active cooling and a more muscular power source, which also add to the cost.

Also thanks!

1. Brave browser, on Android phone & iPad4. When I use the desktop PC with Brave the library refreshes in around 3 seconds, and does the 'Knopfler' search also in 3 seconds - very speedy, and slightly quicker than on the phone or iPad.

2. I'm stuck on 2.4Ghz due to the location of the Pi & my AP's.

3. As above - the performance is probably limited by phone / iPad browser related based on #1, rather than my otherwise speedy NAS. 

TLDR; am therefore happy with the Pi 3B after all  . Especially since I had been concerned about the USB-network shared BUS, but it's not a practical concern.

Sometimes 2.4GHz is the only option. That frequency band has greater range than the 5GHz band. 

You might want to test your network speed and quality by running a few commands for example a 20 second ping test from the Pi to the Router/AP and then an ifconfig command on the Pi.

Here's an example ping from one of my 3B+ Pi's connected via 5GHz WiFi to Router. Ctrl-c after 20 seconds and then examine the ping statistics. Note the % packet loss and rtt (round trip times)

Code:

pi@moode:~ $ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.53 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.93 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.67 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.88 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=2.21 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2.91 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.22 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=8.11 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=4.13 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.42 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.38 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=3.11 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.30 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=4.34 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=2.57 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=1.48 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1.38 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.30 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=1.47 ms
^C
--- 192.168.1.1 ping statistics ---
21 packets transmitted, 21 received, 0% packet loss, time 20030ms
rtt min/avg/max/mdev = 1.223/2.299/8.113/1.574 ms

Here's ifconfig output. Note the stats for wlan0.

Code:

pi@moode:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       ether b8:27:eb:90:be:5b  txqueuelen 1000  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 0  bytes 0 (0.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
       inet 127.0.0.1  netmask 255.0.0.0
       inet6 ::1  prefixlen 128  scopeid 0x10<host>
       loop  txqueuelen 1000  (Local Loopback)
       RX packets 741  bytes 122074 (119.2 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 741  bytes 122074 (119.2 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.121  netmask 255.255.255.0  broadcast 192.168.1.255
       inet6 fe80::4d1f:257c:a601:e79  prefixlen 64  scopeid 0x20<link>
       inet6 fd87:f129:9943:4934:a3fd:9e4c:6b0f:a419  prefixlen 64  scopeid 0x0<global>
       ether b8:27:eb:c5:eb:0e  txqueuelen 1000  (Ethernet)
       RX packets 90435  bytes 16641819 (15.8 MiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 14828  bytes 14667469 (13.9 MiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[TheOldPresbyope]

On the endlessly fascinating   subject of WiFi -

You may have noticed that many commercial streamers have external stub antennas on their boxes. That's de rigueur if metal cases are involved. Even without cases, getting the antenna out in the open can make a big difference in throughput (e.g., bytes/sec).

Unfortunately, regular model Pis don't provide for external antennas (compared, say, to my CM4). If the Pi is buried in cables, cabinetry, etc., using an external USB-WiFi transceiver on the end of a short cable can do wonders. The farther away the access point, the more true this is.

Regards,
Kent

PS - There's any number of hacker posts out there on the subject of retrofitting an external antenna to a Raspberry Pi. I don't advocate for several reasons but it's another option if you don't mind brutalizing your Pi.