Ticket #122 (closed bug: fixed)

Opened 7 years ago

Last modified 6 years ago

slow svn co http://svn.fedoraproject.org/svn/hosted/...

Reported by: apevec Owned by: mmcgrath
Priority: major Milestone:
Component: Hosted Projects Version: Production
Severity: High Keywords:
Cc: sskracic@…, twaugh@…, andy@… Blocked By:
Blocking: Sensitive:

Description

We noticed slow checkouts via anonymous http://svn.fedoraproject.org/ while the same co via svn+ssh is acceptably fast, for example:

time svn co svn+ssh://svn.fedoraproject.org/svn/hosted/aplaws/users/

real ~ 20s

time svn co http://svn.fedoraproject.org/svn/hosted/aplaws/users/

real ~ 6min

I guess this also affects other hosted projects based on Subversion.

Change History

comment:1 Changed 7 years ago by sskracic

In addition to that, anonymous checkout is not possible from some boxes (IP address available on request). The svn+ssh checkout from the same box works nice, wget http://svn.fedoraproject.org/svn/hosted/aplaws/users/ works, but the:

svn co http://svn.fedoraproject.org/svn/hosted/aplaws/users/

simply hangs. Here's the output of netstat -t:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
tcp        0    372 local.address:39472         git.fedora.redhat.com:http  ESTABLISHED 

The box is running RHEL4U5.

comment:2 Changed 7 years ago by apevec

  • Priority changed from major to critical
  • Cc kwade@… added
  • Owner changed from jkeating to mmcgrath

comment:3 Changed 7 years ago by francois

I am having the same problem here. I am using subeclipse and I cannot even browse the Repository as it hangs until it fails

svn: PROPFIND request failed on '/svn/hosted/aplaws' svn: Connection reset

comment:4 Changed 7 years ago by mmcgrath

  • Status changed from new to assigned

I'm slowly working on this issue with GIT, they don't seem to think there is a problem. For now use https instead of http.

comment:5 Changed 7 years ago by mmcgrath

  • Priority changed from critical to major

apevec, can you email me what location you are attempting to connect from? mmcgrath redhat.com.

comment:6 Changed 7 years ago by apevec

Hosts I tried were in RHT MUC office. But now http://www.ohloh.net/projects/5256/enlistments/new doesn't seem to accept HTTP SVN URL at all: after submitting, hangs at Checking server connection...

comment:7 Changed 7 years ago by mmcgrath

just to be clear, does the svn+ssh still work from there?

comment:8 Changed 7 years ago by pboy

Same problem here.

Using the machine in my home office (German Provider Arcor, 82.82.0.0/15): For a checkout of trunk via svn+ssh needs 4 min 38 sec. For a checkout of trunk via http: after 90 min about 20% of the modules were downloaded. A checkout via https didn't work at all (405 Method Not Allowed)

Using my machine at university (high speed German Research Network, 134.102.0.0/16) a checkout using http doesn't work at all. After trying for 6 min the fedoraproject host cancelled the connection.

Peter

comment:9 Changed 7 years ago by apevec

does the svn+ssh still work from there?

from RHT MUC svn+ssh works fine, and ohloh.net can't use svn+ssh

comment:11 Changed 7 years ago by apevec

  • Cc sskracic@… added; kwade@… removed

comment:12 Changed 7 years ago by apevec

HTTP seems to be fixed in the meantime, reported test case svn checkout is now ~23s via

NB: as a workaround project Aplaws has setup a svn mirror at http://svn.aplaws.org/svn/aplaws/ This is also used to generate commit alerts (ticket 123)

comment:13 Changed 7 years ago by mmcgrath

Can anyone else that was having this problem please re-test. We've had another request come in from RHIS following up. I'm ont sure if they made any changes or not.

comment:14 Changed 7 years ago by twaugh

  • Cc twaugh@… added

comment:15 Changed 7 years ago by mmcgrath

  • Cc andy@… added

comment:16 follow-up: ↓ 17 Changed 7 years ago by apevec

HTTP seems to be fixed in the meantime

That was from a RHT internal machine (MUC office) From outside it either slow (test case is ~7.5min) or doesn't work at all

comment:17 in reply to: ↑ 16 Changed 7 years ago by francois

From outside it either slow (test case is ~7.5min) or doesn't work at all

Same goes here. I have tried on our corporate network and it took over 20mins to check out the trunk.

comment:18 Changed 6 years ago by mmcgrath

  • Resolution set to fixed
  • Status changed from assigned to closed

This should now be fixed. Long story short we had to:

net.ipv4.tcp_window_scaling = 0

on the svn box. We will likely have to leave this set until the cisco firewall we are behind is upgraded. In the meantime though, this slowness should be gone.

Note: See TracTickets for help on using tickets.