Rep ID: 1 Base: 35681 Target: -1
7:05:29 AM GetRepositoryStructure returned: Success
7:05:32 AM Getting list of checkout changes.
7:05:32 AM GetCheckOutListChanges returned: Success
7:05:39 AM Beginning file download
7:05:39 AM BeginDownloadFiles returned: Success
7:06:35 AM VaultFileDownload starting
7:06:36 AM GetLatest wrote 10756818 bytes to the Response Stream
7:25:19 AM GetLatest wrote 11148219 bytes to the Response Stream
7:54:12 AM GetLatest wrote 10038355 bytes to the Response Stream
8:32:09 AM Ending download process
8:32:09 AM EndDownloadProcess returned: Success
local user:
8:29:48 AM Getting repository Structure-> Rep ID: 1 Base: 35719 Target: -1
8:29:48 AM GetRepositoryStructure returned: Success
8:29:48 AM Getting list of checkout changes.
8:29:48 AM Beginning file download
8:29:48 AM BeginDownloadFiles returned: Success
8:29:49 AM VaultFileDownload starting
8:29:50 AM GetLatest wrote 10756818 bytes to the Response Stream
8:30:28 AM GetLatest wrote 10043353 bytes to the Response Stream
8:31:09 AM Ending download process
8:31:09 AM EndDownloadProcess returned: Success
notice how there is mere seconds between each 10mb write for the local user, but 20-30 minutes for each 10mb write for the remote users. the remote users can download (via ftp) from the same vault server at approximately 115kB/sec, or approximately 6mb a minute, so 10mb taking 20-30 minutes is really excessively long.
any ideas???
slow vault performance / transfer speed remote workstation
Moderator: SourceGear
If local users see fast download times, then it's probably not a Vault Server issue, but a network issue. Something on the network may be slowing the download.
Some things to check:
What's the bandwidth between client and server? Are clients communicating througha firewall or proxy? Could anti-virus software be slowing down read/writes? Also check network card configuration. Try changing the network card setting: full duplex or half duplex, whatever's different. Change the setting for Chunked encoding in the Vault GUI Client Tools->Options->Network settings.
Some things to check:
What's the bandwidth between client and server? Are clients communicating througha firewall or proxy? Could anti-virus software be slowing down read/writes? Also check network card configuration. Try changing the network card setting: full duplex or half duplex, whatever's different. Change the setting for Chunked encoding in the Vault GUI Client Tools->Options->Network settings.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
I aplogize for the lack of clarity. I didn't post the entire message I meant to post. the entire message should have been as follows:
we have a similiar problem, details follow; is there any solution?
Server: dual xeon 2.8ghz, 2gb ram, sql 2000 sp3, windows server 2000, vault 3.5.1.4786
database 9857mb, 4686mb available
34794 files, 2578 folders in this repository
Internal users do not have any issues.
a GLV that only takes me a minute or two to process (creating a project folder of ~ 65mb) might take one of our remote users 75 minutes.
the database buffer size is set to 256 but the help file says default is 768, could this have an effect?
reverse DNS is off
vault apparently sends data to IIS for delivery to the client in 10MB chunks, and this seems helpful in diagnosing slowness, because the vault log has this interesting content (simplified for posting):
remote user:
7:05:29 AM Getting repository Structure-> Rep ID: 1 Base: 35681 Target: -1
7:05:29 AM GetRepositoryStructure returned: Success
7:05:32 AM Getting list of checkout changes.
7:05:32 AM GetCheckOutListChanges returned: Success
7:05:39 AM Beginning file download
7:05:39 AM BeginDownloadFiles returned: Success
7:06:35 AM VaultFileDownload starting
7:06:36 AM GetLatest wrote 10756818 bytes to the Response Stream
7:25:19 AM GetLatest wrote 11148219 bytes to the Response Stream
7:54:12 AM GetLatest wrote 10038355 bytes to the Response Stream
8:32:09 AM Ending download process
8:32:09 AM EndDownloadProcess returned: Success
local user:
8:29:48 AM Getting repository Structure-> Rep ID: 1 Base: 35719 Target: -1
8:29:48 AM GetRepositoryStructure returned: Success
8:29:48 AM Getting list of checkout changes.
8:29:48 AM Beginning file download
8:29:48 AM BeginDownloadFiles returned: Success
8:29:49 AM VaultFileDownload starting
8:29:50 AM GetLatest wrote 10756818 bytes to the Response Stream
8:30:28 AM GetLatest wrote 10043353 bytes to the Response Stream
8:31:09 AM Ending download process
8:31:09 AM EndDownloadProcess returned: Success
notice how there is mere seconds between each 10mb write for the local user, but 20-30 minutes for each 10mb write for the remote users. the remote users can download (via ftp) from the same vault server at approximately 115kB/sec, or approximately 6mb a minute, so 10mb taking 20-30 minutes is really excessively long.
any ideas???
we have a similiar problem, details follow; is there any solution?
Server: dual xeon 2.8ghz, 2gb ram, sql 2000 sp3, windows server 2000, vault 3.5.1.4786
database 9857mb, 4686mb available
34794 files, 2578 folders in this repository
Internal users do not have any issues.
a GLV that only takes me a minute or two to process (creating a project folder of ~ 65mb) might take one of our remote users 75 minutes.
the database buffer size is set to 256 but the help file says default is 768, could this have an effect?
reverse DNS is off
vault apparently sends data to IIS for delivery to the client in 10MB chunks, and this seems helpful in diagnosing slowness, because the vault log has this interesting content (simplified for posting):
remote user:
7:05:29 AM Getting repository Structure-> Rep ID: 1 Base: 35681 Target: -1
7:05:29 AM GetRepositoryStructure returned: Success
7:05:32 AM Getting list of checkout changes.
7:05:32 AM GetCheckOutListChanges returned: Success
7:05:39 AM Beginning file download
7:05:39 AM BeginDownloadFiles returned: Success
7:06:35 AM VaultFileDownload starting
7:06:36 AM GetLatest wrote 10756818 bytes to the Response Stream
7:25:19 AM GetLatest wrote 11148219 bytes to the Response Stream
7:54:12 AM GetLatest wrote 10038355 bytes to the Response Stream
8:32:09 AM Ending download process
8:32:09 AM EndDownloadProcess returned: Success
local user:
8:29:48 AM Getting repository Structure-> Rep ID: 1 Base: 35719 Target: -1
8:29:48 AM GetRepositoryStructure returned: Success
8:29:48 AM Getting list of checkout changes.
8:29:48 AM Beginning file download
8:29:48 AM BeginDownloadFiles returned: Success
8:29:49 AM VaultFileDownload starting
8:29:50 AM GetLatest wrote 10756818 bytes to the Response Stream
8:30:28 AM GetLatest wrote 10043353 bytes to the Response Stream
8:31:09 AM Ending download process
8:31:09 AM EndDownloadProcess returned: Success
notice how there is mere seconds between each 10mb write for the local user, but 20-30 minutes for each 10mb write for the remote users. the remote users can download (via ftp) from the same vault server at approximately 115kB/sec, or approximately 6mb a minute, so 10mb taking 20-30 minutes is really excessively long.
any ideas???
and to respond to your questions:
the bandwidth for these remote users between the server and clients is approximately 10x the bandwidth that vault appears to actually make use of for the remote users. (they have a partial T1 capable of transferring at 100kB/s when used for other regular (FTP) file transfers.
shouldn't be any anti-virus problems, we use standard mcafee configuration both for the local LAN users and the remote users, so any problem should affect both equally (all our local LAN users are fast, and all our remote users are slow).
no proxy involved, and only standard firewall technologies via cisco routers, nothing esoteric.
we'll try the chunked encoding.
Are there any IIS-specific settings to optimize large data transfers in IIS? perhaps IIS can be optimized for the higher latency of the remote office connection (it's not actually a HIGH latency, just higher than a local LAN, as one would expect on a properly working remote connection).. if IIS is sending one data packet at a time and waiting for acknowledgement before sending another, that could be a huge issue.
If you or the developers have any IIS optimization tips that would be very helpful.
the bandwidth for these remote users between the server and clients is approximately 10x the bandwidth that vault appears to actually make use of for the remote users. (they have a partial T1 capable of transferring at 100kB/s when used for other regular (FTP) file transfers.
shouldn't be any anti-virus problems, we use standard mcafee configuration both for the local LAN users and the remote users, so any problem should affect both equally (all our local LAN users are fast, and all our remote users are slow).
no proxy involved, and only standard firewall technologies via cisco routers, nothing esoteric.
we'll try the chunked encoding.
Are there any IIS-specific settings to optimize large data transfers in IIS? perhaps IIS can be optimized for the higher latency of the remote office connection (it's not actually a HIGH latency, just higher than a local LAN, as one would expect on a properly working remote connection).. if IIS is sending one data packet at a time and waiting for acknowledgement before sending another, that could be a huge issue.
If you or the developers have any IIS optimization tips that would be very helpful.