[ipxe-devel] undionly.kpxe http download slow
Levente LEVAI
levail at aviatronic.hu
Tue Oct 29 08:59:32 UTC 2013
On 2013-10-28 18:56, Michael Brown wrote:
> On 28/10/13 17:05, Daniel Pittman wrote:
>> It didn't include a "Content-Length" header in the HTTP response, just
>> sent an HTTP chunked file down to iPXE. This led to insanely slow
>> downloads; once we patched Sinatra to include that header downloads
>> are comparable to TFTP performance.
>>
>> Our theory, which we never investigated enough to verify, was that
>> this is some sort of memory management issue in the downloader, which
>> spends increasing amounts of time reallocating and moving memory
>> around as the download buffer grows. (eg: over an hour for 170MB,
>> compared to less than a minute once Content-Length is included.)
>
> Yes; that will be the behaviour if no Content-Length is provided.
> Downloaded images are placed at the top of free (32-bit) memory, and
> if the size is unknown then it will effectively perform a realloc()
> for each 4kB chunk. Once the image gets sufficiently large, the time
> taken for a realloc() starts to cause dropped packets, which further
> impacts performance.
>
> With a Content-Length present, HTTP should be substantially faster
> than TFTP, since the window size for TCP transfers is 256kB compared
> to 1.5kB (one packet) for TFTP. For reference, HTTP transfers should
> achieve full line speed on a link of up to 1Gbps, which gives ~120MB/s
> of downloaded data.
>
> Michael
I looked into what is being sent (tcpdump), and yes, you are absolutely
right: publicfile httpd
sends no Content-Length header. I tried with nginx (which does send this
header), it was
difficult to measure the speed, certainly below 2secs for 20MB (=link
speed as you wrote,
I have a 100Mb line).
Maybe all this should be mentioned somewhere in the docs.
Thanks for the insight!
BR
Levente
More information about the ipxe-devel
mailing list