Skip to main content

[pkg-discuss] Re: The future of the pkg mirror

  • From: Tim Foster < >
  • To:
  • Cc: Erik Trauschke < >
  • Subject: [pkg-discuss] Re: The future of the pkg mirror
  • Date: Wed, 01 May 2013 11:11:48 +1200

On 05/ 1/13 10:56 AM, Erik Trauschke wrote:
Changing the current mirror behavior might be
confusing to users so I think it's better to retire the old mirror
functionality and provide the new one with a new name.

Ok. (I really meant behind the covers in the client - if this is just a s/mirror/new-fangled-name/ then that's fine too :)

Why? If the content servers are overloaded, the origin might still be
capable of serving the data, and might be faster.
>>
Yes, but like mentioned above, I think the origin should not be
considered for the auto-tune. It might not even be an issue because the
http downloads over akamai are probably always faster than the https
downloads from pkg.oracle.com but we should try to transport files over
the alternate source if possible.

Imagine customers who don't have their own Akamai servers and just want to provide multiple geographically-distributed pkg/depot servers for their org.

In that case, they'd need to specify one "master" origin, then also include that master origin in the list of CDN mirrors as well - it just seems weird not to consider the origin as being capable of serving content from the start, rather than have them worry about ensuring it's in the CDN list as well.

To put it another way, I can't see any reason for not considering the origin as a source of pkg data. If it's slower to access, then won't the transport still work that out, and tune accordingly?

* If clients are routinely connecting to multiple servers to obtain
content, that might defeat any local proxy-caching that's going on
(since the proxy could have references to multiple URLs containing the
same content) For example, this could upset the system repository cache
on systems with lots of zones.

Will it actually upset the cache? I could imagine you just end up with
the same file/content under different hashes. So it would require
additional space but still be correct, not?

Right - bad choice of words on my part: it makes the cache less efficient for multiple clients if they're not all accessing the content through the same URI because the cache is maintaining more than one copy of the same data: more space used in the cache, more network overhead retrieving duplicate copies of the same data.


        cheers,
                        tim



[pkg-discuss] The future of the pkg mirror

Erik Trauschke 04/30/2013

[pkg-discuss] Re: The future of the pkg mirror

Bart Smaalders 04/30/2013

[pkg-discuss] Re: The future of the pkg mirror

Erik Trauschke 04/30/2013

[pkg-discuss] Re: The future of the pkg mirror

Tim Foster 04/30/2013

[pkg-discuss] Re: The future of the pkg mirror

Erik Trauschke 04/30/2013

[pkg-discuss] Re: The future of the pkg mirror

Tim Foster 04/30/2013
 
 
Close
loading
Please Confirm
Close