NextCloudPi and Talk: Configuration incompatible?

I’m using NextCloudPi on a RaspberryPi 4 for some time now. It’s working great and Nextcloud is very responsive. A few weeks ago I decided to install Talk App. I followed the instructions HowTo: Setup Nextcloud Talk with TURN server to install coTURN and configure Talk. Talk is now usable. Or let’s say bearable… As soon as two participants join the same conversation via Browser (Firefox, Chrome, Safari… doesn’t matter) things are getting slow. Every single action takes approx. 20s. Sending a message, starting a call, changing names, even leaving Talk takes up to 20s. Monitoring CPU load with “htop” while Talk is lagging shows: CPU is either in idle or has very little load. (0.12-0.25 average) So it’s not caused by lack of CPU power.

I’m now trying to find the root cause of this and improve speed. What I did so far:

  • https://github.com/nextcloud/spreed/issues/2211 and https://techwombat.com/enable-http2-apache-ubuntu-16-04/ gave me some hints. I’ve checked the Apache, HTTP/2 and PHP settings. NextCloudPi seems to be configured correctly according to these links. But it’s still slow.
  • Someone mentioned that he had to use mod_php and mpm_prefork instead of php-fpm and mpm_event. So I tried:
    install libapache2-mod-php7.3
    a2disconf php-fpm
    a2dismod mpm_event
    a2enmod mpm_prefork
    a2enmod php7.3
    reboot
    Talk is now as fast as it should be and not stalling anymore. :slight_smile:

But there’s a problem. I don’t know if these changes have an impact on system stability, performance, security or maintainability. I’ll switch back to the old configuration. Better to have a slow system that was configured by an expert rather than a fast and unstable one configured by a noob :wink:

Nevertheless: It seems some people are running Talk with Apache2, mpm_event, PHP-FPM and HTTP\2 without problems. I would like to debug and find out what’s wrong with the NextCloudPi configuration. But I don’t know where to start.

  • Does anybody know what could cause Talk to stall the system?
  • What’s the best way to find the process or configuration that causes the problem?
  • Where can I find the log-file of Talk?

My system:
Nextcloud: 18.0.4 (installation based on NCP image “NextCloudPi_RPi_03-28-20.tar.bz2”)
Talk: 8.0.8
coTURN: 4.5.1.1-1.1
Apache: 2.4.38
PHP: 7.3.14
Hardware: Raspberry Pi 4B 4GB

I’ve had some time to try several other things. To make a long story short: Nothing worked, except switching to mod_php and mpm_prefork.

(Nextcloud.log had no relevant entries from Talk app. Increasing php memory limit showed no effect. Comparing versions of php.ini showed no relevant differences. Adding Debian testing repo and installing latest versions of apache2 and php7.3 didn’t improve situation. Changing some settings in apache2.conf and mpm_event.conf: no success)

If someone has an idea what else to test, I’ll give it a try. Otherwise I’ll accept the fact that Talk is very slow with the current NextCloudPi configuration.

In case someone is facing the same problem:

I finally found the root cause. NextCloudPi’s default configuration limits the number of PHP threads to 4. To get a properly working Talk app, I had to increase this limit to at least 6. With this setting, Talk works perfectly for two users simultaneously accessing a conversation. (I assume that this number has to be scaled up linearly if you need more than two concurrent users. But I cannot test this.)

  • To change NextCloudPi settings, you have to go to NCP Web Interface -> nc-limits -> PHP threads.

The absolute limit for number of php threads depends on your system resources. You might want to read https://www.technik-blog.eu/2018/08/php-fpm-einstellungen-optimieren.html or https://www.kinamo.be/en/support/faq/determining-the-correct-number-of-child-processes-for-php-fpm-on-nginx

nc-limits will modify the value of “pm.max_children” in file “/etc/php/7.3/fpm/pool.d/www.conf”. But beware: Don’t modify this file manually when using NextCloudPi. (Like I did….) It will be overwritten by nc-limits on next reboot of the system. So you could end up thinking this setting has no effect at all.

3 Likes