Hi Andy,
On 03.09.2013 01:06, Andrew Hanushevsky wrote:
> 1) All bytes are transferred through a single pipe. That means if I
> have two clients and one is reading 1K blocks and the other is reading
> 1M blocks the 1K block client suffers the same latency as if it had been
> reading 1M blocks. Same is true for writing. One xrdcp can destroy
> performance for everybody.
You have kXR_oksofar responses that would split large reads into
small chunks making it possible to interleave other responses. You use
this quite extensively.
> 2) Should a TCP packet get dropped and we go into packet recovery
> then all clients see the increased latency. Since we have everything
> going through a single pipe the odds of that happening increase.
True, but single packet loses rarely cause non-negligible
performance issues. Multiple packet loses would affect all connections
equally.
> 3) Meta operations are, by their nature, serialized by the server.
> That means they wpuld impact all clients whenever they occur. Since some
> may take a bit of time to do there may be a substantial delay that
> penalizes all clients that simply want to do I/O.
I don't understand what you mean by this.
> The extra overhead in doing authentication is no worse than the each
> client contacting the server directly as would be the case without a
> proxy. So, that argument is moot. In fact, most sites employ a simple
> authentication scheme between a proxy and a server which makes the
> overhead negligible compared to the downside of serializing all the
> traffic through a single physical socket.
It looks like Alja is using X509.
> A physical single socket severely limits any kind of parallelism in most
> cases. Virtual streams buy you nothing in this case. The bytes are bound
> to a single physical communication channel that works serially by its
> design. That means performance is bound by the slowest client.
So does a NIC and Ethernet.
Cheers,
Lukasz
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|