bug description (occurred issue): Some of our artists have reported that their SVN update process is occasionally very slow, with speeds ranging from 2 to 5 kBytes/s instead of the expected 10000 kBytes/s. To address this, we increased the asyncThreads setting in /etc/scm/config.yml from 4 to 80, and also raised the number of workers from 4 to 8 in the webapp configuration. Despite these adjustments, the issue persists. We are unsure if this change was effective or if there are additional steps we can take to further diagnose and resolve this problem. Any guidance on this matter would be greatly appreciated.
expected result / system behavior: SVN Update are always at an expected speed.
observed result / system behavior: SVN Update update speed occasionally drop to a very low value.
SCM-Manager version and installed package: We were at SCM-Manager 3.2.1, and we I’ve just now update to SCM-Manager 3.3.0
Additionally, would you also provide some documentation with regard to the “Enable GZip Compression” checkbox in the Subversion Configuration setting? In particular, is this something that we can enable and disable at anytime?
The issue happened to us in 3.2.0. We have recently upgrade to 3.3.0 and the slowness happened once. We’ve doubled the asyncThread again and implement a system to log the traffic on the host machine.
We’ve tried to reproduce the poor down-/upload locally and could not see a difference. What file type (size/amount) did you attempt to use for the commit?
from version 3.2 to 3.3 were no changes related to SVN. Therefore we have no idea why you experience a slow down in updating assets.
In your initial post you wrote that only some artists experiencing slow downs. Do they have something im common?
Their connection to the SVN server was also properly setup.
One thing that just come up in my mind is that, the we are running SCM-Manager docker container in rootless mode. Would there be any docker configuration that might have affect the speed?
It’s been a week since we have a report on SVN being slow.
However, I believe that the performance can be further improve for better speed. Is there any configuration changes that you would suggest to optimize our system to serve SVN to about 30 artists?
Recently, we also bump to the “The server sent a truncated HTTP response body.” error message. Is there a configuration where we can prevent this from happening again?
We do use reverse proxy for external artists. However, the speed issue was in the context of using SVN directly without reverse proxy through our internal network.
could you please provide a trace log? To create one please install the SCM-Manager support plugin.
You can share the result with me via a private message.
.