Does having squid proxy caching on top of a caching appliance on MPLS line be helpful for Jazz source control?
IBM recommends squid caching for faster access to RTC source code. However, at one of the sites, MPLS
links have a Riverbed Steelhead caching appliance to cache the content on the line itself.
What we would like to know is, how different is the squid proxy setup from accessing the file through proxy URL when compared to accessing via cached MPLS line ?
In this case, will there be any benefit of setting up an additional caching server for accessing RTC source files above the cached MPLS line ?
Any additional information on this should help.
Thank you
|
Accepted answer
Ralph Schoon (63.5k●3●36●46)
| answered Feb 02 '15, 11:35 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Sumant,
I would suggest to talk to the vendor of your appliance. The squid caching proxy simply caches work item attachments as well as SCM data. If your appliance already caches that, there is no benefit. Sumant Renukarya selected this answer as the correct answer
|
One other answer
|
While I do not have in-depth details on how different is the squid proxy setup from accessing the file through proxy URL when compared to accessing via cached MPLS line using Riverbed Steelhead, here are some of the details which should help:
a. In case of squid proxy cache server, when you load or update a workspace, the client receives back a list of content identifiers from the target (non-proxy) server.
These content objects are then retrieved in parallel through the proxy server.
Any cache hit on these content fetches are returning unchanging data, which shall be equivalent to any request fetched from the originating server.
b. Jazz Source Control does not have any specific dependencies on any proxy, and it should be possible to plug in any HTTP-based caching proxy technology.
c. Caching systems use the file as their object type, and the name of the file is the tag by which caches recognize it.
When a user changes “Overview.doc” to “Overview – edited.doc” caches no longer recognize that this is data that has previously moved across the network.
If a file name changes -- despite the fact that little or no data in the actual document may have changed -- caches can no longer optimize the transfer.
If your organization is willing to use an iron fist in order to require users to never change file names, perhaps a cache would be a good fit.
==>
Looking into the details on the the Riverbed Steelhead caching appliance, I found the following:
a. Riverbed Steelhead is a WAN acceleration appliance and is part file cache, part proxy, and part TCP optimization, providing a unique and extremely effective way of reducing the time spent transferring files from one office to another.
b. Steelhead sits transparently on the LAN between your firewall and your servers.
As files and other TCP traffic pass through it, Steelhead automatically analyzes the stream.
A technology developed by Riverbed called Scalable Data Referencing breaks the data into indexed chunks and stores it in a local disk cache.
The power of Steelhead kicks in when you pass the same or similar traffic back through the appliances over the WAN.
Steelhead recognizes the patterns, finds matches in the data store, and sends only a reference pointer for each chunk of data to the other side.
There, the reference pointer is used to rebuild the traffic on the fly so that the TCP stream arrives intact.
By sending only a small pointer and not the whole file, the appliance greatly increases perceived performance over the link and dramatically reduces the time spent waiting for the data.
==>
1. Based on this, we believe setting up an additional caching server for accessing RTC source files might or might not help in terms of performance improvement on top of the Steelbed appliance. However, to what extent if it does help is something that has not been tested or tried by IBM.
2. The following forum discussion from riverbed should help as well,
w.r.t difference and advantage of using cache over and above steelhead:
https://splash.riverbed.com/thread/2299
http://www.nle.com/literature/Riverbed_WAFS_and_Caching.pdf
3. To what extent a reverse accelarator proxy configuration with squid against the main jazz.net source code repository has helped is outlined here:
https://jazz.net/library/article/325
Look for "Using this ourselves on jazz.net" section
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
I did find this information but to what extent will having squid cache proxy server on top of caching appliance for accessing files is missing: