cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: HTTP PUT performance issues

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 5 Dec 2002 20:02:46 +0100 (MET)

On Thu, 5 Dec 2002 RBramante_at_on.com wrote:

> OK sounds good. I hope you find something because I am really confused by
> this as well if the ftp and http xfer code is the same.

Did the tests and I've learned some new things. I'll show you:

Test machine is a 733MHz Pentium III running Linux kernel 2.4.18.

All tests were done on a file I have that is 843309644 bytes big.

'httpput' sent it all in 135 seconds to my Apache2 on localhost (the receiver
is a perl script that sends the received data to /dev/null). It makes 6246738
bytes per second. That makes it 5.95MB/sec.

Clearly my Apache receives HTTP PUT *much* slower than my wu-ftpd receives
ftp upload.

I modified my curl to always loop until EWOULDBLOCK before going back to
select(), and then uploading (HTTP PUT) the exact same.

It took 134 seconds. Pretty much the same speed, I'd say.

I then went back and fired away an older curl I have installed (7.9.9-pre1)
and it ran the same test at 136 seconds.

The amount of select()s clearly has no particular impact on this test here.
It might be because the server is the one slowing down the operation or,
perhaps more likely, it is because windows has a higher penalty for using
select().

Test number two:

I run 'nc -l -p 8888 >/dev/null' to just accept a PUT and read it at highest
possible speed. The timings showed:

Modified curl: 44 seconds
httpput: 43 seconds
Old curl: 44 seconds

Summary:

There is no speed issues with HTTP PUT with curl on Linux. At least not that
I can provoke to appear.

Do you think you could get the latest sources off CVS and try them on win32?
My changes might make a different impact on Windows than on Linux.

--
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-12-05