Interesting. I am using a custom wakeword with snowboy (.pmdl) instead of one of their universal models and I have low CPU usage (~10% when the Rhasspy webserver is disabled). Maybe that makes a difference?
There certainly is a difference between pmdl and umdl wakeword. Jarvis.umdl size is 3.5MB, my personnal wakeword size is about 10kB. Jarvis has multiple embedded hotwords that makes it heavier.
Thanks to @tuxedo78 for his useful workaround, that makes a big difference. With 2 personnal wakewords my rpi zero now runs with about 25 % CPU load.
@synesthesiam is it possible to have a way to enable/disable the webserver through commandline for future versions? That would really help for Pi-zero… And by leaving more CPU cycles to wakeword (especially for snowboy), I really think that it should improve wakeword detection performance.
fx
1 Like
+1 for this for 2.5, if possible @synesthesiam. Even an environment variable or command line argument or something that could be included in my docker-compose.yaml to disable the webserver would be amazing. Once I have everything on my Pi Zero satellite configured (using external MQTT), there’s no need for me to be running the web server.
Hello,
Yes, I do not understand this saturation, when:
mosquitto_sub -v -h “localhost” -p 12183 -t “#”
2.5 on Odroid xu4
I’ll add an option to rhasspy-voltron to disable the web server. Let’s see if that helps. I’ve also noticed supervisord sometimes leaves behind running Rhasspy processes. Do you see anything after exiting with ps -ef | grep rhasspy?
All my sites (Pi0, Pi3B+ and VM/master) run in Docker and I have never observed processes still running after stop.
Regarding this option, please could you elaborate the exact impacts of disabling the web server? Is it pure configuration stuff (need to change profile.json manually which is quite OK) or does it impact binding with external programs like Jeedom?
Well I checked and disabling web server will completly break Jeedom interface so not an option for me 
Oh, yeah. Jeedom uses the HTTP and websocket APIs extensively.
Can you tell if the CPU usage is coming specifically from the web server’s Python process?
Yes this is definitely coming from the webserver because even with an install from scratch (deleted .config/rhasspy directory), the load is high (25% on Pi-zero without anything is really unexpected) despite there is no running service.
If you have any clue how to dig into the Quart webserver server, I can give it a try…
Not really. Anyone know a good Python profiler?
well the webserver could be disabled only for sattelites ( but it would be nice to have a way to manage/config the sattelites from the server )
Can confirm that there are no supervisord “left-behind” processes for me either. On my Pi Zero, the CPU usage is coming from a python process, not a rhasspy-* process. So when I comment out the app.run() lines in rhasspyserver_hermes/__main__.py and restart the container, the CPU usage is much more manageable. I don’t use Jeedom and have a purely external MQTT setup, so it has made my satellites much more responsive.
The web server shouldn’t be burning so much CPU, so this may be a bug. I’m worried it’s processing a lot of unnecessary MQTT messages.
Are you using UDP for you wake word audio, or MQTT (the default)?
I’m using UDP on my satellites.
1 Like
Pulled the latest Docker image and the new switch --noweb-server is working great. Thanks @synesthesiam!
I confirm that the load comes fro mthe web server. Again, the issue is observed even on a “debugging” PI with no “applicative” service running (everything disabled) : only mqtt and webserver.
I gave a try to cProfile. Here are the ouputs after sorting on tottime
| ncalls | tottime | percall | cumtime | percall | filename:lineno(function) |
|---|---|---|---|---|---|
| 13598 | 14.656 | 0.001 | 14.656 | 0.001 | {method ‘poll’ of ‘select.epoll’ objects} |
| 12956 | 3.006 | 0 | 5.776 | 0 | pathlib.py:62(parse_parts) |
| 23041 | 2.755 | 0 | 4.726 | 0 | {built-in method posix.stat} |
| 8126 | 2.301 | 0 | 6.399 | 0.001 | :1356(find_spec) |
| 13598 | 2.241 | 0 | 43.216 | 0.003 | base_events.py:1679(_run_once) |
| 13533 | 2.063 | 0 | 15.471 | 0.001 | utils.py:102(observe_changes) |
| 14972 | 1.77 | 0 | 24.293 | 0.002 | {method ‘run’ of ‘Context’ objects} |
| 106918 | 1.313 | 0 | 1.313 | 0 | {built-in method sys.intern} |
| 1273 | 1.133 | 0.001 | 1.133 | 0.001 | {built-in method builtins.compile} |
| 814 | 1.12 | 0.001 | 1.12 | 0.001 | {built-in method marshal.loads} |
| 41464 | 1.054 | 0 | 2.602 | 0 | :56(_path_join) |
| 12952 | 0.984 | 0 | 7.127 | 0.001 | pathlib.py:633(_parse_args) |
| 41464 | 0.966 | 0 | 1.279 | 0 | :58() |
| 12959 | 0.894 | 0 | 1.599 | 0 | pathlib.py:693(str) |
| 14619 | 0.732 | 0 | 1.404 | 0 | base_events.py:707(_call_soon) |
I applied the Quickstart/Hello-world guide from Quart website… and this is eating 30% of my CPU. Like my “empty” Rhasspy webserver…
So there is clearly an issue coming from Quart itelf (and not even the way it’s used by Rhasspy). If you are in touch with the Quart dev team, can you report them this issue?
That’s weird.
I also use Jeedom and have no problem except for TTS. I think that @KiboOst 's plugin Jeerhasspy uses HTTP API for the TTS command.
So, I use MQTT in Jeedom for TTS and everything works like a charm.
I have also tried to do TTS with squeezelite and LMS plugin as I use my rhasspy satellite as a squeezebox but that isn’t so elegant…