2008-05-13 09:12 AEST by Arthur Barrett - Commit a large (500Mb) file and 'transfer' to server is slow (SSPI).  In 15 
minutes only 151 MB is transferred.

Server: cvsntserver XPPro SP2 (vmware on vmdev with 1.5GB RAM and 2GB page)
Client: bbcclient W2003 SP2 (vmware on macair with 1.2GB RAM and 2GB page)

I can 'see' the  file being uploaded onto the c:\windows\temp directory of the 
cvsntserver - however the client is showing almost no CPU and no change of 
memory usage (already allocated) and same on the server (no cpu, no memory).  
It apppears as though this is the point in the commit where the client copies 
the file to the server - it just runs really really slowly.

The client and server are connected by gigabit ethernet and copying the 500Mb 
file using windows file sharing takes a fraction of the time.

client "windows firewall" enabled - no antivirus.
server "windows firewall" disabled - no antivirus.


This poor performance could be happening for numerous reasons (eg: vmware 
software network drivers) - however it could use some time investigating.  I'd 
propose doing the following tests:
* same test (using sspi) but entirely on cvsntserver (require more RAM?)
* same test (using sspi) but using physical server(s) perhaps cluster 1 as 
server and cluster 2 as client?

2008-05-13 13:59 AEST by Arthur Barrett - Created an attachment (id=1276)
added debugging, moved variable alloc out of loop

added debugging (level 99 - so only works with ServerTraceFile), moved variable
alloc out of loop.  Committed 2.5.03:
Checking in src/server.cpp;
/cvs/cvsnt/src/server.c,v  <--	server.cpp
new revision: 1.106.2.210.6.14; previous revision: 1.106.2.210.6.13
done

2008-05-14 11:06 AEST by Arthur Barrett - The cause is the reverse dns.  I've no idea why (or where) the server is 
performing this lookup on EACH packet, but it is.  I thought this would only 
affect each CONNECTION - but it affects each PACKET.

See bug 5274.

2008-05-14 13:39 AEST by Arthur Barrett - Some more inforomation gathered using the same test set:
* doing a checkout takes 10 min (as opposed to commit takes 1 hour)
* tracing the server shows no activity during 'idle' period
* copying same file using smb to server takes 10min (same client to same server)

So:
* Ive added some extra tracing to show what the server is doing
* if the upload is slow the server should now warn the client

2008-05-14 17:21 AEST by Arthur Barrett - No the cause is not reverse dns.

So back to the drawing board as the what the real cause is.

It does appear to slow down as the read progresses:
* 0:15 - has read 1/4 the file
* 0:45 - has read 1/2 the file
* 1:45 - has read 2/3 the file
* client memory remains at 2*filesize
* server process memory alloc remains insignificant

2008-05-20 10:47 AEST by Arthur Barrett - Add more debugging to find what buffer->output is used.
Checking in src/buffer.cpp;
/cvs/cvsnt/src/buffer.c,v  <--  buffer.cpp
new revision: 1.16.2.6.8.4; previous revision: 1.16.2.6.8.3
done
Checking in src/buffer.h;
/cvs/cvsnt/src/buffer.h,v  <--  buffer.h
new revision: 1.8.2.4.10.3; previous revision: 1.8.2.4.10.2
done
Checking in src/client.cpp;
/cvs/cvsnt/src/client.c,v  <--  client.cpp
new revision: 1.84.2.141.6.22; previous revision: 1.84.2.141.6.21
done
Checking in src/server.cpp;
/cvs/cvsnt/src/server.c,v  <--  server.cpp
new revision: 1.106.2.210.6.33; previous revision: 1.106.2.210.6.32
done
Checking in src/zlib.cpp;
/cvs/cvsnt/src/zlib.c,v  <--  zlib.cpp
new revision: 1.16.2.18.8.1; previous revision: 1.16.2.18
done

2008-06-03 09:53 AEST by Arthur Barrett - Not dependant on bug5275.