You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Matthew Fletcher <MF...@serck-controls.co.uk> on 2011/04/20 15:06:20 UTC
Slow initial repo access (https method)
Hi,
We are using svn 1.6.16 on the server and have noticed that there is a large pause in the inital https requests, (snip of wireshark shown bellow). Basically it looks like this is a server side issue but i am not sure where to look for logs (apache ?).
10.141.80.130 (server)
10.141.81.134 (client)
No. Time Source Destination Protocol Info
1 0.000000 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
No. Time Source Destination Protocol Info
2 0.000125 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
No. Time Source Destination Protocol Info
3 0.000166 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0
No. Time Source Destination Protocol Info
4 0.000307 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=227
No. Time Source Destination Protocol Info
5 0.013041 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [ACK] Seq=1 Ack=228 Win=65308 Len=1460
No. Time Source Destination Protocol Info
6 0.013068 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228 Win=65308 Len=13
No. Time Source Destination Protocol Info
7 0.013084 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [ACK] Seq=228 Ack=1474 Win=64240 Len=0
No. Time Source Destination Protocol Info
8 0.029234 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=228 Ack=1474 Win=64240 Len=198
No. Time Source Destination Protocol Info
9 0.033499 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426 Win=65110 Len=266
No. Time Source Destination Protocol Info
10 0.225080 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [ACK] Seq=426 Ack=1740 Win=63974 Len=0
No. Time Source Destination Protocol Info
11 15.123199 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=426 Ack=1740 Win=63974 Len=485
No. Time Source Destination Protocol Info
12 15.123238 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=911 Ack=1740 Win=63974 Len=133
No. Time Source Destination Protocol Info
13 15.123401 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [ACK] Seq=1740 Ack=1044 Win=64492 Len=0
No. Time Source Destination Protocol Info
14 15.124022 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [PSH, ACK] Seq=1740 Ack=1044 Win=64492 Len=746
Note the giant 15 second wait between packets 10-11, and then fast afterwards.
See the slow packets 10-11 in full bellow;
Frame 10: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst: Dell_cf:17:71 (00:1e:c9:cf:17:71)
Internet Protocol, Src: 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x453c (17724)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (6)
Header checksum: 0x0000 [incorrect, should be 0xfe71]
Source: 10.141.81.134 (10.141.81.134)
Destination: 10.141.80.130 (10.141.80.130)
Transmission Control Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https (8443), Seq: 426, Ack: 1740, Len: 0
Source port: 50186 (50186)
Destination port: pcsync-https (8443)
[Stream index: 0]
Sequence number: 426 (relative sequence number)
Acknowledgement number: 1740 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 63974
Checksum: 0xb73c [validation disabled]
[SEQ/ACK analysis]
Frame 11: 539 bytes on wire (4312 bits), 539 bytes captured (4312 bits)
Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst: Dell_cf:17:71 (00:1e:c9:cf:17:71)
Internet Protocol, Src: 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 525
Identification: 0x4546 (17734)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (6)
Header checksum: 0x0000 [incorrect, should be 0xfc82]
Source: 10.141.81.134 (10.141.81.134)
Destination: 10.141.80.130 (10.141.80.130)
Transmission Control Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https (8443), Seq: 426, Ack: 1740, Len: 485
Source port: 50186 (50186)
Destination port: pcsync-https (8443)
[Stream index: 0]
Sequence number: 426 (relative sequence number)
[Next sequence number: 911 (relative sequence number)]
Acknowledgement number: 1740 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 63974
Checksum: 0xb921 [validation disabled]
[SEQ/ACK analysis]
Data (485 bytes)
0000 17 03 01 01 e0 5b aa 54 59 c4 53 f1 31 5a c3 00 .....[.TY.S.1Z..
0010 9f b8 89 74 7e 6a ce 5a a0 34 02 dc 78 6b a3 2d ...t~j.Z.4..xk.-
0020 64 2f 60 dc c6 80 00 3f 01 20 50 02 d2 4d 70 f2 d/`....?. P..Mp.
0030 4f 9d 82 a6 3a cc 8f 18 3f a3 d7 0b ea 1d 33 1b O...:...?.....3.
0040 84 b3 15 c2 5d de d5 6b 49 1a 72 a3 10 a2 8e b0 ....]..kI.r.....
0050 9c 82 9a 65 f0 05 38 3b 7d d2 9b 5c 1b ed b6 85 ...e..8;}..\....
0060 d5 0d 17 9a 99 5c a4 18 ac 12 d5 7d 26 82 a3 b3 .....\.....}&...
0070 d9 a2 66 07 52 d3 7f ea 26 69 f1 a5 ee a8 b9 21 ..f.R...&i.....!
0080 b9 98 d2 a8 e6 05 30 2d a2 53 8b 0b 59 bd 6e ed ......0-.S..Y.n.
0090 9a b6 4e 9e 7a 57 ad 16 bc 4e 6b f8 48 e3 d2 b3 ..N.zW...Nk.H...
00a0 8f 19 2d e6 0a 06 bf 7f 71 e0 74 a2 8e fa 92 59 ..-.....q.t....Y
00b0 7e 00 24 06 41 c6 f0 bc 74 f3 39 af 3c e3 34 20 ~.$.A...t.9.<.4
00c0 f4 35 9f 70 40 c6 95 2a 69 61 98 ff 58 52 5e 03 .5.p@..*ia..XR^.
00d0 50 c1 60 d5 27 53 48 60 c4 1b e7 a6 49 1d 98 f0 P.`.'SH`....I...
00e0 46 8c 25 b5 1f 7b 93 79 1b 52 02 e5 fd 9e 2c 6d F.%..{.y.R....,m
00f0 8e ed 6f 6c f3 8e 72 1e 76 0f 7c c0 f9 61 00 1c ..ol..r.v.|..a..
0100 95 21 f8 f5 e1 32 bd 83 47 65 d2 f4 21 7e b0 20 .!...2..Ge..!~.
0110 d6 45 48 30 a1 6b e8 e3 8e f0 58 ad f7 9e 5b ff .EH0.k....X...[.
0120 86 63 fe d1 1b 0c bb af e1 85 e1 d8 13 f0 00 78 .c.............x
0130 3a f6 de d6 77 40 be e8 e1 ab 4c e3 7c 7c ec 3d :...w@....L.||.=
0140 4c 56 e9 42 11 cb 42 13 81 75 66 70 01 63 c5 40 LV.B..B..ufp.c.@
0150 fa 2e 39 86 64 ac 7a da 38 0e aa 15 62 b1 4f 6f ..9.d.z.8...b.Oo
0160 f2 71 b8 12 64 f4 91 f2 1c 57 ae 15 05 20 42 2b .q..d....W... B+
0170 a3 6e 24 01 dc 8c fa b0 49 2f 5e 68 68 29 1d de .n$.....I/^hh)..
0180 c6 dc 14 44 76 91 6b 4b ed 4f 65 77 43 a1 56 df ...Dv.kK.OewC.V.
0190 4a 66 8d 00 e9 96 f7 3a 60 dd 5a 3e e7 4f a5 ae Jf.....:`.Z>.O..
01a0 6e 82 49 81 ce 4d a8 1e 2d 0d c6 ae 3e 5b ee 83 n.I..M..-...>[..
01b0 b0 29 72 91 48 57 54 72 f3 a1 59 46 cf ff dd 0b .)r.HWTr..YF....
01c0 95 ef 03 2b fe c0 4c 47 f1 cd e8 46 07 17 7c 1a ...+..LG...F..|.
01d0 d8 d0 bc 68 b4 ca 07 ec 73 87 eb 34 93 e5 1f 42 ...h....s..4...B
01e0 fa ce 60 11 f6 ..`..
any ideas why this packet takes so long to be created, or what operation preceded it can caused the slowness ?
regards,
Matthew J Fletcher
**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
A company registered in England Reg. No. 4353634
Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com Admin: post@serck-controls.co.uk
A subsidiary of Schneider Electric.
**********************************************************************
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.
This message has been scanned for malware by Mailcontrol. www.Mailcontrol.com
Re: Slow initial repo access (https method)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
You may wish to try the users@httpd.a.o list too, this is by now more of
an httpd discussion than a mod_dav_svn one.
Matthew Fletcher wrote on Thu, Apr 21, 2011 at 10:55:17 +0100:
> Hi,
>
> Poor description on my part sorry, in my httpd.conf i explicitly turned of hostname lookups. That made no noticeable difference.
>
> I think its mod_ssl/openssl (am using 0.9.8r) just being slow, unfortunately even with apache logs set to "debug" verbosity there is no output on this, so will try and turn on logging within mod_ssl.
>
>
> regards
>
> Matthew J Fletcher
>
>
> > -----Original Message-----
> > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > Sent: 21 April 2011 10:25
> > To: Matthew Fletcher
> > Cc: users@subversion.apache.org
> > Subject: Re: Slow initial repo access (https method)
> >
> > What do you mean by "accessing the repo via IP address"?
> > Without having read your link, I expect it does a reverse DNS
> > lookup on the client's address (i.e., the IP address of the
> > box where the working copy resides), and just accessing the
> > repository as http://192.87.106.227 instead of
> > http://svn.apache.org won't affect that.
> >
> > The test would be
> > % ssh svn.apache.org time dig -x '$(echo $SSH_CONNECTION |
> > cut -d " " -f 1)'
> >
> > (this assumes you have a sh-like, not csh-like, login shell)
> >
> > Matthew Fletcher wrote on Thu, Apr 21, 2011 at 10:16:29 +0100:
> > > Hi,
> > >
> > > Our IT guys have been quite helpful and checked the DNS
> > setup (and showed it to me), looks fine. A test accessing the
> > repo via IP address gives the same delay.
> > >
> > >
> > > regards
> > >
> > > Matthew J Fletcher | Serck Controls | United Kingdom
> > | Lead Software Engineer
> > > Phone: +44 2476 305050 | Direct Dial: +44 2476 515089
> > > Email: mfletcher@serck-controls.co.uk | Site:
> > www.serck-controls.co.uk | Address: Rowley Drive,
> > Coventry, CV3 4FH, United Kingdom
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Matthew Fletcher
> > > > Sent: 21 April 2011 09:55
> > > > To: 'Daniel Shahaf'; users@subversion.apache.org
> > > > Subject: RE: Slow initial repo access (https method)
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Nothing as fancy as LDAP, just a basic file.
> > > >
> > > > AuthType Basic
> > > > AuthBasicProvider file
> > > >
> > > >
> > > > I wonder if it could be due to DNS name lookup issues,
> > > >
> > > > http://old.nabble.com/Using-SSL-between-Apache-proxy-and-Synap
> > > >
> > se-causes-consistent-10-second-delay-in-SSL-handshake-td16014406.htm
> > > > l
> > > >
> > > > "Check if reverse DNS lookups are the same for both
> > production and
> > > > stating/integration. The 10 second delays are usually caused by
> > > > reverse lookups when accepting connections, since we try
> > to get the
> > > > hostname for logging."
> > > >
> > > > I will look into that.
> > > >
> > > >
> > > > regards
> > > >
> > > > Matthew
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > > > Sent: 21 April 2011 09:49
> > > > > To: Matthew Fletcher; users@subversion.apache.org
> > > > > Subject: RE: Slow initial repo access (https method)
> > > > >
> > > > > The problem may be not openssl but rather your
> > > > authentication backend
> > > > > (as configured in httpd.conf). For example, if you use LDAP
> > > > > authentication and your LDAP server is slow to respond,
> > that could
> > > > > account for some seconds' difference.
> > > > >
> > > > > On Thu, 21 Apr 2011 09:44 +0100, "Matthew Fletcher"
> > > > > <MF...@serck-controls.co.uk> wrote:
> > > > > >
> > > > > > Thanks for the info, enabling apache logging i can see
> > > > > where the pause is comming from,. its between the inital client
> > > > > connection and granting the access rights to my user.
> > > > > A full 15 seconds ! This is a fast quad core xeon
> > server as well.
> > > > > >
> > > > > > [Thu Apr 21 09:32:30 2011] [info] Connection: Client IP:
> > > > > > 10.141.81.134, Protocol: TLSv1, Cipher:
> > > > DHE-RSA-AES256-SHA (256/256
> > > > > > bits) [Thu Apr 21 09:32:45 2011] [info] [client
> > > > > 10.141.81.134] Access
> > > > > > granted: 'MFletcher' OPTIONS Play:/
> > > > > >
> > > > > > How do i go about finding out why its taking so long to do
> > > > > the inital https / SSL stuff before granting access ? I
> > > > realise this
> > > > > crosses the boundary between SVN/apache/OpenSSL so it might
> > > > be tricky.
> > > > > >
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Matthew
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > > > > > Sent: 20 April 2011 18:21
> > > > > > > To: Matthew Fletcher; users@subversion.apache.org
> > > > > > > Subject: Re: Slow initial repo access (https method)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> > > > > > > <MF...@serck-controls.co.uk> wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > We are using svn 1.6.16 on the server and have
> > noticed that
> > > > > > > there is a large pause in the inital https
> > requests, (snip of
> > > > > > > wireshark shown bellow). Basically it looks like this
> > > > is a server
> > > > > > > side issue but i am not sure where to look for logs
> > (apache ?).
> > > > > > >
> > > > > > > I'd firstly try to understand what the two packets are
> > > > on either
> > > > > > > side of the large pause. So...
> > > > > > >
> > > > > > > * A dev who knows the protocol might be able to tell what
> > > > > > > those packets are without even looking at your data;
> > > > > > > * You might be able to decrypt the packets you posted;
> > > > > > > * You might be able to reproduce the problem with non-ssl
> > > > > > > connections;
> > > > > > > * You might be able to log the packets before they get
> > > > > encrypted (or
> > > > > > > after decrypted).
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > ********************************************************************
> > > > **
> > > > > > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A
> > > > > > company registered in England Reg. No. 4353634
> > > > > > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > > > > > Web: www.serck-controls.com Admin:
> > post@serck-controls.co.uk A
> > > > > > subsidiary of Schneider Electric.
> > > > > >
> > > > >
> > > >
> > ********************************************************************
> > > > **
> > > > > > This email and files transmitted with it are confidential
> > > > > and intended
> > > > > > solely for the use of the individual or entity to
> > whom they are
> > > > > > addressed. If you have received this email in error please
> > > > > notify the
> > > > > > above. Any views or opinions presented are those of the
> > > > > author and do
> > > > > > not necessarily represent those of Serck Controls Ltd.
> > > > > >
> > > > > > This message has been scanned for malware by Mailcontrol.
> > > > > > www.Mailcontrol.com
> > > > > >
> > > > >
> >
RE: Slow initial repo access (https method)
Posted by Matthew Fletcher <MF...@serck-controls.co.uk>.
Hi,
Poor description on my part sorry, in my httpd.conf i explicitly turned of hostname lookups. That made no noticeable difference.
I think its mod_ssl/openssl (am using 0.9.8r) just being slow, unfortunately even with apache logs set to "debug" verbosity there is no output on this, so will try and turn on logging within mod_ssl.
regards
Matthew J Fletcher
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: 21 April 2011 10:25
> To: Matthew Fletcher
> Cc: users@subversion.apache.org
> Subject: Re: Slow initial repo access (https method)
>
> What do you mean by "accessing the repo via IP address"?
> Without having read your link, I expect it does a reverse DNS
> lookup on the client's address (i.e., the IP address of the
> box where the working copy resides), and just accessing the
> repository as http://192.87.106.227 instead of
> http://svn.apache.org won't affect that.
>
> The test would be
> % ssh svn.apache.org time dig -x '$(echo $SSH_CONNECTION |
> cut -d " " -f 1)'
>
> (this assumes you have a sh-like, not csh-like, login shell)
>
> Matthew Fletcher wrote on Thu, Apr 21, 2011 at 10:16:29 +0100:
> > Hi,
> >
> > Our IT guys have been quite helpful and checked the DNS
> setup (and showed it to me), looks fine. A test accessing the
> repo via IP address gives the same delay.
> >
> >
> > regards
> >
> > Matthew J Fletcher | Serck Controls | United Kingdom
> | Lead Software Engineer
> > Phone: +44 2476 305050 | Direct Dial: +44 2476 515089
> > Email: mfletcher@serck-controls.co.uk | Site:
> www.serck-controls.co.uk | Address: Rowley Drive,
> Coventry, CV3 4FH, United Kingdom
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Matthew Fletcher
> > > Sent: 21 April 2011 09:55
> > > To: 'Daniel Shahaf'; users@subversion.apache.org
> > > Subject: RE: Slow initial repo access (https method)
> > >
> > >
> > > Hi,
> > >
> > > Nothing as fancy as LDAP, just a basic file.
> > >
> > > AuthType Basic
> > > AuthBasicProvider file
> > >
> > >
> > > I wonder if it could be due to DNS name lookup issues,
> > >
> > > http://old.nabble.com/Using-SSL-between-Apache-proxy-and-Synap
> > >
> se-causes-consistent-10-second-delay-in-SSL-handshake-td16014406.htm
> > > l
> > >
> > > "Check if reverse DNS lookups are the same for both
> production and
> > > stating/integration. The 10 second delays are usually caused by
> > > reverse lookups when accepting connections, since we try
> to get the
> > > hostname for logging."
> > >
> > > I will look into that.
> > >
> > >
> > > regards
> > >
> > > Matthew
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > > Sent: 21 April 2011 09:49
> > > > To: Matthew Fletcher; users@subversion.apache.org
> > > > Subject: RE: Slow initial repo access (https method)
> > > >
> > > > The problem may be not openssl but rather your
> > > authentication backend
> > > > (as configured in httpd.conf). For example, if you use LDAP
> > > > authentication and your LDAP server is slow to respond,
> that could
> > > > account for some seconds' difference.
> > > >
> > > > On Thu, 21 Apr 2011 09:44 +0100, "Matthew Fletcher"
> > > > <MF...@serck-controls.co.uk> wrote:
> > > > >
> > > > > Thanks for the info, enabling apache logging i can see
> > > > where the pause is comming from,. its between the inital client
> > > > connection and granting the access rights to my user.
> > > > A full 15 seconds ! This is a fast quad core xeon
> server as well.
> > > > >
> > > > > [Thu Apr 21 09:32:30 2011] [info] Connection: Client IP:
> > > > > 10.141.81.134, Protocol: TLSv1, Cipher:
> > > DHE-RSA-AES256-SHA (256/256
> > > > > bits) [Thu Apr 21 09:32:45 2011] [info] [client
> > > > 10.141.81.134] Access
> > > > > granted: 'MFletcher' OPTIONS Play:/
> > > > >
> > > > > How do i go about finding out why its taking so long to do
> > > > the inital https / SSL stuff before granting access ? I
> > > realise this
> > > > crosses the boundary between SVN/apache/OpenSSL so it might
> > > be tricky.
> > > > >
> > > > >
> > > > > regards,
> > > > >
> > > > > Matthew
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > > > > Sent: 20 April 2011 18:21
> > > > > > To: Matthew Fletcher; users@subversion.apache.org
> > > > > > Subject: Re: Slow initial repo access (https method)
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> > > > > > <MF...@serck-controls.co.uk> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > We are using svn 1.6.16 on the server and have
> noticed that
> > > > > > there is a large pause in the inital https
> requests, (snip of
> > > > > > wireshark shown bellow). Basically it looks like this
> > > is a server
> > > > > > side issue but i am not sure where to look for logs
> (apache ?).
> > > > > >
> > > > > > I'd firstly try to understand what the two packets are
> > > on either
> > > > > > side of the large pause. So...
> > > > > >
> > > > > > * A dev who knows the protocol might be able to tell what
> > > > > > those packets are without even looking at your data;
> > > > > > * You might be able to decrypt the packets you posted;
> > > > > > * You might be able to reproduce the problem with non-ssl
> > > > > > connections;
> > > > > > * You might be able to log the packets before they get
> > > > encrypted (or
> > > > > > after decrypted).
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> ********************************************************************
> > > **
> > > > > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A
> > > > > company registered in England Reg. No. 4353634
> > > > > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > > > > Web: www.serck-controls.com Admin:
> post@serck-controls.co.uk A
> > > > > subsidiary of Schneider Electric.
> > > > >
> > > >
> > >
> ********************************************************************
> > > **
> > > > > This email and files transmitted with it are confidential
> > > > and intended
> > > > > solely for the use of the individual or entity to
> whom they are
> > > > > addressed. If you have received this email in error please
> > > > notify the
> > > > > above. Any views or opinions presented are those of the
> > > > author and do
> > > > > not necessarily represent those of Serck Controls Ltd.
> > > > >
> > > > > This message has been scanned for malware by Mailcontrol.
> > > > > www.Mailcontrol.com
> > > > >
> > > >
>
Re: Slow initial repo access (https method)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
What do you mean by "accessing the repo via IP address"? Without having
read your link, I expect it does a reverse DNS lookup on the client's
address (i.e., the IP address of the box where the working copy
resides), and just accessing the repository as http://192.87.106.227
instead of http://svn.apache.org won't affect that.
The test would be
% ssh svn.apache.org time dig -x '$(echo $SSH_CONNECTION | cut -d " " -f 1)'
(this assumes you have a sh-like, not csh-like, login shell)
Matthew Fletcher wrote on Thu, Apr 21, 2011 at 10:16:29 +0100:
> Hi,
>
> Our IT guys have been quite helpful and checked the DNS setup (and showed it to me), looks fine. A test accessing the repo via IP address gives the same delay.
>
>
> regards
>
> Matthew J Fletcher | Serck Controls | United Kingdom | Lead Software Engineer
> Phone: +44 2476 305050 | Direct Dial: +44 2476 515089
> Email: mfletcher@serck-controls.co.uk | Site: www.serck-controls.co.uk | Address: Rowley Drive, Coventry, CV3 4FH, United Kingdom
>
>
>
>
>
> > -----Original Message-----
> > From: Matthew Fletcher
> > Sent: 21 April 2011 09:55
> > To: 'Daniel Shahaf'; users@subversion.apache.org
> > Subject: RE: Slow initial repo access (https method)
> >
> >
> > Hi,
> >
> > Nothing as fancy as LDAP, just a basic file.
> >
> > AuthType Basic
> > AuthBasicProvider file
> >
> >
> > I wonder if it could be due to DNS name lookup issues,
> >
> > http://old.nabble.com/Using-SSL-between-Apache-proxy-and-Synap
> > se-causes-consistent-10-second-delay-in-SSL-handshake-td16014406.html
> >
> > "Check if reverse DNS lookups are the same for both
> > production and stating/integration. The 10 second delays are
> > usually caused by reverse lookups when accepting connections,
> > since we try to get the hostname for logging."
> >
> > I will look into that.
> >
> >
> > regards
> >
> > Matthew
> >
> >
> >
> > > -----Original Message-----
> > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > Sent: 21 April 2011 09:49
> > > To: Matthew Fletcher; users@subversion.apache.org
> > > Subject: RE: Slow initial repo access (https method)
> > >
> > > The problem may be not openssl but rather your
> > authentication backend
> > > (as configured in httpd.conf). For example, if you use LDAP
> > > authentication and your LDAP server is slow to respond, that could
> > > account for some seconds' difference.
> > >
> > > On Thu, 21 Apr 2011 09:44 +0100, "Matthew Fletcher"
> > > <MF...@serck-controls.co.uk> wrote:
> > > >
> > > > Thanks for the info, enabling apache logging i can see
> > > where the pause is comming from,. its between the inital client
> > > connection and granting the access rights to my user.
> > > A full 15 seconds ! This is a fast quad core xeon server as well.
> > > >
> > > > [Thu Apr 21 09:32:30 2011] [info] Connection: Client IP:
> > > > 10.141.81.134, Protocol: TLSv1, Cipher:
> > DHE-RSA-AES256-SHA (256/256
> > > > bits) [Thu Apr 21 09:32:45 2011] [info] [client
> > > 10.141.81.134] Access
> > > > granted: 'MFletcher' OPTIONS Play:/
> > > >
> > > > How do i go about finding out why its taking so long to do
> > > the inital https / SSL stuff before granting access ? I
> > realise this
> > > crosses the boundary between SVN/apache/OpenSSL so it might
> > be tricky.
> > > >
> > > >
> > > > regards,
> > > >
> > > > Matthew
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > > > Sent: 20 April 2011 18:21
> > > > > To: Matthew Fletcher; users@subversion.apache.org
> > > > > Subject: Re: Slow initial repo access (https method)
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> > > > > <MF...@serck-controls.co.uk> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > We are using svn 1.6.16 on the server and have noticed that
> > > > > there is a large pause in the inital https requests, (snip of
> > > > > wireshark shown bellow). Basically it looks like this
> > is a server
> > > > > side issue but i am not sure where to look for logs (apache ?).
> > > > >
> > > > > I'd firstly try to understand what the two packets are
> > on either
> > > > > side of the large pause. So...
> > > > >
> > > > > * A dev who knows the protocol might be able to tell what those
> > > > > packets are without even looking at your data;
> > > > > * You might be able to decrypt the packets you posted;
> > > > > * You might be able to reproduce the problem with non-ssl
> > > > > connections;
> > > > > * You might be able to log the packets before they get
> > > encrypted (or
> > > > > after decrypted).
> > > > >
> > > >
> > > >
> > >
> > **********************************************************************
> > > > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company
> > > > registered in England Reg. No. 4353634
> > > > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > > > Web: www.serck-controls.com Admin: post@serck-controls.co.uk A
> > > > subsidiary of Schneider Electric.
> > > >
> > >
> > **********************************************************************
> > > > This email and files transmitted with it are confidential
> > > and intended
> > > > solely for the use of the individual or entity to whom they are
> > > > addressed. If you have received this email in error please
> > > notify the
> > > > above. Any views or opinions presented are those of the
> > > author and do
> > > > not necessarily represent those of Serck Controls Ltd.
> > > >
> > > > This message has been scanned for malware by Mailcontrol.
> > > > www.Mailcontrol.com
> > > >
> > >
RE: Slow initial repo access (https method)
Posted by Matthew Fletcher <MF...@serck-controls.co.uk>.
Hi,
Our IT guys have been quite helpful and checked the DNS setup (and showed it to me), looks fine. A test accessing the repo via IP address gives the same delay.
regards
Matthew J Fletcher | Serck Controls | United Kingdom | Lead Software Engineer
Phone: +44 2476 305050 | Direct Dial: +44 2476 515089
Email: mfletcher@serck-controls.co.uk | Site: www.serck-controls.co.uk | Address: Rowley Drive, Coventry, CV3 4FH, United Kingdom
> -----Original Message-----
> From: Matthew Fletcher
> Sent: 21 April 2011 09:55
> To: 'Daniel Shahaf'; users@subversion.apache.org
> Subject: RE: Slow initial repo access (https method)
>
>
> Hi,
>
> Nothing as fancy as LDAP, just a basic file.
>
> AuthType Basic
> AuthBasicProvider file
>
>
> I wonder if it could be due to DNS name lookup issues,
>
> http://old.nabble.com/Using-SSL-between-Apache-proxy-and-Synap
> se-causes-consistent-10-second-delay-in-SSL-handshake-td16014406.html
>
> "Check if reverse DNS lookups are the same for both
> production and stating/integration. The 10 second delays are
> usually caused by reverse lookups when accepting connections,
> since we try to get the hostname for logging."
>
> I will look into that.
>
>
> regards
>
> Matthew
>
>
>
> > -----Original Message-----
> > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > Sent: 21 April 2011 09:49
> > To: Matthew Fletcher; users@subversion.apache.org
> > Subject: RE: Slow initial repo access (https method)
> >
> > The problem may be not openssl but rather your
> authentication backend
> > (as configured in httpd.conf). For example, if you use LDAP
> > authentication and your LDAP server is slow to respond, that could
> > account for some seconds' difference.
> >
> > On Thu, 21 Apr 2011 09:44 +0100, "Matthew Fletcher"
> > <MF...@serck-controls.co.uk> wrote:
> > >
> > > Thanks for the info, enabling apache logging i can see
> > where the pause is comming from,. its between the inital client
> > connection and granting the access rights to my user.
> > A full 15 seconds ! This is a fast quad core xeon server as well.
> > >
> > > [Thu Apr 21 09:32:30 2011] [info] Connection: Client IP:
> > > 10.141.81.134, Protocol: TLSv1, Cipher:
> DHE-RSA-AES256-SHA (256/256
> > > bits) [Thu Apr 21 09:32:45 2011] [info] [client
> > 10.141.81.134] Access
> > > granted: 'MFletcher' OPTIONS Play:/
> > >
> > > How do i go about finding out why its taking so long to do
> > the inital https / SSL stuff before granting access ? I
> realise this
> > crosses the boundary between SVN/apache/OpenSSL so it might
> be tricky.
> > >
> > >
> > > regards,
> > >
> > > Matthew
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > > Sent: 20 April 2011 18:21
> > > > To: Matthew Fletcher; users@subversion.apache.org
> > > > Subject: Re: Slow initial repo access (https method)
> > > >
> > > >
> > > >
> > > > On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> > > > <MF...@serck-controls.co.uk> wrote:
> > > > > Hi,
> > > > >
> > > > > We are using svn 1.6.16 on the server and have noticed that
> > > > there is a large pause in the inital https requests, (snip of
> > > > wireshark shown bellow). Basically it looks like this
> is a server
> > > > side issue but i am not sure where to look for logs (apache ?).
> > > >
> > > > I'd firstly try to understand what the two packets are
> on either
> > > > side of the large pause. So...
> > > >
> > > > * A dev who knows the protocol might be able to tell what those
> > > > packets are without even looking at your data;
> > > > * You might be able to decrypt the packets you posted;
> > > > * You might be able to reproduce the problem with non-ssl
> > > > connections;
> > > > * You might be able to log the packets before they get
> > encrypted (or
> > > > after decrypted).
> > > >
> > >
> > >
> >
> **********************************************************************
> > > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company
> > > registered in England Reg. No. 4353634
> > > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > > Web: www.serck-controls.com Admin: post@serck-controls.co.uk A
> > > subsidiary of Schneider Electric.
> > >
> >
> **********************************************************************
> > > This email and files transmitted with it are confidential
> > and intended
> > > solely for the use of the individual or entity to whom they are
> > > addressed. If you have received this email in error please
> > notify the
> > > above. Any views or opinions presented are those of the
> > author and do
> > > not necessarily represent those of Serck Controls Ltd.
> > >
> > > This message has been scanned for malware by Mailcontrol.
> > > www.Mailcontrol.com
> > >
> >
RE: Slow initial repo access (https method)
Posted by Matthew Fletcher <MF...@serck-controls.co.uk>.
Hi,
Nothing as fancy as LDAP, just a basic file.
AuthType Basic
AuthBasicProvider file
I wonder if it could be due to DNS name lookup issues,
http://old.nabble.com/Using-SSL-between-Apache-proxy-and-Synapse-causes-consistent-10-second-delay-in-SSL-handshake-td16014406.html
"Check if reverse DNS lookups are the same for both production and
stating/integration. The 10 second delays are usually caused by reverse
lookups when accepting connections, since we try to get the hostname for logging."
I will look into that.
regards
Matthew
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: 21 April 2011 09:49
> To: Matthew Fletcher; users@subversion.apache.org
> Subject: RE: Slow initial repo access (https method)
>
> The problem may be not openssl but rather your authentication
> backend (as configured in httpd.conf). For example, if you
> use LDAP authentication and your LDAP server is slow to
> respond, that could account for some seconds' difference.
>
> On Thu, 21 Apr 2011 09:44 +0100, "Matthew Fletcher"
> <MF...@serck-controls.co.uk> wrote:
> >
> > Thanks for the info, enabling apache logging i can see
> where the pause is comming from,. its between the inital
> client connection and granting the access rights to my user.
> A full 15 seconds ! This is a fast quad core xeon server as well.
> >
> > [Thu Apr 21 09:32:30 2011] [info] Connection: Client IP:
> > 10.141.81.134, Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256
> > bits) [Thu Apr 21 09:32:45 2011] [info] [client
> 10.141.81.134] Access
> > granted: 'MFletcher' OPTIONS Play:/
> >
> > How do i go about finding out why its taking so long to do
> the inital https / SSL stuff before granting access ? I
> realise this crosses the boundary between SVN/apache/OpenSSL
> so it might be tricky.
> >
> >
> > regards,
> >
> > Matthew
> >
> >
> >
> > > -----Original Message-----
> > > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > > Sent: 20 April 2011 18:21
> > > To: Matthew Fletcher; users@subversion.apache.org
> > > Subject: Re: Slow initial repo access (https method)
> > >
> > >
> > >
> > > On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> > > <MF...@serck-controls.co.uk> wrote:
> > > > Hi,
> > > >
> > > > We are using svn 1.6.16 on the server and have noticed that
> > > there is a large pause in the inital https requests, (snip of
> > > wireshark shown bellow). Basically it looks like this is a server
> > > side issue but i am not sure where to look for logs (apache ?).
> > >
> > > I'd firstly try to understand what the two packets are on either
> > > side of the large pause. So...
> > >
> > > * A dev who knows the protocol might be able to tell what those
> > > packets are without even looking at your data;
> > > * You might be able to decrypt the packets you posted;
> > > * You might be able to reproduce the problem with non-ssl
> > > connections;
> > > * You might be able to log the packets before they get
> encrypted (or
> > > after decrypted).
> > >
> >
> >
> **********************************************************************
> > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company
> > registered in England Reg. No. 4353634
> > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > Web: www.serck-controls.com Admin: post@serck-controls.co.uk A
> > subsidiary of Schneider Electric.
> >
> **********************************************************************
> > This email and files transmitted with it are confidential
> and intended
> > solely for the use of the individual or entity to whom they are
> > addressed. If you have received this email in error please
> notify the
> > above. Any views or opinions presented are those of the
> author and do
> > not necessarily represent those of Serck Controls Ltd.
> >
> > This message has been scanned for malware by Mailcontrol.
> > www.Mailcontrol.com
> >
>
RE: Slow initial repo access (https method)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
The problem may be not openssl but rather your authentication backend (as configured in httpd.conf). For example, if you use LDAP authentication and your LDAP server is slow to respond, that could account for some seconds' difference.
On Thu, 21 Apr 2011 09:44 +0100, "Matthew Fletcher" <MF...@serck-controls.co.uk> wrote:
>
> Thanks for the info, enabling apache logging i can see where the pause is comming from,. its between the inital client connection and granting the access rights to my user. A full 15 seconds ! This is a fast quad core xeon server as well.
>
> [Thu Apr 21 09:32:30 2011] [info] Connection: Client IP: 10.141.81.134, Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
> [Thu Apr 21 09:32:45 2011] [info] [client 10.141.81.134] Access granted: 'MFletcher' OPTIONS Play:/
>
> How do i go about finding out why its taking so long to do the inital https / SSL stuff before granting access ? I realise this crosses the boundary between SVN/apache/OpenSSL so it might be tricky.
>
>
> regards,
>
> Matthew
>
>
>
> > -----Original Message-----
> > From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > Sent: 20 April 2011 18:21
> > To: Matthew Fletcher; users@subversion.apache.org
> > Subject: Re: Slow initial repo access (https method)
> >
> >
> >
> > On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> > <MF...@serck-controls.co.uk> wrote:
> > > Hi,
> > >
> > > We are using svn 1.6.16 on the server and have noticed that
> > there is a large pause in the inital https requests, (snip of
> > wireshark shown bellow). Basically it looks like this is a
> > server side issue but i am not sure where to look for logs (apache ?).
> >
> > I'd firstly try to understand what the two packets are on
> > either side of the large pause. So...
> >
> > * A dev who knows the protocol might be able to tell what
> > those packets are without even looking at your data;
> > * You might be able to decrypt the packets you posted;
> > * You might be able to reproduce the problem with non-ssl connections;
> > * You might be able to log the packets before they get
> > encrypted (or after decrypted).
> >
>
> **********************************************************************
> Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
> A company registered in England Reg. No. 4353634
> Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> Web: www.serck-controls.com Admin: post@serck-controls.co.uk
> A subsidiary of Schneider Electric.
> **********************************************************************
> This email and files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the above. Any views or opinions presented are those of the author
> and do not necessarily represent those of Serck Controls Ltd.
>
> This message has been scanned for malware by Mailcontrol. www.Mailcontrol.com
>
RE: Slow initial repo access (https method)
Posted by Matthew Fletcher <MF...@serck-controls.co.uk>.
Thanks for the info, enabling apache logging i can see where the pause is comming from,. its between the inital client connection and granting the access rights to my user. A full 15 seconds ! This is a fast quad core xeon server as well.
[Thu Apr 21 09:32:30 2011] [info] Connection: Client IP: 10.141.81.134, Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
[Thu Apr 21 09:32:45 2011] [info] [client 10.141.81.134] Access granted: 'MFletcher' OPTIONS Play:/
How do i go about finding out why its taking so long to do the inital https / SSL stuff before granting access ? I realise this crosses the boundary between SVN/apache/OpenSSL so it might be tricky.
regards,
Matthew
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: 20 April 2011 18:21
> To: Matthew Fletcher; users@subversion.apache.org
> Subject: Re: Slow initial repo access (https method)
>
>
>
> On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher"
> <MF...@serck-controls.co.uk> wrote:
> > Hi,
> >
> > We are using svn 1.6.16 on the server and have noticed that
> there is a large pause in the inital https requests, (snip of
> wireshark shown bellow). Basically it looks like this is a
> server side issue but i am not sure where to look for logs (apache ?).
>
> I'd firstly try to understand what the two packets are on
> either side of the large pause. So...
>
> * A dev who knows the protocol might be able to tell what
> those packets are without even looking at your data;
> * You might be able to decrypt the packets you posted;
> * You might be able to reproduce the problem with non-ssl connections;
> * You might be able to log the packets before they get
> encrypted (or after decrypted).
>
**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
A company registered in England Reg. No. 4353634
Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com Admin: post@serck-controls.co.uk
A subsidiary of Schneider Electric.
**********************************************************************
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.
This message has been scanned for malware by Mailcontrol. www.Mailcontrol.com
Re: Slow initial repo access (https method)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Wed, 20 Apr 2011 14:06 +0100, "Matthew Fletcher" <MF...@serck-controls.co.uk> wrote:
> Hi,
>
> We are using svn 1.6.16 on the server and have noticed that there is a large pause in the inital https requests, (snip of wireshark shown bellow). Basically it looks like this is a server side issue but i am not sure where to look for logs (apache ?).
I'd firstly try to understand what the two packets are on either side of the large pause. So...
* A dev who knows the protocol might be able to tell what those packets are without even looking at your data;
* You might be able to decrypt the packets you posted;
* You might be able to reproduce the problem with non-ssl connections;
* You might be able to log the packets before they get encrypted (or after decrypted).
RE: Slow initial repo access (https method)
Posted by Matthew Fletcher <MF...@serck-controls.co.uk>.
Hi,
Thanks for the ideas, but we just use a self signed certificate. I am not really an expert with certificates, would there be any kind of lookup done to a certificate authority or other internet site with a self signed certificate ?
If so is there any way to disable it ? we are just using svn internaly in an small company and dont have a big IT department.
regards
Matthew J Fletcher
> -----Original Message-----
> From: Brian Brophy [mailto:brianmbrophy@gmail.com]
> Sent: 22 April 2011 16:39
> To: Matthew Fletcher; users@subversion.apache.org
> Subject: Re: Slow initial repo access (https method)
>
> Is your trace below only showing traffic from client to SVN
> server? If so, try grabbing all traffic from the client to
> see what else may be going on. There are a couple features
> of SSL which may explain this.
>
> First, does your certificate signing chain include
> intermediary signers? An example would be something like
> VeriSign Public Primary G3
> -> VeriSign International Root G5 -> Your Certificate. If so, the
> server should have all signers in the chain available to it,
> so that if the client needs them to verify the handshake, the
> server can hand them down. If the client determines it needs
> the intermediaries and the server does not have them, the
> client may go out to the provider (ie,
> VeriSign) and attempt to download the missing certificates in
> order to perform the verification.
>
> Second, some SSL certificates include a configuration for a
> revocation link. This is a location (typically a publicly
> accessible URL) that the client can view on the certificate's
> metadata, and if implemented, call out to the revocation
> location in order to determine if the certificate the client
> is attempting to handshake with (ie, your server cert) has
> since been revoked by the signer. It is a mechanism for the
> signer to "de-certify" a certificate that otherwise would be
> ok (ie, start/end dates are within window, cn matches hostname, etc).
>
> Some thoughts,
> Brian
>
> Matthew Fletcher wrote:
> > Hi,
> >
> > We are using svn 1.6.16 on the server and have noticed that
> there is a large pause in the inital https requests, (snip of
> wireshark shown bellow). Basically it looks like this is a
> server side issue but i am not sure where to look for logs (apache ?).
> >
> > 10.141.80.130 (server)
> > 10.141.81.134 (client)
> >
> > No. Time Source Destination
> Protocol Info
> > 1 0.000000 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [SYN] Seq=0 Win=8192 Len=0
> MSS=1460 SACK_PERM=1
> > No. Time Source Destination
> Protocol Info
> > 2 0.000125 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1
> Win=16384 Len=0 MSS=1460 SACK_PERM=1
> > No. Time Source Destination
> Protocol Info
> > 3 0.000166 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0
> > No. Time Source Destination
> Protocol Info
> > 4 0.000307 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=1 Ack=1
> Win=64240 Len=227
> > No. Time Source Destination
> Protocol Info
> > 5 0.013041 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [ACK] Seq=1 Ack=228
> Win=65308 Len=1460
> > No. Time Source Destination
> Protocol Info
> > 6 0.013068 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228
> Win=65308 Len=13
> > No. Time Source Destination
> Protocol Info
> > 7 0.013084 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [ACK] Seq=228 Ack=1474
> Win=64240 Len=0
> > No. Time Source Destination
> Protocol Info
> > 8 0.029234 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=228 Ack=1474
> Win=64240 Len=198
> > No. Time Source Destination
> Protocol Info
> > 9 0.033499 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426
> Win=65110 Len=266
> > No. Time Source Destination
> Protocol Info
> > 10 0.225080 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [ACK] Seq=426 Ack=1740
> Win=63974 Len=0
> > No. Time Source Destination
> Protocol Info
> > 11 15.123199 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=426 Ack=1740
> Win=63974 Len=485
> > No. Time Source Destination
> Protocol Info
> > 12 15.123238 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=911 Ack=1740
> Win=63974 Len=133
> > No. Time Source Destination
> Protocol Info
> > 13 15.123401 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [ACK] Seq=1740 Ack=1044
> Win=64492 Len=0
> > No. Time Source Destination
> Protocol Info
> > 14 15.124022 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [PSH, ACK] Seq=1740
> Ack=1044 Win=64492 Len=746
> >
> >
> > Note the giant 15 second wait between packets 10-11, and
> then fast afterwards.
> >
> > See the slow packets 10-11 in full bellow;
> >
> >
> > Frame 10: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
> > Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst:
> > Dell_cf:17:71 (00:1e:c9:cf:17:71) Internet Protocol, Src:
> 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
> > Version: 4
> > Header length: 20 bytes
> > Differentiated Services Field: 0x00 (DSCP 0x00:
> Default; ECN: 0x00)
> > Total Length: 40
> > Identification: 0x453c (17724)
> > Flags: 0x02 (Don't Fragment)
> > Fragment offset: 0
> > Time to live: 128
> > Protocol: TCP (6)
> > Header checksum: 0x0000 [incorrect, should be 0xfe71]
> > Source: 10.141.81.134 (10.141.81.134)
> > Destination: 10.141.80.130 (10.141.80.130) Transmission Control
> > Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https
> (8443), Seq: 426, Ack: 1740, Len: 0
> > Source port: 50186 (50186)
> > Destination port: pcsync-https (8443)
> > [Stream index: 0]
> > Sequence number: 426 (relative sequence number)
> > Acknowledgement number: 1740 (relative ack number)
> > Header length: 20 bytes
> > Flags: 0x10 (ACK)
> > Window size: 63974
> > Checksum: 0xb73c [validation disabled]
> > [SEQ/ACK analysis]
> >
> >
> > Frame 11: 539 bytes on wire (4312 bits), 539 bytes captured (4312
> > bits) Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst:
> > Dell_cf:17:71 (00:1e:c9:cf:17:71) Internet Protocol, Src:
> 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
> > Version: 4
> > Header length: 20 bytes
> > Differentiated Services Field: 0x00 (DSCP 0x00:
> Default; ECN: 0x00)
> > Total Length: 525
> > Identification: 0x4546 (17734)
> > Flags: 0x02 (Don't Fragment)
> > Fragment offset: 0
> > Time to live: 128
> > Protocol: TCP (6)
> > Header checksum: 0x0000 [incorrect, should be 0xfc82]
> > Source: 10.141.81.134 (10.141.81.134)
> > Destination: 10.141.80.130 (10.141.80.130) Transmission Control
> > Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https
> (8443), Seq: 426, Ack: 1740, Len: 485
> > Source port: 50186 (50186)
> > Destination port: pcsync-https (8443)
> > [Stream index: 0]
> > Sequence number: 426 (relative sequence number)
> > [Next sequence number: 911 (relative sequence number)]
> > Acknowledgement number: 1740 (relative ack number)
> > Header length: 20 bytes
> > Flags: 0x18 (PSH, ACK)
> > Window size: 63974
> > Checksum: 0xb921 [validation disabled]
> > [SEQ/ACK analysis]
> > Data (485 bytes)
> >
> > 0000 17 03 01 01 e0 5b aa 54 59 c4 53 f1 31 5a c3 00
> .....[.TY.S.1Z..
> > 0010 9f b8 89 74 7e 6a ce 5a a0 34 02 dc 78 6b a3 2d
> ...t~j.Z.4..xk.-
> > 0020 64 2f 60 dc c6 80 00 3f 01 20 50 02 d2 4d 70 f2
> d/`....?. P..Mp.
> > 0030 4f 9d 82 a6 3a cc 8f 18 3f a3 d7 0b ea 1d 33 1b
> O...:...?.....3.
> > 0040 84 b3 15 c2 5d de d5 6b 49 1a 72 a3 10 a2 8e b0
> ....]..kI.r.....
> > 0050 9c 82 9a 65 f0 05 38 3b 7d d2 9b 5c 1b ed b6 85
> ...e..8;}..\....
> > 0060 d5 0d 17 9a 99 5c a4 18 ac 12 d5 7d 26 82 a3 b3
> .....\.....}&...
> > 0070 d9 a2 66 07 52 d3 7f ea 26 69 f1 a5 ee a8 b9 21
> ..f.R...&i.....!
> > 0080 b9 98 d2 a8 e6 05 30 2d a2 53 8b 0b 59 bd 6e ed
> ......0-.S..Y.n.
> > 0090 9a b6 4e 9e 7a 57 ad 16 bc 4e 6b f8 48 e3 d2 b3
> ..N.zW...Nk.H...
> > 00a0 8f 19 2d e6 0a 06 bf 7f 71 e0 74 a2 8e fa 92 59
> ..-.....q.t....Y
> > 00b0 7e 00 24 06 41 c6 f0 bc 74 f3 39 af 3c e3 34 20
> ~.$.A...t.9.<.4
> > 00c0 f4 35 9f 70 40 c6 95 2a 69 61 98 ff 58 52 5e 03
> .5.p@..*ia..XR^.
> > 00d0 50 c1 60 d5 27 53 48 60 c4 1b e7 a6 49 1d 98 f0
> P.`.'SH`....I...
> > 00e0 46 8c 25 b5 1f 7b 93 79 1b 52 02 e5 fd 9e 2c 6d
> F.%..{.y.R....,m
> > 00f0 8e ed 6f 6c f3 8e 72 1e 76 0f 7c c0 f9 61 00 1c
> ..ol..r.v.|..a..
> > 0100 95 21 f8 f5 e1 32 bd 83 47 65 d2 f4 21 7e b0 20
> .!...2..Ge..!~.
> > 0110 d6 45 48 30 a1 6b e8 e3 8e f0 58 ad f7 9e 5b ff
> .EH0.k....X...[.
> > 0120 86 63 fe d1 1b 0c bb af e1 85 e1 d8 13 f0 00 78
> .c.............x
> > 0130 3a f6 de d6 77 40 be e8 e1 ab 4c e3 7c 7c ec 3d
> :...w@....L.||.=
> > 0140 4c 56 e9 42 11 cb 42 13 81 75 66 70 01 63 c5 40
> LV.B..B..ufp.c.@
> > 0150 fa 2e 39 86 64 ac 7a da 38 0e aa 15 62 b1 4f 6f
> ..9.d.z.8...b.Oo
> > 0160 f2 71 b8 12 64 f4 91 f2 1c 57 ae 15 05 20 42 2b
> .q..d....W... B+
> > 0170 a3 6e 24 01 dc 8c fa b0 49 2f 5e 68 68 29 1d de
> .n$.....I/^hh)..
> > 0180 c6 dc 14 44 76 91 6b 4b ed 4f 65 77 43 a1 56 df
> ...Dv.kK.OewC.V.
> > 0190 4a 66 8d 00 e9 96 f7 3a 60 dd 5a 3e e7 4f a5 ae
> Jf.....:`.Z>.O..
> > 01a0 6e 82 49 81 ce 4d a8 1e 2d 0d c6 ae 3e 5b ee 83
> n.I..M..-...>[..
> > 01b0 b0 29 72 91 48 57 54 72 f3 a1 59 46 cf ff dd 0b
> .)r.HWTr..YF....
> > 01c0 95 ef 03 2b fe c0 4c 47 f1 cd e8 46 07 17 7c 1a
> ...+..LG...F..|.
> > 01d0 d8 d0 bc 68 b4 ca 07 ec 73 87 eb 34 93 e5 1f 42
> ...h....s..4...B
> > 01e0 fa ce 60 11 f6 ..`..
> >
> >
> > any ideas why this packet takes so long to be created, or
> what operation preceded it can caused the slowness ?
> >
> >
> > regards,
> >
> > Matthew J Fletcher
> >
> >
> >
> **********************************************************************
> > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company
> > registered in England Reg. No. 4353634
> > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > Web: www.serck-controls.com Admin: post@serck-controls.co.uk A
> > subsidiary of Schneider Electric.
> >
> **********************************************************************
> > This email and files transmitted with it are confidential
> and intended
> > solely for the use of the individual or entity to whom they are
> > addressed. If you have received this email in error please
> notify the
> > above. Any views or opinions presented are those of the
> author and do
> > not necessarily represent those of Serck Controls Ltd.
> >
> > This message has been scanned for malware by Mailcontrol.
> > www.Mailcontrol.com
> >
>
Re: Slow initial repo access (https method)
Posted by Brian Brophy <br...@gmail.com>.
Is your trace below only showing traffic from client to SVN server? If
so, try grabbing all traffic from the client to see what else may be
going on. There are a couple features of SSL which may explain this.
First, does your certificate signing chain include intermediary
signers? An example would be something like VeriSign Public Primary G3
-> VeriSign International Root G5 -> Your Certificate. If so, the
server should have all signers in the chain available to it, so that if
the client needs them to verify the handshake, the server can hand them
down. If the client determines it needs the intermediaries and the
server does not have them, the client may go out to the provider (ie,
VeriSign) and attempt to download the missing certificates in order to
perform the verification.
Second, some SSL certificates include a configuration for a revocation
link. This is a location (typically a publicly accessible URL) that the
client can view on the certificate's metadata, and if implemented, call
out to the revocation location in order to determine if the certificate
the client is attempting to handshake with (ie, your server cert) has
since been revoked by the signer. It is a mechanism for the signer to
"de-certify" a certificate that otherwise would be ok (ie, start/end
dates are within window, cn matches hostname, etc).
Some thoughts,
Brian
Matthew Fletcher wrote:
> Hi,
>
> We are using svn 1.6.16 on the server and have noticed that there is a large pause in the inital https requests, (snip of wireshark shown bellow). Basically it looks like this is a server side issue but i am not sure where to look for logs (apache ?).
>
> 10.141.80.130 (server)
> 10.141.81.134 (client)
>
> No. Time Source Destination Protocol Info
> 1 0.000000 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
> No. Time Source Destination Protocol Info
> 2 0.000125 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
> No. Time Source Destination Protocol Info
> 3 0.000166 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0
> No. Time Source Destination Protocol Info
> 4 0.000307 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=227
> No. Time Source Destination Protocol Info
> 5 0.013041 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [ACK] Seq=1 Ack=228 Win=65308 Len=1460
> No. Time Source Destination Protocol Info
> 6 0.013068 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228 Win=65308 Len=13
> No. Time Source Destination Protocol Info
> 7 0.013084 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [ACK] Seq=228 Ack=1474 Win=64240 Len=0
> No. Time Source Destination Protocol Info
> 8 0.029234 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=228 Ack=1474 Win=64240 Len=198
> No. Time Source Destination Protocol Info
> 9 0.033499 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426 Win=65110 Len=266
> No. Time Source Destination Protocol Info
> 10 0.225080 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [ACK] Seq=426 Ack=1740 Win=63974 Len=0
> No. Time Source Destination Protocol Info
> 11 15.123199 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=426 Ack=1740 Win=63974 Len=485
> No. Time Source Destination Protocol Info
> 12 15.123238 10.141.81.134 10.141.80.130 TCP 50186 > pcsync-https [PSH, ACK] Seq=911 Ack=1740 Win=63974 Len=133
> No. Time Source Destination Protocol Info
> 13 15.123401 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [ACK] Seq=1740 Ack=1044 Win=64492 Len=0
> No. Time Source Destination Protocol Info
> 14 15.124022 10.141.80.130 10.141.81.134 TCP pcsync-https > 50186 [PSH, ACK] Seq=1740 Ack=1044 Win=64492 Len=746
>
>
> Note the giant 15 second wait between packets 10-11, and then fast afterwards.
>
> See the slow packets 10-11 in full bellow;
>
>
> Frame 10: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
> Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst: Dell_cf:17:71 (00:1e:c9:cf:17:71)
> Internet Protocol, Src: 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 40
> Identification: 0x453c (17724)
> Flags: 0x02 (Don't Fragment)
> Fragment offset: 0
> Time to live: 128
> Protocol: TCP (6)
> Header checksum: 0x0000 [incorrect, should be 0xfe71]
> Source: 10.141.81.134 (10.141.81.134)
> Destination: 10.141.80.130 (10.141.80.130)
> Transmission Control Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https (8443), Seq: 426, Ack: 1740, Len: 0
> Source port: 50186 (50186)
> Destination port: pcsync-https (8443)
> [Stream index: 0]
> Sequence number: 426 (relative sequence number)
> Acknowledgement number: 1740 (relative ack number)
> Header length: 20 bytes
> Flags: 0x10 (ACK)
> Window size: 63974
> Checksum: 0xb73c [validation disabled]
> [SEQ/ACK analysis]
>
>
> Frame 11: 539 bytes on wire (4312 bits), 539 bytes captured (4312 bits)
> Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst: Dell_cf:17:71 (00:1e:c9:cf:17:71)
> Internet Protocol, Src: 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 525
> Identification: 0x4546 (17734)
> Flags: 0x02 (Don't Fragment)
> Fragment offset: 0
> Time to live: 128
> Protocol: TCP (6)
> Header checksum: 0x0000 [incorrect, should be 0xfc82]
> Source: 10.141.81.134 (10.141.81.134)
> Destination: 10.141.80.130 (10.141.80.130)
> Transmission Control Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https (8443), Seq: 426, Ack: 1740, Len: 485
> Source port: 50186 (50186)
> Destination port: pcsync-https (8443)
> [Stream index: 0]
> Sequence number: 426 (relative sequence number)
> [Next sequence number: 911 (relative sequence number)]
> Acknowledgement number: 1740 (relative ack number)
> Header length: 20 bytes
> Flags: 0x18 (PSH, ACK)
> Window size: 63974
> Checksum: 0xb921 [validation disabled]
> [SEQ/ACK analysis]
> Data (485 bytes)
>
> 0000 17 03 01 01 e0 5b aa 54 59 c4 53 f1 31 5a c3 00 .....[.TY.S.1Z..
> 0010 9f b8 89 74 7e 6a ce 5a a0 34 02 dc 78 6b a3 2d ...t~j.Z.4..xk.-
> 0020 64 2f 60 dc c6 80 00 3f 01 20 50 02 d2 4d 70 f2 d/`....?. P..Mp.
> 0030 4f 9d 82 a6 3a cc 8f 18 3f a3 d7 0b ea 1d 33 1b O...:...?.....3.
> 0040 84 b3 15 c2 5d de d5 6b 49 1a 72 a3 10 a2 8e b0 ....]..kI.r.....
> 0050 9c 82 9a 65 f0 05 38 3b 7d d2 9b 5c 1b ed b6 85 ...e..8;}..\....
> 0060 d5 0d 17 9a 99 5c a4 18 ac 12 d5 7d 26 82 a3 b3 .....\.....}&...
> 0070 d9 a2 66 07 52 d3 7f ea 26 69 f1 a5 ee a8 b9 21 ..f.R...&i.....!
> 0080 b9 98 d2 a8 e6 05 30 2d a2 53 8b 0b 59 bd 6e ed ......0-.S..Y.n.
> 0090 9a b6 4e 9e 7a 57 ad 16 bc 4e 6b f8 48 e3 d2 b3 ..N.zW...Nk.H...
> 00a0 8f 19 2d e6 0a 06 bf 7f 71 e0 74 a2 8e fa 92 59 ..-.....q.t....Y
> 00b0 7e 00 24 06 41 c6 f0 bc 74 f3 39 af 3c e3 34 20 ~.$.A...t.9.<.4
> 00c0 f4 35 9f 70 40 c6 95 2a 69 61 98 ff 58 52 5e 03 .5.p@..*ia..XR^.
> 00d0 50 c1 60 d5 27 53 48 60 c4 1b e7 a6 49 1d 98 f0 P.`.'SH`....I...
> 00e0 46 8c 25 b5 1f 7b 93 79 1b 52 02 e5 fd 9e 2c 6d F.%..{.y.R....,m
> 00f0 8e ed 6f 6c f3 8e 72 1e 76 0f 7c c0 f9 61 00 1c ..ol..r.v.|..a..
> 0100 95 21 f8 f5 e1 32 bd 83 47 65 d2 f4 21 7e b0 20 .!...2..Ge..!~.
> 0110 d6 45 48 30 a1 6b e8 e3 8e f0 58 ad f7 9e 5b ff .EH0.k....X...[.
> 0120 86 63 fe d1 1b 0c bb af e1 85 e1 d8 13 f0 00 78 .c.............x
> 0130 3a f6 de d6 77 40 be e8 e1 ab 4c e3 7c 7c ec 3d :...w@....L.||.=
> 0140 4c 56 e9 42 11 cb 42 13 81 75 66 70 01 63 c5 40 LV.B..B..ufp.c.@
> 0150 fa 2e 39 86 64 ac 7a da 38 0e aa 15 62 b1 4f 6f ..9.d.z.8...b.Oo
> 0160 f2 71 b8 12 64 f4 91 f2 1c 57 ae 15 05 20 42 2b .q..d....W... B+
> 0170 a3 6e 24 01 dc 8c fa b0 49 2f 5e 68 68 29 1d de .n$.....I/^hh)..
> 0180 c6 dc 14 44 76 91 6b 4b ed 4f 65 77 43 a1 56 df ...Dv.kK.OewC.V.
> 0190 4a 66 8d 00 e9 96 f7 3a 60 dd 5a 3e e7 4f a5 ae Jf.....:`.Z>.O..
> 01a0 6e 82 49 81 ce 4d a8 1e 2d 0d c6 ae 3e 5b ee 83 n.I..M..-...>[..
> 01b0 b0 29 72 91 48 57 54 72 f3 a1 59 46 cf ff dd 0b .)r.HWTr..YF....
> 01c0 95 ef 03 2b fe c0 4c 47 f1 cd e8 46 07 17 7c 1a ...+..LG...F..|.
> 01d0 d8 d0 bc 68 b4 ca 07 ec 73 87 eb 34 93 e5 1f 42 ...h....s..4...B
> 01e0 fa ce 60 11 f6 ..`..
>
>
> any ideas why this packet takes so long to be created, or what operation preceded it can caused the slowness ?
>
>
> regards,
>
> Matthew J Fletcher
>
>
> **********************************************************************
> Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
> A company registered in England Reg. No. 4353634
> Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> Web: www.serck-controls.com Admin: post@serck-controls.co.uk
> A subsidiary of Schneider Electric.
> **********************************************************************
> This email and files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the above. Any views or opinions presented are those of the author
> and do not necessarily represent those of Serck Controls Ltd.
>
> This message has been scanned for malware by Mailcontrol. www.Mailcontrol.com
>