Apache Guacamole working poorly

[MrPorcine]

OK, this is a corner case but I'm hoping someone can give me some guidance on how to proceed.
I have Apache Guacamole somewhat working. This is piCore16. Whenever Guacamole needs to serve a big change in the underlying display, it fails and the client get a message that it needs to reconnect. Reconnecting works until the next big change in the display.
To make this work at all, you need x11vnc, a java run time edition, tomcat, and guacamole both server and client. I have put this all together. X11vnc is a custom extension loaded by onboot.lst. Tomcat9, Java, and guacamole are concatenated with the piCore base, so they are part of the base filesystem loaded at boot.
And it works - sort of. Using top (busybox edition) it looks like memory is not a issue. Disk space is definitely not an issue. Yet guacamole is resource limited somewhere.
I have the same setup in a Debian Trixie distribution using the same versions of the firmware, the same configuration files and the same startup commands. It works perfectly.
Did I mention this is on a Pi 3, so 1MB of memory.

So my question is how can I find what is limiting guacamole?

[Paul_123]

Adding to the base increases the size of the rootfs ramdisk.  I would bet it is memory related.   A swap file/partition is not used by default.   But you should try one.

[MrPorcine]

Maybe. When I run free this is the result. Looks OK to me.

Code: [Select]

tc@box:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:         906.7M      401.7M      113.4M      301.5M      391.6M      189.1M
Swap:        149.9M           0      149.9M
tc@box:~$
I'll go back to custom extensions for all and see what happens. Since extensions are loaded into RAM, I don't see the RAM penality for increasing the size of the root file system. It does mean a longer delay before I can put up the first splash screen. If I'm wrong about this, please set me straight.

[Paul_123]

They are not loaded to ram by default.  They are loop mounted read only file systems.  Only symlinks are created on the rootfs.

True, there is a slightly longer boot.

If it’s not Ram, then it would have to be some IO limitation.  Been a while since I looked, what IO scheduler is Trixie using?

[MrPorcine]

I've done some more work exploring this problem, but Guacamole is still not working well. When I first attach to Guacamole, response is good for maybe 10 seconds, then whenever the screen changes dramically Guacamole disconnects and the client has to reconnect. The grace period only works for the first client after a boot on the server.

The available schedulers on the server are "none [mq-deadline] kyber bfq". I've tried them all, none fix the problem. mq-deadline is the default.

I've substuted a faster SD card, no change.
I've tried a pi 4 in place of the pi 3, no change in Guacamole. In general, the Pi 4 makes the UI snappier. It could be that with a Pi 4 I get a longer grace period before the first disconnect. I can't think of a reason where the problem is independant of processor speed.

I've tried different clients, so far Brave and Chromium. Using a very fast client makes no difference.