Hey everyone,
First I would love to say how much I value this project, I have been toying for some time and it’s truly amazing!
I am currently deploying the app-server in a containerised setup using balena and a Raspberry Pi 3. Since it wasn’t possible to build it from source in an alpine (due to some library error-gobindata) I am simply using a debian image and installing it using apk.
The problem is that I am trying to squize several services into the raspberry pi and I need to optimise each and every service. Thus, I was wondering whether it was possible to disable the graphical interface of the app-server and use only the api endpoint.
Any other suggested optimisation that can lead to a reduced memory hungry app-server will be much appreciated!
I can provide any information necessary!
Thanks to this amazing community 
Could you define “memory hungry”? 
Hey,
You got me, it isn’t memory-hungry per se, but for my use-case I really need to optimise it as much as possible. I only need it to manage 1 device (receive uplinks).
Thank you so much for this amazing work!
Cheers
I’ve got LoraServer running without issue on a pi including all of the components. It’s basically a gateway that contains the gateway-bridge, network-server, and app-server and whist it’s tight, it does work
Thanks @Proffalken for your reply! I know it’s possible, but for several architectural reasons, currently all the loraserver infrastructure runs on a seperate “gateway” device and I only run the app-server on the raspberry pi. I was wondering whether users here now any tricks on how to optimise the app-server, ideally turning off all the web interface.
cheers!
If the only thing you’re running on the pi is the app server, it’s highly unlikely you’ll need to switch the web UI off, in fact I don’t even think it’s possible!
What else are you running on the Pi that you need to strip the web UI out?
Fwiw, I bought a Bitscope Blade Quattro a few months back and mounted 4 Pi’s on there - one for loraserver, one for influxdb, one for grafana, and one for our farm management solution. The one running loraserver runs Postgres, Redis, the network and app servers, and doubles as a router/gateway for the rest of the network, so I’m really not convinced you’re going to have the issues that you think you might!
https://twitter.com/MBConsultingUK/status/1140895870063448066 (I’ve since downgraded to an 8-port switch… 
)
Here is a view from the device statistics:
I am not saying that lora-app-server is hungry, but I am trying to cut corners on every service so as I can add even more services that are needed for my use-case. In canse I don’t manage, I will be splitting the application logic in two devices.
**Currently lora-app-servers receives an uplink every 5 minutes and pushes it to an online server http integration.
cheers!
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
297115192feb lora-appserver_1414191_1031626 1.68% 17.46MiB / 967.7MiB 1.80% 370MB / 445MB 53MB / 0B 0
1f778f471d71 lora-postgresql_1414193_1031626 2.64% 8.586MiB / 967.7MiB 0.89% 441MB / 366MB 23.3MB / 219MB 0
065cad55981d lora-redis_1414192_1031626 0.34% 2.102MiB / 967.7MiB 0.22% 505kB / 147kB 3.24MB / 205kB 0
a42141f09822 edgex-redis_1414184_1031626 0.51% 2.195MiB / 967.7MiB 0.23% 97.2kB / 82.6kB 5.32MB / 0B 0
b182a8291f66 edgex-export-distro_1414190_1031626 0.99% 4.906MiB / 967.7MiB 0.51% 42.2MB / 51.7MB 20.6MB / 0B 0
ff114784440f edgex-export-client_1414189_1031626 1.37% 5.02MiB / 967.7MiB 0.52% 9.04MB / 6.36MB 22.8MB / 0B 0
04170cb962e5 edgex-core-data_1414187_1031626 1.38% 5.691MiB / 967.7MiB 0.59% 58.1MB / 41.1MB 17MB / 0B 0
9a7750d43937 edgex-core-command_1414188_1031626 0.00% 5.273MiB / 967.7MiB 0.54% 12.7MB / 7.84MB 18MB / 0B 0
ba073f92fdc7 edgex-core-metadata_1414186_1031626 1.78% 5.797MiB / 967.7MiB 0.60% 8.94MB / 6.27MB 24MB / 0B 0
cca64c85b4c3 edgex-support-logging_1414185_1031626 1.50% 4.234MiB / 967.7MiB 0.44% 5.27MB / 4.72MB 19.2MB / 0B 0
5e759abbe012 edgex-core-config-seed_1414183_1031626 0.00% 0B / 0B 0.00% 0B / 0B 0B / 0B 0
e1f3de02873c edgex-core-consul_1414182_1031626 4.08% 38.9MiB / 967.7MiB 4.02% 47.5MB / 70.4MB 55.4MB / 336kB 0
fdc3998e0414 volume_1414181_1031626 0.00% 816KiB / 967.7MiB 0.08% 15kB / 0B 385kB / 0B 0
4a64e7558883 resin_supervisor 0.02% 76.62MiB / 967.7MiB 7.92% 0B / 0B 16.1MB / 49.2kB 0
ok, so you’re running Resin.io, docker, and a load of other things on that box, which means that you’re overloading it already.
I’d humbly suggest that getting rid of the lora server UI is not the solution to your problem, as even if it was possible all it’s serving is static Javascript to interact with the various API’s so it’s going to have minimal impact on that system.
I’d suggest either running this across multiple Pi’s, ditching Resin/Balena (even though it’s something that I love and have blogged about in the past!), or moving everything out of Docker containers and running them on the bare metal.
Failing that, either shell out for a Pi4 with 4G RAM, or look at a cloud provider such as DigitalOcean.com where you can get a more than adequate VM for under $10/month.
I’ve spent the last 20 years working as a Systems Administrator and Infrastructure Consultant, and you’re running too much on that Pi…
Hey @Proffalken,
Thank you so much for the time and effort you put into the reply.
I am using a raspberry pi because the project is in fact part of my master’s thesis in the area of edge computing. I managed to get Rpi running smoothly by deleting lora-redis and lora-postgre and configuring app-server to use the redis/postgres of the network server (which is located into a different board).
Since I have another 2 minimal services (small python scripts) I think I will be able to make it work without further distributing the architecture. If it is ok, would it be cool to contact you with DM for feedback on my setup? What I can do to improve/optimise without compromising important parameters of my use-case.
Thanks again
Sure, happy to take a look in this instance, just be aware that due to existing commitments it could be a few days before I get back to you.