Feedback - Poor Performance Using 1.34
Posted: Sun May 09, 2021 7:47 pm
I am using ZM 1.34 as found in the Devuan (Debian clone) repo. That means I had to update to the Devuan 'chimaera' release, basically Debian 'bullseye'. That meant a Linux kernel jump from 4.16.x or 4.19.x to 5.10.x.
I have not noticed any issues running Linux 5.10 on a Supermicro 2558 and 2758 boards with 16 GB of RAM.
After debugging the "upgrade" from Devuan 'ascii' to Devuan 'chimaera' (issues with deprecated "shorewall" features) I then focused on the ZM issues. Since a jump of 2 major releases is technically not supported in Debian or Devuan you jump to the intermediate level, Devuan 'beowulf', equivalent to Debian 'buster'. That meant ZM was borked because Devuan does not have ZM in the 'beowulf' repos. Once 'chimaera' is installed you can reinstall ZM, but then "zmupdate.pl" is borked by a missing call to update 'zm.*' database permissions. Once the database permissions are fixed and apache is told to enable 'zoneminder', then ZM works again.
Or does it?
From what I can tell the ZM web GUI may need some tuning. Whatever it is doing it is causing clients to seemingly crawl when displaying something as simple as a montage. I thought it was my PC, but 8 cores at 3.2 GHz with 16GB of RAM and barely any load said, "Nope, not here."
So I looked at my dedicated ZM server; no GUI on it, completely "headless". Via the ZM web GUI it reports Load is less than 3 and "shm" is less than 40 percent. Looking at "htop" in Linux via SSH shows all 8 cores are working and almost 4GB of RAM is used out of 16GB.
Networking is not an issue. The cameras are physically separate from the rest of the house; only the ZM server directly sees them over a dedicated GB port and 1 Ethernet switch. The house is all GB networking, unchanged, quite reliable, and other household video streaming applications are working perfectly.
So it does not appear to be a physical resource issue. It looks more like an application tuning issue. [snark]Or has PHP gotten that bad?[/snark]
So why do the "Cycle", "Montage", and "Montage Review" features cause my web browser to turn sluggish at times? Could it be the new fancy ZM web GUI? Why can't we have a simple URL to the actual "Cycle" or "Montage" group that avoids using the web GUI entirely, like in ZM 1.30+dfsg? Yes, I have entered a feature request asking just that question.
Or are there strange problems running ZM 1.34 on Linux 5.10? The hardware is all unchanged and still supported. Process of elimination troubleshooting points to software, something than needs to be tuned, but what? Yes I have gone through all of the ZM options menus.
Honestly, this upgrade was a letdown in terms of performance, like trading in a Ferrari for a YUGO. If you know cars (I have worked on both and many others), then you will understand my analogy.
ZM 1.30+dfsg on Devuan 'ascii' was "rock solid" and a "real go-er", but I upgraded because Devuan 'ascii' is now "oldstable" and not getting much of anything in terms of upgrades. Sooner or later I had to do this upgrade if I did not want my ZM server to be a functioning museum piece.
I have not noticed any issues running Linux 5.10 on a Supermicro 2558 and 2758 boards with 16 GB of RAM.
After debugging the "upgrade" from Devuan 'ascii' to Devuan 'chimaera' (issues with deprecated "shorewall" features) I then focused on the ZM issues. Since a jump of 2 major releases is technically not supported in Debian or Devuan you jump to the intermediate level, Devuan 'beowulf', equivalent to Debian 'buster'. That meant ZM was borked because Devuan does not have ZM in the 'beowulf' repos. Once 'chimaera' is installed you can reinstall ZM, but then "zmupdate.pl" is borked by a missing call to update 'zm.*' database permissions. Once the database permissions are fixed and apache is told to enable 'zoneminder', then ZM works again.
Or does it?
From what I can tell the ZM web GUI may need some tuning. Whatever it is doing it is causing clients to seemingly crawl when displaying something as simple as a montage. I thought it was my PC, but 8 cores at 3.2 GHz with 16GB of RAM and barely any load said, "Nope, not here."
So I looked at my dedicated ZM server; no GUI on it, completely "headless". Via the ZM web GUI it reports Load is less than 3 and "shm" is less than 40 percent. Looking at "htop" in Linux via SSH shows all 8 cores are working and almost 4GB of RAM is used out of 16GB.
Networking is not an issue. The cameras are physically separate from the rest of the house; only the ZM server directly sees them over a dedicated GB port and 1 Ethernet switch. The house is all GB networking, unchanged, quite reliable, and other household video streaming applications are working perfectly.
So it does not appear to be a physical resource issue. It looks more like an application tuning issue. [snark]Or has PHP gotten that bad?[/snark]
So why do the "Cycle", "Montage", and "Montage Review" features cause my web browser to turn sluggish at times? Could it be the new fancy ZM web GUI? Why can't we have a simple URL to the actual "Cycle" or "Montage" group that avoids using the web GUI entirely, like in ZM 1.30+dfsg? Yes, I have entered a feature request asking just that question.
Or are there strange problems running ZM 1.34 on Linux 5.10? The hardware is all unchanged and still supported. Process of elimination troubleshooting points to software, something than needs to be tuned, but what? Yes I have gone through all of the ZM options menus.
Honestly, this upgrade was a letdown in terms of performance, like trading in a Ferrari for a YUGO. If you know cars (I have worked on both and many others), then you will understand my analogy.
ZM 1.30+dfsg on Devuan 'ascii' was "rock solid" and a "real go-er", but I upgraded because Devuan 'ascii' is now "oldstable" and not getting much of anything in terms of upgrades. Sooner or later I had to do this upgrade if I did not want my ZM server to be a functioning museum piece.