I ran into a similar problem with the XP firewall, with CVS-pserver
hosted on Redhat, and *any* CVS client on host. It was taking exactly
30 seconds to do *anything*. Turning off the XP firewall fixed the
problem;
it was also possible to fix it by leaving the XP firewall on, but
disabling access logging in the /etc/xinetd.d/cvspserver config.
It was suggested at info-cvs (to someone else with same problem
a year ago) that this was caused by RDNS not working, but for various
reasons I'm pretty sure that's
not the case here. I did found out one interesting thing: If I 'finger'
the XP box from the RH server, with firewall off, it fails immediately.
If I try it with the XP firewall on, it hangs indefinitely. So I wonder
if something on the server, either xinetd or cvsd, is doing a finger
or something similar, with a 30-second timeout, but only if logging
is enabled. Since the operation fails whether or not the firewall is
enabled, only the time is affected by the firewall setting, not the
outcome.
Since the '30 seconds' is a function of the server operation,
is it possible that a different daemon could be doing something like
this with a shorter timeout? I've been using http: svn, maybe I've
got a 2-second lag too, I haven't been that picky after suffering
through the 30-second problem.
-----Original Message-----
From: Alan Thompson [mailto:ALAN.W.THOMPSON@saic.com]
Sent: Thursday, February 10, 2005 2:42 PM
To: lubela@tteam.com
Subject: RE: Subversion + Apache + SSL + Windows = low performance
I use Apache+SSL/SVN on RedHat 9. Speed with http or https is equal as
far as I can tell.
One test you might try: Access your SVN repo via the IP address instead
of the hostname:
svn checkout https://1.22.33.44/svn/myproj
It might give you a clue if DNS or similar is the problem. If no
change, perhaps Windoze is doing something stupid.
Alan Thompson
On Thu, 2005-02-10 at 07:11, Andy Lubel wrote:
> Weve got about 4 repositories (about 400MB per repository) running on
gentoo
> 2004.3 and windowsXP with apache2+SSL with no problems.. We are
> experimenting with the fsfs stuff but use the BDB system as our
standard.
>
> What I think it is; go to appwiz.cpl-->add remove windows
components-->
> then scroll down to where networking options are and see if QOS or any
other
> stupid windows 'feature' is enabled. When I was reading through
apache
> docs, I remember something about removing that. Give it a try!
Besides its
> pretty useless anyway. Also if youre running XP maybe check that the
> Firewall is off, and or logging of packets is off.
>
> I hope that helps, basically imho its not dav_svn, apache, or ssl,
it's the
> windows 'features' that are causing the problems. Of course I assume
that
> your httpd.conf is not doing reverse lookups and nothing is set to
DEBUG
> mode.
>
>
>
> Andy Lubel
>
>
> -----Original Message-----
> From: Slava Skorykh [mailto:vskorykh@fortess.net]
> Sent: Thursday, February 10, 2005 5:05 AM
> To: 'Martin Tomes'
> Cc: users@subversion.tigris.org
> Subject: RE: Subversion + Apache + SSL + Windows = low performance
>
> >Slava Skorykh wrote:
> >> Hi All,
> >>
> >> I have monitored network with Ethereal Network Analyzed and it
shows
> >> that
>
> >> there are 1-2 seconds delays in Apache2 responses.
>
> > Network delays like this are often caused by DNS lookups or similar
> > 'where am I what am I, who is that' network queries. Are all Apache
> > requests delayed or just Subversion ones? Are you doing hostname
> > lookups for your Apache log file or logging the IP address of the
request?
>
> I am not sure that DNS lookups cause delays:
> 1. In Apache log files there are no host names, only IP addresses 2.
Delays
> are observed only for HTTPS protocol and there are no delays for HTTP
(svn
> checkout of an empty project for HTTPS ~30 seconds and for HTTP ~2
> seconds)
>
> HTTPS handshake is also unlikely to cause the delays:
> 1. Ethereal Network Analyzed shows that port opened by Subversion
client is
> always the same for all the requests 2. I have configured
SSLSessionCache
> and tested that it works with openssl.exe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------------------
This e-mail and any attachments may contain confidential information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any use, review, dissemination, forwarding, printing or copying of this email or any information or attachments contained herein by a person other than the intended recipient is unauthorized and may be illegal. Silicon Optix reserves the right to monitor all e-mail communications through its networks for quality control purposes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 19:16:36 2005