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.

I took a network trace of the ftp upload and compared it with the http
upload.

What I found:

Total packets transacted: ftp-1950 http-1930
Packets curl -> server ftp-1267 http-1255
Packets server -> curl ftp-683 http-675

So no great diff there, both send about the same amount of packets. A
quick look shows that we always send full packets (1460) for both uploads.
The server window never drops to 0 but one diff is that the http window
always remains pretty much fully open (opens at 17520 and never falls very
far beneath that). The ftp window opens at 17520 and drops as low as 5840
several times. Interesting.....but what does it mean????

My only guess is maybe the server ACKs come back quicker from the ftp
server? But why would this be, and since the server window never drops to
0 what does it even matter?

Is there any tool that can take a tcpdump file and analyze it for things
like this? Reading through the response times for 3800+ packets seems a
bit tedious....

                                                                                                                                            
                      Daniel Stenberg
                      <daniel_at_haxx.se> To: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
                      Sent by: cc:
                      curl-library-admin_at_lists.sour Subject: Re: HTTP PUT performance issues
                      ceforge.net
                                                                                                                                            
                                                                                                                                            
                      12/05/2002 08:21 AM
                      Please respond to
                      curl-library
                                                                                                                                            
                                                                                                                                            

On Wed, 4 Dec 2002 RBramante_at_on.com wrote:

> I put a freeware ftpd on that windows machine and the xfer takes about 5
> seconds, so the curl ftp xfer is abount 3x faster than the http one.

Indeed an interesting result, even if it matches my own tests. So how can
the
ftp upload run so much faster when it is the same code in curl that is
executed?

> Very strange indeed. I also wrote a very dumb c app to do the http put
and
> tested that. Again, it takes ~2 seconds to do the 1.6. So both the java
> app and my c app do it about the same. You can use it for testing. There
> is no error checking and it breaks about 100 rules of network
programming,
> but it should serve its purpose for comparison.

Thanks for doing this. I'll run your test-program on the same machine I did
my previous tests on later tonight and see what happens.

> Since we spend so much time in select() I'm wondering how we do the
> read/writes. For example for write (since this is the current problem)
> when select() returns the socket as writable, do we do one send() and
then
> go back and select() again, or do we send() until we get an EWOULDBLOCK
and
> then go back and select()? If we are doing the former it might explain
> some of the latency. The same would apply for recv(). If readable, recv
()
> until EWOULDBLOCK and only then go to the select().

Right. curl does it the "bad" way:

 1 - select()
 2 - when a writeable socket is detected:
 3 - read() data to send away (unless previous data wasn't sent off)
 4 - send() data
 5 - GOTO 1

I figure step 5 should be remade to a GOTO 3 until the send returns
EWOULDBLOCK.

The only weird thing is of course that ftp uploading is done the very same
way...

I'll do this:

First, I'll compile, build and run your test program on my test server.
It'll
give me a good comparison on how fast it *should* be (at least it should be
in the same neighborhood).

Then, I'll rewrite the inner loop of the transfer logic to see if we can
achieve it that way.

I'll report my findings as soon as I have anything to share.

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