Re: Redirection to Other IP Addresses

The alternative to small files, is that they could rather be bundled and rather pushed to the client from a single request,
With a header hint hash of all the individual small requests. Which would reduce the overhead on the wire, but not the overhead in the backend systems, which have to load balance. For static files hash of the file response with life cycle of the file headers included, would work
Well too.

Same as the old issue copying small file problems, OS need like a parallel buffer data write and buffered meta data write the the File allocation table, So speed up writing of small files in batches, as small files kill copy speed. So batch two parts to be be maintained, hopefully would improve performance of the overall copy speed.

> On 30 Jul 2019, at 09:34, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> On 30/07/19 7:02 am, Bin Ni wrote:
>> Yes, what we want is a way to force a "deterministic behavior from the
>> client", just like all the 30X redirections today.
>>
>> Let me give a few more cases in which this can be helpful:
>> 1. A client in North America is returned a server IP in Europe by the
>> DNS. The server then wants to direct the client to another server in
>> North America for better performance.
>> 2. The content of a website is hashed to multiple servers based on URL.
>> These multiple servers may not even be in the same datacenter. The DNS
>> does not have this information and may return any IP to any query of the
>> website's hostname.  Each server will calculate the hash for each
>> request and redirect client to the correct server that has the content.
>> This is quite common for CDN.
>
> It is common for good reason: efficiency.
>
> There is a secondary level of efficiency that comes from the redirects
> being actual HTTP 30x redirects. Having large objects at different URL
> entirely provides for a different CDN or caching layer closer to the
> client to provide the large object contents. DNS can be (often is)
> involved in that layer to provide the closest server IP.
>
> As proposed so far your mechanism would flatten this two-tier structure.
> Forcing the frontend layer (now only layer) to be involved in deciding
> the specific hardware location of individual objects / resources.
> Making the frontend machinery store more information and do more work
> per-request is not going to make the system faster, quite the opposite.
>
>
> By separating the work into the three layers: frontend LB, cache, and
> origin. Each CDN layer gets some orders of magnitude increase in
> performance / capacity:
> - origin able to handle/generate some few thousand responses per second,
> - cache able to re-distribute those as static objects at line speed for
> an order or two magnitude more than origins,
> - frontend LB able to handle millions of the small ~1KB
> request/response pairs for redirection spreading that high load across
> the lower layers.
>
>
> AYJ
>

This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners.
"This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this linkhttps://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy"

Received on Tuesday, 30 July 2019 08:02:46 UTC