Re: [arch-d] HTTP 2.0 + Performance improvement Idea

[Joe Touch <[e-mail]>]

You sound like you're looking for NFS; maybe you should propose an "NSF 
over HTTP" variant where responses can be issued out of order?

Joe

On 3/25/2014 4:56 AM, Rakshith Venkatesh wrote:
> Hi,
>
> I was going through SPDY draft or the HTTP 2.0 initial draft. I had an
> idea which I think would require a change in the architecture of the
> same and so I am dropping this mail. Here is the idea:
>
> A Http client expects the server to send data in-order. (NOTE: When I
> say a server, I am referring to an appliance to which disks are attached
> and the file resides on the disk.). If there is a file let’s say 10GB
> and if the client asks for this file from the server, the data has to be
> given in-order from the 1^st byte till the last byte. Now let’s say I
> implement an engine at the server side to do a parallel read on this
> huge file to fetch data at various offsets within the file, I will be
> able to fetch the data faster for sure but, I will not be able to send
> across the data immediately as and when I fetch it. I am expected to
> finish doing all parallel reads on the file till I read all the bytes,
> then send across the wire to the client.
>
> Now if we can have some tag or header which can be introduced as part of
> HTTP 2.0 which actually can help re-order the byte stream at the session
> layer or at a layer in between the application and session layer, we
> could potentially improve the performance for File reads using HTTP by
> making sure that the new module looks at this new tag and jumbles around
> the data based on this tag and eventually presents the data to HTTP to
> make it look all seamless.
>
> So the server can just do parallel reads on the same file at various
> offsets without worrying about ordering and send across the read chunks
> and this new module sitting at the client side can intervene and look at
> some form of tag/header to make sure it swaps the data accordingly and
> waits till all data is received and then present it to the Application
> protocol.
>
> NOTE: I am not referring to packet-reordering at TCP.
>
> By having this, servers can attain true parallelism in reading the file
> and can effectively improve file transfer rates.
>
>
> Thanks,
>
> Rakshith
>
>
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>