Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
niedz., 2 wrz 2018 o 13:33 Jan Ehrhardt via curl-library napisał(a): > > Do you have a compiled version somewhere? I'm hacking this on Linux, I don't have a proper testing environment on my Windows machine. > I tried to build my own with the 3 patches: > > 1. winsock > 2. oploadbuffer 512 KB > 3. sftp writeback in libssh2 > > Dissappointing results for a 274MB sftp upload against a remote CoreFTP > server: > - bash / ssh / lftp: 68 seconds > - openssh portable sftp: 50 seconds > - curl triple patched: 734 seconds > ping of the remote machine: 3-4 ms. That's like 5MB/s best case, 300KB/s worst case; what's your limiting factor? Network? Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
Jan Ehrhardt via curl-library (Sun, 26 Aug 2018 16:03:16 +0200): >Daniel Jelinski via curl-library (Sun, 26 Aug 2018 09:09:58 +0200): >>added 100ms: original 310kB/sec, patched 9900kB/sec > >Impressive results! Do you have a compiled version somewhere? I tried to build my own with the 3 patches: 1. winsock 2. oploadbuffer 512 KB 3. sftp writeback in libssh2 Dissappointing results for a 274MB sftp upload against a remote CoreFTP server: - bash / ssh / lftp: 68 seconds - openssh portable sftp: 50 seconds - curl triple patched: 734 seconds ping of the remote machine: 3-4 ms. Used cipher in openssh portable sftp: AES128-CBC. In production we have an old version of the CoreFTP server. On our dev machine I am going to install the most recent CoreFTP server version. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
Jan Ehrhardt via curl-library (Sun, 26 Aug 2018 16:28:47 +0200): >Daniel Jelinski via curl-library (Sun, 26 Aug 2018 09:09:58 +0200): >>The patched version is CPU-bound on lower latencies; when the latency >>goes higher, SSH window becomes the limiting factor. I read that HPN >>SSH should do better on high latency links, didn't try it out. > >A lot of PR's for HPN-SSH came from @allanjude. Interesting stuff: >http://www.allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf In May 2017 Allan Jude posted a new HPN patch here: https://lists.freebsd.org/pipermail/freebsd-current/2017-May/066015.html Quote: > In my benchmarks with 100ms of latency (from dummynet) is increases SSH > send throughput from 1 megabyte/sec to 225 megabytes/sec provided a > large enough socket buffer. I cannot reproduce that. I applied a modified version of this patch to OpenSSH-portable for Windows: https://github.com/Jan-E/openssh-portable/commit/e5c711f66aa3a14980dc7e0ca8504d0bda614fa6 For anyone that wants to try it: https://phpdev.toolsforresearch.com/expect.7z The scripting is done with Expect for Windows: https://github.com/zetamatta/expect/issues/8#issuecomment-416445736 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
Daniel Jelinski via curl-library (Sun, 26 Aug 2018 09:09:58 +0200): >The patched version is CPU-bound on lower latencies; when the latency >goes higher, SSH window becomes the limiting factor. I read that HPN >SSH should do better on high latency links, didn't try it out. A lot of PR's for HPN-SSH came from @allanjude. Interesting stuff: http://www.allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
Daniel Jelinski via curl-library (Sun, 26 Aug 2018 09:09:58 +0200): >added 100ms: original 310kB/sec, patched 9900kB/sec Impressive results! >The patched version is CPU-bound on lower latencies; when the latency >goes higher, SSH window becomes the limiting factor. I read that HPN >SSH should do better on high latency links, didn't try it out. I had also been looking at HPN SSH. If you try that you should increase the buffersize as well: https://github.com/rapier1/openssh-portable/pull/11 >https://github.com/djelinski/libssh2/commit/c321b5d3a0ed964b291c710179dde7385e514ef7 >It's not ready for inclusion; it requires cleanup, and breaks SSL >backends other than openSSL with AES-CTR support. There is an open issue with AES-CTR in HPN SSH: https://github.com/rapier1/openssh-portable/issues/13#issuecomment-279778429 I did not run any tests yet. I will see if I can build it for Windows under Cygwin. https://github.com/rapier1/hpn-ssh/tree/master/contrib/cygwin -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
niedz., 26 sie 2018 o 03:36 Jan Ehrhardt via curl-library napisał(a): > Do you have any stats about the performanceimprovement? Workbench: I am running curl against openssh 7.2 shipped with Ubuntu. The server is running on the same machine as the client. I am uploading 1GB file to /dev/null on the server. My laptop is running a 2nd gen i3 CPU without hardware AES support. I'm tweaking network latency using tc. Curl speed was taken from curl-reported average when the transfer took less than a minute. For slower transfers I took a representative value from the momentary upload speed. Results with 16kB curl upload buffer: no delay added: original 12MB/sec, patched 33 MB/sec added 20 ms: original 390kB/sec, patched 26.6 MB/sec added 100ms: original 81 kB/sec, patched 9700 kB/sec Results with 64kB curl upload buffer: no delay added: original 27MB/sec, patched 35 MB/sec added 20 ms: original 1400kB/sec, patched 30MB/sec added 100ms: original 310kB/sec, patched 9900kB/sec The patched version is CPU-bound on lower latencies; when the latency goes higher, SSH window becomes the limiting factor. I read that HPN SSH should do better on high latency links, didn't try it out. Separately I have a work-in-progress patch that improves the CPU usage; I was able to reach 80MB/s transfers with that patch applied. You can see it here: https://github.com/djelinski/libssh2/commit/c321b5d3a0ed964b291c710179dde7385e514ef7 It's not ready for inclusion; it requires cleanup, and breaks SSL backends other than openSSL with AES-CTR support. If you have openSSL with AES support, it might be worth a try. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
Daniel Jelinski via curl-library (Sun, 26 Aug 2018 01:07:14 +0200): >sob., 11 sie 2018 o 01:05 Daniel Stenberg napisa?(a): >> It would require that libssh2 provides such an API, which it currently >> doesn't >> (and I don't know anyone working on it). > >Sent a PR to libssh2 for that: https://github.com/libssh2/libssh2/pull/264 Do you have any stats about the performanceimprovement? -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
On Sat, Aug 25, 2018, 4:10 PM Daniel Jeliński via curl-library < curl-library@cool.haxx.se> wrote: > sob., 11 sie 2018 o 01:05 Daniel Stenberg napisał(a): > > It would require that libssh2 provides such an API, which it currently > doesn't > > (and I don't know anyone working on it). > > Sent a PR to libssh2 for that: https://github.com/libssh2/libssh2/pull/264 > > > I still haven't checked what libssh provides or how it performs in > comparison. > > Just checked, looks about the same here. > > --- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
libssh2 optimization [was: Re: Windows users! Help us test upload performance tuning?]
sob., 11 sie 2018 o 01:05 Daniel Stenberg napisał(a): > It would require that libssh2 provides such an API, which it currently doesn't > (and I don't know anyone working on it). Sent a PR to libssh2 for that: https://github.com/libssh2/libssh2/pull/264 > I still haven't checked what libssh provides or how it performs in comparison. Just checked, looks about the same here. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Sat, 18 Aug 2018, Daniel Stenberg via curl-library wrote: uploading to localhost means this test both encrypts and decrypts on the same CPU. Oops. This might not be accurate actually, since I have 4 (multi-threaded) cores they probably did that on different cores... -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Sat, 18 Aug 2018, Daniel Jeliński via curl-library wrote: I don't believe encryption is to blame here, at least not on curl side. I was able to upload 40 MB/s over https on plain 7.60 with 4MB socket buffer. Encryption takes more CPU or hardware to get the job done so if you're CPU bound and/or have huge bandwidth then encrypted transfers will of course be slower. With the same linux machine as I ran the previous tests, but this time against an nginx on localhost: - 7.61.0 $ time curl -sT 4GB -k https://localhost/sample.cgi 5.975s - 7.61.1-DEV (with 64KB upload buffer) 5.128s (780031201 bytes/sec) Uploading over plain HTTP took 1.281 seconds with this buffer size (pretty much exactly 4 times faster). But also, uploading to localhost means this test both encrypts and decrypts on the same CPU. As I showed before, if I upload HTTPS to my web site over a gigabit connection I can saturate it; 100MB/sec. On a six years old desktop PC. -- / daniel.haxx.se--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
W dniu sobota, 18 sierpnia 2018 Jan Ehrhardt via curl-library < curl-library@cool.haxx.se> napisał(a): > We had a real oops when we tested the same 178 MB over plain FTP: > > curl x64 512KB upload buffer FTP: 16 seconds > https upload php uploadprogress : 489 seconds I don't believe encryption is to blame here, at least not on curl side. I was able to upload 40 MB/s over https on plain 7.60 with 4MB socket buffer. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt via curl-library (Wed, 15 Aug 2018 22:51:34 +0200): >Network connection: about 200 Mbits/s up, 200ms latency (speedtest.net) >Test file: 178 MB mp4 >Protocol: sftp > >iPad app 32 KB libssh2 buffer: 2147 seconds >iPad app 320 KB libssh2 buffer: 737 seconds >Filezilla (out-of-the-box): 967 seconds >curl x64 512 KB upload buffer: 1154 seconds We had a real oops when we tested the same 178 MB over plain FTP: curl x64 512KB upload buffer FTP: 16 seconds https upload php uploadprogress : 489 seconds % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 176M0 0 100 176M 0 11.0M 0:00:16 0:00:16 --:--:-- 13.6M start:2.062000 total:16.01500a0 Unencrypted uploads are legally (the HIPAA act) prohibited, but the price for encryption is really high. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Tue, 14 Aug 2018, Daniel Stenberg via curl-library wrote: Update! I would like us to... 1. Change to alloc-on-demand for this buffer. It is used for a few non-upload things, but it only needs to be this big for actual uploads, and most transfers are not. That'll save (almost) 16KB for all download-only handles. 2. Enlarge the default upload buffer size to 64KB. These two steps have now been done and pushed to master. 3. Add a CURLOPT_UPLOADBUFFERSIZE option that allows users to set their preferred size, from 16KB up to perhaps a few megabytes. I intend to write upp a pull-request for this and queue for merging in the next feature window after the pending release on September 5. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Tue, 14 Aug 2018, Daniel Stenberg via curl-library wrote: I would like us to... To make sure we keep track of this, I filed a bug: https://github.com/curl/curl/issues/2888 -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg via curl-library (Tue, 14 Aug 2018 09:39:21 +0200 (CEST)): >I think its time we run some tests in an orderly fashion with different upload >buffer sizes and collect some numbers... Feedback on some informal upload tests from Phoenix, Arizona to Amsterdam, NL. High speed connection. Upload around 200 Mbits/s according to speedtest.net, but a latency of 200ms. My tester uploaded a 178MB mp4 file first with the unpatched iPad app (libssh2, not curl), then with a patched iPad app, then used Filezilla and last, but not least a patched curl.exe. Network connection: about 200 Mbits/s up, 200ms latency (speedtest.net) Test file: 178 MB mp4 Protocol: sftp iPad app 32 KB libssh2 buffer: 2147 seconds iPad app 320 KB libssh2 buffer: 737 seconds Filezilla (out-of-the-box): 967 seconds curl x64 512 KB upload buffer: 1154 seconds % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 176M0 0 100 176M 0 156k 0:19:14 0:19:14 --:--:-- 195k 100 176M0 0 100 176M 0 156k 0:19:14 0:19:14 --:--:-- 156k start:2.437000 total:1154.047000 Speed sometimes as low as 125K, said my tester. At the same time another user from the same network was uploading a 289 MB mp4 file in 1106 seconds, using bash/lftp. At the same speed that would have been 681 seconds for the tester's 178 MB file. bash/lftp may be some 8% faster than the patched iPad app. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Tue, 14 Aug 2018, Jan Ehrhardt via curl-library wrote: Thanks for the stats. It indicates that my choice for 320 KB in the iOS app (using sftp) is quite good. I would like us to... 1. Change to alloc-on-demand for this buffer. It is used for a few non-upload things, but it only needs to be this big for actual uploads, and most transfers are not. That'll save (almost) 16KB for all download-only handles. 2. Enlarge the default upload buffer size to 64KB. 3. Add a CURLOPT_UPLOADBUFFERSIZE option that allows users to set their preferred size, from 16KB up to perhaps a few megabytes. I remembered reading something about this, but it doesn't seem related (and was resolved anyway). But maybe it gives a clue: https://github.com/icing/mod_h2/issues/130 Okay! I'm also quite sure we have some optimizations left to do in the libcurl side of the HTTP/2 transfers... -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg via curl-library (Tue, 14 Aug 2018 12:02:46 +0200 (CEST)): > Size Seconds Improvement > > 16 KB2.522- > 64 KB1.281x 1.97 > 128 KB 1.095x 2.30 > 256 KB 0.938x 2.69 > 512 KB 0.860x 2.93 Thanks for the stats. It indicates that my choice for 320 KB in the iOS app (using sftp) is quite good. >(Amazingly enough, HTTP/1.1 being 2.33 times faster than HTTP/2 ...) I remembered reading something about this, but it doesn't seem related (and was resolved anyway). But maybe it gives a clue: https://github.com/icing/mod_h2/issues/130 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Tue, 14 Aug 2018, Jan Ehrhardt via curl-library wrote: I did not test if there is a difference on *nix. Did you? Here are the results my tests run just now. Using Linux kernel 4.17. Upload 4GB over plain HTTP to Apache 2.4.34 on localhost - so really 0 RTT. I ran "time curl -sT 4GB localhost -o /dev/null". The results are clearly saying larger buffers help. Average times over 4 consecutive runs with each buffer size (using the "real" time from the output). Size Seconds Improvement 16 KB2.522- 64 KB1.281x 1.97 128 KB 1.095x 2.30 256 KB 0.938x 2.69 512 KB 0.860x 2.93 -- Then I sent 500MB in a PUT to https://daniel.haxx.se, which is really close to me RTT wise (average ping 0.931 ms). I have a 1000 mbit connection to the Internet. Also using HTTPS. When using HTTP/2: This showed no gain at all with a larger buffer, it actually got slightly worse. Also shows HTTP/2 uploads need attention and improvements. Size Seconds Improvement 16KB 13.682 - 64KB 14.488 x 0.94 512KB14.306 x 0.96 When I instead did the same upload over HTTPS to the same host but forced HTTP/1.1 the speeds were all remarkably similar. 500MB in 5 seconds should be just about maximum for 1000mbit... Size Seconds Improvement 16KB 5.872- 64KB 5.838x 1 512KB5.841x 1 (Amazingly enough, HTTP/1.1 being 2.33 times faster than HTTP/2 ...) -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg via curl-library (Tue, 14 Aug 2018 09:39:21 +0200 (CEST)): >I think its time we run some tests in an orderly fashion with different upload >buffer sizes and collect some numbers... I did not test if there is a difference on *nix. Did you? Anyway, I agree with the fact that some testing has to be done. By more than 2 or 3 people... -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Tue, 14 Aug 2018, Jan Ehrhardt wrote: my tests indicated that increasing this value also influenced the FTP upload speeds. From 10 to 5 seconds on XP in Daniel Jelinski's testcurl uploads. And down to less than a second on Win 7 and Win 10. Right. So yes, there's certainly a valid reason to consider and work on upping the upload buffer size for all protocols. I suppose we simply haven't done enough upload speed comprisons and tests recently... If plain FTP uploads can go faster with a larger buffer, that's an indication that *all* TCP protocols can be done faster if given larger buffers. (At least on Windows.) How much larger buffer is sensible? If we're talking about changing the default size. The current buffer size has been used since basically day 1 and both the Internet and devices that run curl have changed a bit since then... It would probably still be valuable to allow applications to set the upload buffer size a similar way it can set download buffer size. Or should we even set the upload buffer to the same size as that one? I think its time we run some tests in an orderly fashion with different upload buffer sizes and collect some numbers... -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg via curl-library (Mon, 13 Aug 2018 23:37:56 +0200 (CEST)): >On Mon, 13 Aug 2018, Jan Ehrhardt via curl-library wrote: > >> Daniel Stenberg (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)): >> -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE >> +#define UPLOAD_BUFSIZE (512*1024) >> >> @Daniel Stenberg: is there a reason that is stopping you from changing this >> in curl? > >Yes. (Pretty much explained already in the TODO: >https://curl.haxx.se/docs/todo.html#Modified_buffer_size_approach) Clear. But what strikes me: only SFTP is mentioned, but my tests indicated that increasing this value also influenced the FTP upload speeds. From 10 to 5 seconds on XP in Daniel Jelinski's testcurl uploads. And down to less than a second on Win 7 and Win 10. >1. This buffer is allocated as part of the regular easy handle and increasing >that allocation this much in one go I fear will cause problems to some >existing applications out there. Especially those doing a huge amount of >parallel transfers. I can imagine this. In my iOS app (using libssh2, not curl), there are no parallel transfers, but only single transfers of typically 200MB+ files. >2. There's basically only SFTP that needs this huge buffer so it seems >wasteful to always use such a large buffer if it isn't necessary. I would like >to see it conditionally enlarged if SFTP is indeed used. Sure? What about FTP uploads? See https://curl.haxx.se/mail/lib-2018-08/0150.html >3. I think it might be a good idea to let the application control the SFTP >size, so that the 1,000 parallel transfer applications can use a smaller >buffer and the single connection apps can use a larger. The iOS NMSSH library did just that. The buffersize is configurable from the calling app. >Besides all that, it would also be interesting to work out what an "ideal" >size might be. Is 512KB large enough? Is 256KB enough for 99% of the cases? >Would 1MB help in the extremely high speed high latency cases? In my iOS tests I settled for 320KB, but that was was for a 4-5 ms latency connection. I have no idea whet the effect would be for high latency connections. And the app crashed with 512KB, most likely due to memory allocation issues. Debugging on iOS is no easy job, so I did nit investigate further. >Would it be sensible to attempt to detect the situation and dynamicly grow the >size if deemed fine? Ouch. Seems a hell of a job to auto-detect an optimal size. Better make it configurable from outside (API, command line option). -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Mon, 13 Aug 2018, Jan Ehrhardt via curl-library wrote: Daniel Stenberg (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)): -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE +#define UPLOAD_BUFSIZE (512*1024) @Daniel Stenberg: is there a reason that is stopping you from changing this in curl? Yes. (Pretty much explained already in the TODO: https://curl.haxx.se/docs/todo.html#Modified_buffer_size_approach) 1. This buffer is allocated as part of the regular easy handle and increasing that allocation this much in one go I fear will cause problems to some existing applications out there. Especially those doing a huge amount of parallel transfers. 2. There's basically only SFTP that needs this huge buffer so it seems wasteful to always use such a large buffer if it isn't necessary. I would like to see it conditionally enlarged if SFTP is indeed used. 3. I think it might be a good idea to let the application control the SFTP size, so that the 1,000 parallel transfer applications can use a smaller buffer and the single connection apps can use a larger. Besides all that, it would also be interesting to work out what an "ideal" size might be. Is 512KB large enough? Is 256KB enough for 99% of the cases? Would 1MB help in the extremely high speed high latency cases? Would it be sensible to attempt to detect the situation and dynamicly grow the size if deemed fine? -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)): -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE +#define UPLOAD_BUFSIZE (512*1024) @Daniel Stenberg: is there a reason that is stopping you from changing this in curl? -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg via curl-library (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)): >-#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE >+#define UPLOAD_BUFSIZE (512*1024) This extra patch also had major speed improvements for Daniel Jelinski's testcurl.bat. I have now included a fully static curl-vc9-x86-double-patched.exe in https://phpdev.toolsforresearch.com/curl-mingw32-7.61.0.zip The two cross-compiled curl's in the zip have both patches as well. Microsoft Windows XP [Version 5.1.2600] generating test file... running vanilla... start:0,531000 total:11,469000 running patched... start:0,546000 total:11,328000 running double patched... start:0,516000 total:5,266000 Microsoft Windows [Version 6.1.7601] generating test file... running vanilla... start:0,546000 total:9,578000 running patched... start:0,546000 total:2,698000 running double patched... start:0,546000 total:0,812000 Microsoft Windows [Version 10.0.17134.165] generating test file... running vanilla... start:0.547000 total:5.125000 running patched... start:0.515000 total:1.828000 running double patched... start:0.532000 total:0.813000 Measured on the same machine (a quadruple boot Lenovo X220). Thanks to this discussion I have also doubled the upload speed in my iOS app. The 274MB mp4 file uploaded now in 70 seconds in stead of 2:25 minutes: https://github.com/NMSSH/NMSSH/pull/136#issuecomment-412398204 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Jelinski via curl-library (Fri, 10 Aug 2018 22:59:22 +0200): >Ok, so let's put Linux to a test. Reality check from a CentOS 6 machine % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 274M0 0 100 274M 0 667k 0:07:00 0:07:00 --:--:-- 667k start:0.191403 total:420.697969 >0. Patch CURL: -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE +#define UPLOAD_BUFSIZE (512*1024) % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 274M0 0 100 274M 0 1297k 0:03:36 0:03:36 --:--:-- 1297k start:0.230242 total:216.560168 If I use lftp on the target Windows 2008 R2 machine to get the file from the CentOS 6 machine: c:\>ptime bash /utils/pcx6get.sh um001348.opt.mp4 === bash /utils/pcx6get.sh um001348.opt.mp4 === Execution time: 13.201 s rsync running on the target Windows 2008 R2 server, syncing from the CentOS, is even a tiny bit faster: 287754814 100% 23.35MB/s0:00:11 (xfer#1, to-check=0/1) sent 30 bytes received 287790026 bytes 23023204.48 bytes/sec total size is 287754814 speedup is 1.00 Execution time: 12.183 s -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Sat, 11 Aug 2018, Daniel Jeliński wrote: I like that; if we had the sftp_write function acknowledge data as soon as it is put in socket buffer, we could get much faster transfers. In order to avoid errors we would need to wait for all outstanding acks on file close. Something like that, sure. It would require that libssh2 provides such an API, which it currently doesn't (and I don't know anyone working on it). I still haven't checked what libssh provides or how it performs in comparison. -- / daniel.haxx.se--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
pt., 10 sie 2018 o 23:08 Daniel Stenberg napisał(a): > [...] libssh2 could offer a better API that's more suited to send (and > receive) SFTP data. I like that; if we had the sftp_write function acknowledge data as soon as it is put in socket buffer, we could get much faster transfers. In order to avoid errors we would need to wait for all outstanding acks on file close. We would lose the opportunity to retry errors without rewinding, but according to [1] the only error we would want to retry is lost connection, and other protocols already rewind in that case. What do you think? [1] https://winscp.net/eng/docs/sftp_codes --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Fri, 10 Aug 2018, Daniel Jeliński via curl-library wrote: TCP window is not a problem, and SSH window doesn't seem to be the problem either. There is definitely still some room for improvement. Absolutely. For example, one fundamental piece that is a rather tough obstacle is the fact that curl drains the upload buffer completely before it fills it up again. That means that all the fancy pipelining logic works fine all up until the point for when reaching the end of the buffer. Then when the final piece of the buffer is sent (and acked) it refills the 512KB buffer again and fires off a huge amount of data split up in many packages. So there's still this bottle neck for every buffer-size. A "sliding buffer" approach or similar would be much more efficient there so there always be a full RTT worth of data in progress. Alternatively, libssh2 could offer a better API that's more suited to send (and receive) SFTP data. -- / daniel.haxx.se--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Ok, so let's put Linux to a test. 0. Patch CURL: #define UPLOAD_BUFSIZE (1<<19) 1. Create a large file. 1 TB looks good: dd if=/dev/zero of=testfile bs=1 count=0 seek=1T The file is sparse, so disk operations won't block us. 2. Upload to /dev/null: curl -u user:pass -k sftp://127.0.0.1/dev/null -T testfile % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 1024G0 00 576M 0 34.5M 8:26:28 0:00:16 8:26:12 31.6M^C Interrupted after a few sec. 30-40MB/sec, decent speed. Curl uses 100% CPU, SSHD uses 60%. 3. Add some latency: sudo tc qdisc add dev lo root netem delay 40ms (note: this latency is only half RTT, so in this case RTT=80ms 4. Repeat test: % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 1024G0 00 608M 0 14.8M 19:36:56 0:00:40 19:36:16 15.1M^C Very stable speed, 15.1-15.3MB/s. Curl uses 60% CPU, SSHD uses 30%. 4a. optionally inspect traffic: sudo tcpdump -i lo -w dump tcp port 22 View results: tcpdump -r dump | less note: tcpdump doesn't play well with emulated delays, so reading the dump is tricky. 5. Clean up sudo tc qdisc del dev lo root netem TCP window is not a problem, and SSH window doesn't seem to be the problem either. There is definitely still some room for improvement. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt via curl-library (Fri, 10 Aug 2018 17:25:51 +0200): >running curl-mingw64 sftp > % Total% Received % Xferd Average Speed TimeTime Time Current > Dload Upload Total SpentLeft Speed >100 274M0 0 100 274M 0 298k 0:15:42 0:15:42 --:--:-- 313k >100 274M0 0 100 274M 0 298k 0:15:42 0:15:42 --:--:-- 298k >start:0,64 total:942,153000 Gisle sent me a link to his monolitic compiled version. About the same speed with my 274MB mp4 file: running curl-monolitic sftp % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 274M0 0 100 274M 0 292k 0:16:00 0:16:00 --:--:-- 299k 100 274M0 0 100 274M 0 292k 0:16:00 0:16:00 --:--:-- 292k start:0,468000 total:960,763000 Too bad. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt via curl-library (Fri, 10 Aug 2018 03:29:21 +0200):
>Gisle Vanem via curl-library (Thu, 9 Aug 2018 18:31:12 +0200):
>>Jan Ehrhardt wrote:
>>
Wow dude! 2 times faster than FileZilla now.
Time decreased from 33.153s to 6.4 sec (same random 10 MByte file).
Versus approx. 5.3 sec for curl/FTP.
>>>
>>> Using SFTP?
>>
>>Yes:
>>curl.exe -k -# --write-out "speed: %%{speed_upload} bytes/sec, total-time:
>>%%{time_total}" ^
>> sftp://xyz -T c:\TEMP\curl-test.file
>>speed: 1649348,000 bytes/sec, total-time: 6,063000
>
>Can you make your compiled version available somewhere? I tried different
>combinations of VC9, VC11, VC14 and x86 / x64 and cannot get it higher than
>300k
>at the moment.
I even cross-compiled curl.exe with GCC 7.3.1 on a Ubuntu 16.04 machine, linking
libssh2 1.8.0 (also compiled with GCC 7.3.1):
https://phpdev.toolsforresearch.com/curl-mingw32-7.61.0.zip
It has both patches: the winsock patch and the sftp uploadbuffer one. Uploading
over sftp went up from 145k to about 300KB/s, but nowhere near the 4+ MB/s of
the other methods.
Interesting about the cross-compiled versions: they include a static OpenSSL
1.0.2o module (also cross-compiled by GCC), that somehow reads the system
certificate store of the Windows machines.
--
Jan
Microsoft Windows [Version 6.1.7601]
running lftp
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== E:\utils\bash.exe /utils/bash.sh ===
Execution time: 69.934 s
running vanilla...
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" (removed)
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 5062k 0:00:55 0:00:55 --:--:-- 5200k
start:0,39 total:55,506000
Execution time: 55.667 s
running patched...
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" (removed)
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 6825k 0:00:41 0:00:41 --:--:-- 6231k
start:0,375000 total:41,169000
Execution time: 41.320 s
running curl-mingw64 patched...
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" (removed)
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 6550k 0:00:42 0:00:42 --:--:-- 6043k
start:0,374000 total:42,90
Execution time: 43.048 s
running curl-mingw64 sftp
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" (removed)
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 298k 0:15:42 0:15:42 --:--:-- 313k
100 274M0 0 100 274M 0 298k 0:15:42 0:15:42 --:--:-- 298k
start:0,64 total:942,153000
Execution time: 942.211 s
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Gisle Vanem via curl-library (Thu, 9 Aug 2018 18:31:12 +0200):
>Jan Ehrhardt wrote:
>
>>> Wow dude! 2 times faster than FileZilla now.
>>>
>>> Time decreased from 33.153s to 6.4 sec (same random 10 MByte file).
>>> Versus approx. 5.3 sec for curl/FTP.
>>
>> Using SFTP?
>
>Yes:
>curl.exe -k -# --write-out "speed: %%{speed_upload} bytes/sec, total-time:
>%%{time_total}" ^
> sftp://xyz -T c:\TEMP\curl-test.file
>speed: 1649348,000 bytes/sec, total-time: 6,063000
Can you make your compiled version available somewhere? I tried different
combinations of VC9, VC11, VC14 and x86 / x64 and cannot get it higher than 300k
at the moment.
--
Jan
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt wrote:
Wow dude! 2 times faster than FileZilla now.
Time decreased from 33.153s to 6.4 sec (same random 10 MByte file).
Versus approx. 5.3 sec for curl/FTP.
Using SFTP?
Yes:
curl.exe -k -# --write-out "speed: %%{speed_upload} bytes/sec, total-time:
%%{time_total}" ^
sftp://xyz -T c:\TEMP\curl-test.file
speed: 1649348,000 bytes/sec, total-time: 6,063000
--
--gv
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Gisle Vanem via curl-library (Thu, 9 Aug 2018 17:48:49 +0200): >Daniel Stenberg wrote: > >> /* The upload buffer size, should not be smaller than CURL_MAX_WRITE_SIZE, >> as >> it needs to hold a full buffer as could be sent in a write callback */ >> -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE >> +#define UPLOAD_BUFSIZE (512*1024) > >Wow dude! 2 times faster than FileZilla now. > >Time decreased from 33.153s to 6.4 sec (same random 10 MByte file). >Versus approx. 5.3 sec for curl/FTP. Using SFTP? -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg via curl-library (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)): >On Thu, 9 Aug 2018, Jan Ehrhardt via curl-library wrote: > >> curl plain ftp patched 41 seconds >> curl patched sftp 1925 seconds > >Oh what a sad number there... =( > >A quick little experiment could be to try upping the upload buffer size >significantly: snip patch Patch applied. On another connection (slower than back at home) it now reports % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 274M0 0 100 274M 0 871k 0:05:22 0:05:22 --:--:-- 900k 100 274M0 0 100 274M 0 871k 0:05:22 0:05:22 --:--:-- 871k 322 seconds. Lot faster. -- Jant --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg wrote: /* The upload buffer size, should not be smaller than CURL_MAX_WRITE_SIZE, as it needs to hold a full buffer as could be sent in a write callback */ -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE +#define UPLOAD_BUFSIZE (512*1024) Wow dude! 2 times faster than FileZilla now. Time decreased from 33.153s to 6.4 sec (same random 10 MByte file). Versus approx. 5.3 sec for curl/FTP. -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Thu, 9 Aug 2018, Jan Ehrhardt via curl-library wrote: curl plain ftp patched 41 seconds curl patched sftp 1925 seconds Oh what a sad number there... =( A quick little experiment could be to try upping the upload buffer size significantly: diff --git a/lib/urldata.h b/lib/urldata.h index 7d396f3f2..ccfe83b3b 100644 --- a/lib/urldata.h +++ b/lib/urldata.h @@ -142,11 +142,11 @@ typedef ssize_t (Curl_recv)(struct connectdata *conn, /* connection data */ #include #endif /* HAVE_LIBSSH2_H */ /* The upload buffer size, should not be smaller than CURL_MAX_WRITE_SIZE, as it needs to hold a full buffer as could be sent in a write callback */ -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE +#define UPLOAD_BUFSIZE (512*1024) /* The "master buffer" is for HTTP pipelining */ #define MASTERBUF_SIZE 16384 /* Initial size of the buffer to store headers in, it'll be enlarged in case -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Gisle Vanem via curl-library (Thu, 9 Aug 2018 13:51:50 +0200):
>Jan Ehrhardt wrote:
>
>>> 33.153s vs 5.4s for a 10 MByte file.
>>
>> Did you time how long Filezilla takes for the same action? Filezilla
>> squeezes quite a lot over sftp-connections...
>
>11.4 sec!!
snip
>I must be using the wrong compiler and SSL-lib :-)
>But, it's certainly possible to make SFTP faster.
Same results here. Yesterday I had a discussion with a customer, uploading
a 274MB file from an iPad over sftp. That took 2:27 minutes. I repeated the
upload now with Filezilla, lftp and curl
TL;DR
iPad sftp (NMSSH2) 147 seconds
Filezilla sftp 67 seconds
lftp sftp70 seconds
curl plain ftp vanilla 56 seconds
curl plain ftp patched 41 seconds (the 2nd is my own compiled version: 42s)
curl patched sftp 1925 seconds
--
Jan
Microsoft Windows [Version 6.1.7601]
running lftp
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== E:\utils\bash.exe /utils/bash.sh ===
Execution time: 70.587 s
running vanilla...
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" removed
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 4982k 0:00:56 0:00:56 --:--:-- 4960k
start:0,374000 total:56,394000
Execution time: 56.547 s
running patched...
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" removed
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 6812k 0:00:41 0:00:41 --:--:-- 6420k
start:0,375000 total:41,247000
Execution time: 41.408 s
running curl patched...
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" removed
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 6617k 0:00:42 0:00:42 --:--:-- 6923k
start:0,374000 total:42,463000
Execution time: 42.699 s
running patched sftp
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
=== curl -w"start:%{time_starttransfer} total:%{time_total}\n" removed
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 274M0 0 100 274M 0 145k 0:32:05 0:32:05 --:--:-- 150k
100 274M0 0 100 274M 0 145k 0:32:05 0:32:05 --:--:-- 145k
start:0,421000 total:1925,349000
Execution time: 1925.451 s
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt wrote: 33.153s vs 5.4s for a 10 MByte file. Did you time how long Filezilla takes for the same action? Filezilla squeezes quite a lot over sftp-connections... 11.4 sec!! From the "About" box: Version: 3.31.0 Build information: Compiled for: x86_64-w64-mingw32 Compiled with: x86_64-w64-mingw32-gcc (GCC) 6.3.0 20170516 Compiler flags: -g -O2 -Wall GnuTLS: 3.5.18 CPU features: sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2 aes pclmulqdq rdrnd bmi2 bmi2 I must be using the wrong compiler and SSL-lib :-) But, it's certainly possible to make SFTP faster. -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Gisle Vanem via curl-library (Thu, 9 Aug 2018 01:42:18 +0200): >Jan Ehrhardt wrote: > >> I ended up with a Windows port of lftp, launched from a bash script. Curl >> sftp >> did resume, but was terribly slow. > >I also just tested with 'curl sftp//:' with the latest libssh2 >and the new 'SIO_IDEAL_SEND_BACKLOG_QUERY' option. 'sftp://' is >still 6 times slower than ftp against the same server in Denmark. > >33.153s vs 5.4s for a 10 MByte file. Did you time how long Filezilla takes for the same action? Filezilla squeezes quite a lot over sftp-connections... -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Thu, 9 Aug 2018, Daniel Jeliński via curl-library wrote: There's no way for curl/libssh2 to put more than 16 KB on the wire. It's right there in libssh2 docs [1]: [libssh2_sftp_write] will return a positive number as soon as the first packet is acknowledged from the server. That's incorrect. libssh2 sends off many separate packets at the same time (if given the opportunity) and will return data as soon as the *first* packet is acked, so if you keep sending large data buffers there will be more outstanding and you can get much faster speeds. Since sftp packets are up to 32 KB, and curl is using 16KB send buffer, the buffer always fits in one packet and the function always waits for acknowledgement before returning. So your transfer rate will never exceed 16 KB / ping. Yes, and I've actually explained this architecture issue on this list many times before. SFTP is a rather particular protocol, and libssh2's API for it isn't ideal which makes curl suffer. (I blogged about it once over here: https://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers-fast/) It seems relatively easy to change the procedure to get rid of this write-through semantics. Not sure if the project is still actively maintained though, its mailing list [2] looks very quiet. It's active allright (as opposed to dead) but during periods not a lot of things happen. Mostly just because of a lack of developers (and partly because I can't really keep up being a good maintainer of it)... I didn't check curl with libssh backend, it may be worth a try. It may! I haven't looked into the libssh SFTP specifics for a long time. Hopefully they've solved these challenges better! -- / daniel.haxx.se--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-09 1:42 GMT+02:00 Gisle Vanem via curl-library : > I also just tested with 'curl sftp//:' with the latest libssh2 > and the new 'SIO_IDEAL_SEND_BACKLOG_QUERY' option. 'sftp://' is > still 6 times slower than ftp against the same server in Denmark. > > 33.153s vs 5.4s for a 10 MByte file. There's no way for curl/libssh2 to put more than 16 KB on the wire. It's right there in libssh2 docs [1]: [libssh2_sftp_write] will return a positive number as soon as the first packet is acknowledged from the server. Since sftp packets are up to 32 KB, and curl is using 16KB send buffer, the buffer always fits in one packet and the function always waits for acknowledgement before returning. So your transfer rate will never exceed 16 KB / ping. It seems relatively easy to change the procedure to get rid of this write-through semantics. Not sure if the project is still actively maintained though, its mailing list [2] looks very quiet. I didn't check curl with libssh backend, it may be worth a try. [1] https://www.libssh2.org/libssh2_sftp_write.html [2] https://www.libssh2.org/mail.cgi --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt wrote: I ended up with a Windows port of lftp, launched from a bash script. Curl sftp did resume, but was terribly slow. I also just tested with 'curl sftp//:' with the latest libssh2 and the new 'SIO_IDEAL_SEND_BACKLOG_QUERY' option. 'sftp://' is still 6 times slower than ftp against the same server in Denmark. 33.153s vs 5.4s for a 10 MByte file. -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Wed, 8 Aug 2018, Daniel Stenberg via curl-library wrote: Right, that's a valid remark. But let's address that issue if/when someone actually gets a problem with it... Merged now! -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Mon, 6 Aug 2018, Daniel Jeliński wrote: Well I guess the overhead of WSAIoCtl or setsockopt may be non-negligible for fast connections. I can't reproduce this here, can't find a network with low enough bandwidth-delay product. On high BDP the patched version is consistently faster. Should we proceed and merge https://github.com/curl/curl/pull/2762 or is there anything else we should check first? The patch seems to significantly improve a lot of transfers and so far we've only seen one case out of 30+ that got worse performance. -- / daniel.haxx.se--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel wrote... Ok, so I installed Win 10 on Virtualbox 5.2.16 on my machine and I can confirm Jan's findings; in NAT mode the ideal backlog stays flat at 64 KB, and the patch provides no benefits. Once I switched to "Bridged adapter", I got normal results (as in, similar to what other people reported): Looking at the source code for VirtualBox it appears that the NAT mode is built on top of lwIP 1.4.1 so the limitation may come from there. I chat with the VirtualBox devs on IRC from time to time and am happy to ask them specific questions if it would help. -Andy. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-05 10:01 GMT+02:00 Andy Pont : > VirtualBox 5.0.16 was released in March 2016 and so it two years out of date > and is unsupported by Oracle. The current version is 5.2.16. If possible > you should try upgrading and seeing if you get the same results. Ok, so I installed Win 10 on Virtualbox 5.2.16 on my machine and I can confirm Jan's findings; in NAT mode the ideal backlog stays flat at 64 KB, and the patch provides no benefits. Once I switched to "Bridged adapter", I got normal results (as in, similar to what other people reported): Microsoft Windows [Version 10.0.17134.112] generating test file... running vanilla... start:0.687000 total:6.062000 running patched... start:0.625000 total:2.407000 Looks like a limitation of VirtualBox's NAT mode. Regards, Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Sat, 4 Aug 2018, Jan Ehrhardt wrote: curl was consistently a little bit faster than bash/lftp, but that may be related to the sftp encryption (curl ran plain ftp, port 21). curl vanilla and curl patched did not seem to differ. Sometimes patched was faster than vanilla, sometimes the other way around. @Daniel Jelinski: could you compile a version with sftp support? curl's SFTP performance is however known to not be optimal - so I consider that to be a poor protocol choice to check for TCP/winsock performance. I think keeping it as plain TCP as possible (HTTP or FTP basically) helps keeping the comparisons as relevant as possible. But I used HTTPS from my windows box and that also showed a huge difference with the patched version. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt wrote:
Timed by
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
I tried this tool too, as (inside a 'upload-speed.bat'):
ptime.exe -- curl.exe -# --output - -w"speed:%%{speed_upload} bytes/sec\n"
%URL% -T %TEST_FILE%
But always got things like:
-=O=- # # # #
speed:0,000curl: (6) Could not resolve host: bytes
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: " to save to a file.
speed:0,000time: elapsed: 3203ms, kernel: 203ms, user: 46ms
w/o, ptime, curl has no complains.
How did you use ptime for curl? And under bash (I use 4nt)?
I ended up with:
ptime -- upload-speed.bat
--
--gv
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Jeli?ski in gmane.comp.web.curl.library (Sat, 4 Aug 2018 19:52:37 +0200): >2018-08-04 15:55 GMT+02:00 Jan Ehrhardt : >> Virtualbox 5.0.16. Network adapter screenshot here: >> https://phpdev.toolsforresearch.com/win7x64.png > >Thanks. Do you happen to limit allowed bandwidth of these VMs? >VirtualBox allows this, as described here: >https://stackoverflow.com/a/8124491/7707617 No, AFAIK. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Jeli?ski in gmane.comp.web.curl.library (Sat, 4 Aug 2018 19:40:01 +0200): >I haven't figured out yet how to build libssh2, and I don't need it at >the moment. https://windows.php.net/downloads/php-sdk/deps/vc15/x64/ (or whatever VC and x-version you are using). The libssh_a.lib inside the libssh2-1.8.0-vc15-x64.zip is the static version without dependent dll's. I'd like to test the sftp-speed, because sftp can do a resume. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt in gmane.comp.web.curl.library (Sat, 04 Aug 2018 18:30:56 +0200): >Jan Ehrhardt in gmane.comp.web.curl.library (Sat, 04 Aug 2018 18:14:29 +0200): >>curl vanilla: 5.248 s >>curl patched: 5.471 s > >I will repeat the tests later over my fiber connaction. Over a fast connection (plain FTP upload) the patched version is consistently slower. Done with a 194MB mp4 file (in stead of the 1 MB test file): Microsoft Windows [Version 6.1.7601] % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 194M0 0 100 194M 0 7037k 0:00:28 0:00:28 --:--:-- 6527k start:0,359000 total:28,345000 running patched... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 194M0 0 100 194M 0 6517k 0:00:30 0:00:30 --:--:-- 6554k start:0,374000 total:30,607000 Every result was 28 seconds versus 30 seconds. FWIW: this is with a 1 Gbit/s network cable connection to my Fritzbox, behind a 50 Mbit/s up and down fiber connection. 194MB is 20 seconds is faster than the spacs of my connection. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-04 15:55 GMT+02:00 Jan Ehrhardt : > Virtualbox 5.0.16. Network adapter screenshot here: > https://phpdev.toolsforresearch.com/win7x64.png Thanks. Do you happen to limit allowed bandwidth of these VMs? VirtualBox allows this, as described here: https://stackoverflow.com/a/8124491/7707617 Your results for Windows 10 on these VMs are almost the same as older Windows versions. Your non-VM test reports roughly doubled speed on Windows 10 compared to older systems, which leads me to suspect that something else might be limiting your speed there. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-04 18:14 GMT+02:00 Jan Ehrhardt : > curl was consistently a little bit faster than bash/lftp, but that may be > related to the sftp encryption (curl ran plain ftp, port 21). > curl vanilla and curl patched did not seem to differ. Sometimes patched was > faster than vanilla, sometimes the other way around. > > @Daniel Jelinski: could you compile a version with sftp support? I haven't figured out yet how to build libssh2, and I don't need it at the moment. Out of curiosity, I run some tests of SFTP using curl binaries by Viktor Szakats [1] and some ancient CopSSH server. Uploads to localhost were capped at ~300 KB/s. WinSCP was able to upload to the same server at a rate of 4MB/s, maxing out one entire CPU in the process (server used about 15% of another one), so Curl seems a little unimpressive here. On linux Curl uploaded to localhost (OpenSSH + sftp) at a rate of 15 MB/s, using 60% of a single CPU (server used ~30% of another one). Tried both libssh and libssh2, didn't notice a difference. This result is much better, but there may still be some room for improvement. Regards, Daniel [1] https://bintray.com/vszakats/generic/curl/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Jan Ehrhardt in gmane.comp.web.curl.library (Sat, 04 Aug 2018 18:14:29 +0200): >bash / lftp : 5.660 s >curl vanilla: 5.248 s >curl patched: 5.471 s Disclaimer: these times are over a Wifi connection at http://drovers-dog.com/dog1/ I will repeat the tests later over my fiber connaction. -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Jelinski (Sat, 4 Aug 2018 08:02:00 +0200):
>I'm a little concerned about Gisle's FTP results and Jan's results on
>Virtualbox. I don't think they should block this patch, but they may
>justify some further enhancements.
Once upon a time I tested a lot of upload tools to see which one suited my
requirements best. These requirements were:
1. Speedy upload of 200MB files
2. Possibility to resume an interrupted transfer
3. Secure
I ended up with a Windows port of lftp, launched from a bash script. Curl sftp
did resume, but was terribly slow. Curl ftps was fast, but did not resume.
WinSCP did not resume, because of rename restrictions on the FTP server.
Today, I compared the speed once again with the 1 MB test file.
Results: curl patched was not faster than curl vanilla.
I used ptime to time the execution, because bash/lftp did not have one of its
own. Example run:
bash / lftp : 5.660 s
curl vanilla: 5.248 s
curl patched: 5.471 s
curl was consistently a little bit faster than bash/lftp, but that may be
related to the sftp encryption (curl ran plain ftp, port 21).
curl vanilla and curl patched did not seem to differ. Sometimes patched was
faster than vanilla, sometimes the other way around.
@Daniel Jelinski: could you compile a version with sftp support?
Microsoft Windows [Version 6.1.7601]
generating test file...
running lftp
== E:\utils\bash.exe /utils/bash.sh ===
Execution time: 5.660 s
running vanilla...
== curl -w"start:%{time_starttransfer} total:%{time_total}\n" -C - -k (removed)
** Resuming transfer from byte position -1
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 1023k0 0 100 1023k 0 207k 0:00:04 0:00:04 --:--:-- 227k
start:0,577000 total:4,945000
Execution time: 5.248 s
running patched...
== curl -w"start:%{time_starttransfer} total:%{time_total}\n" -C - -k (removed)
** Resuming transfer from byte position -1
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 1023k0 0 100 1023k 0 197k 0:00:05 0:00:05 --:--:-- 224k
start:0,733000 total:5,179000
Execution time: 5.471 s
Timed by
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes
--
Jan
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Jeli?ski in gmane.comp.web.curl.library (Sat, 4 Aug 2018 07:53:24 +0200): >2018-08-03 4:07 GMT+02:00 Jan Ehrhardt : >>>I also have a Windows 8.1 64-bits running in a Virtualbox on the Wondows >>>2008 R2 server. No speed improvement. Most of the times the patched >>>version is a little bit faster, but sometimes even slower. Typical >>>result below. >>> >> The same happens with other Windows versions in a Virtualbox (on the >> Win2k8 server). > >That one is disturbing. Wonder if this happens because ideal send >buffer query fails under virtualbox, or if it returns bogus values >(like 8 KiB). Which version of Virtualbox is that? How did you set up >the network adapter? I'd like to try and reproduce this here. Virtualbox 5.0.16. Network adapter screenshot here: https://phpdev.toolsforresearch.com/win7x64.png -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Hello! Please note that we would *love* your assistance here if you're a Windows user and can offer a few moments of your time to run a few tests on a few Windows versions and tell us the outcome! Here's a simple way to help us make curl better without doing any coding at all! =) We want to have more user's experience and results from tests to determine how we should make curl make uploads on windows as fast as possible. See Daniel's mail below for details. Please report your results to the list, to me or to Daniel Jeliński and we can make a summary in a few days. Looks good. 200/15 MBit cable connection. Windows XP Professional SP3: Microsoft Windows XP [Version 5.1.2600] generating test file... running vanilla... start:0.734000 total:10.671000 running patched... start:0.563000 total:10.157000 Windows 7 Professional SP1: Microsoft Windows [Version 6.1.7601] generating test file... running vanilla... start:0.546000 total:10.109000 running patched... start:0.53 total:2.621000 --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Jeliński wrote: Besides the 'test' data-file gives the wrong picture under a VPN-connection. With PPTP/L2TP compression I believe VPN operates on a lower level than TCP, so send buffer usage will not be affected by VPN compression. But you could see speeds faster than what your ISP advertises, which is kind of nice. Some VPN uses UDP (IPsec, port 4500) and the send-buffer Winsock provides to them. So maybe this generator command gives a better picture: openssl rand -out %TEMP%\curl-test 1048448 But I guess we cannot assume everybody have OpenSSL installed. -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Sat, Aug 4, 2018 at 2:06 AM, Daniel Jeliński wrote: > 2018-08-03 22:47 GMT+02:00 Daniel Stenberg : > > On Fri, 3 Aug 2018, Ray Satiro wrote: > > This is strange. I see Ray's mail in the archives [1] but not in my > mailbox. On the other hand, I don't see Rickard Alcock's reply in the > archives, but I have it in my mailbox. What gives? > Gmail dropped Ray's message in my Spam folder with this note: "This message has a from address in yahoo.com but has failed yahoo.com's required tests for authentication" Ralph Mitchell --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-04 8:06 GMT+02:00 Daniel Jeliński : > 2018-08-03 22:47 GMT+02:00 Daniel Stenberg : >> On Fri, 3 Aug 2018, Ray Satiro wrote: > > This is strange. I see Ray's mail in the archives [1] but not in my > mailbox. On the other hand, I don't see Rickard Alcock's reply in the > archives, but I have it in my mailbox. What gives? > > [1]https://curl.haxx.se/mail/lib-2018-08/ Found Ray's mail. GMail sent it to spam complaining about missing yahoo authorization. I guess I need to check spam folder more often... --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-03 22:47 GMT+02:00 Daniel Stenberg : > On Fri, 3 Aug 2018, Ray Satiro wrote: This is strange. I see Ray's mail in the archives [1] but not in my mailbox. On the other hand, I don't see Rickard Alcock's reply in the archives, but I have it in my mailbox. What gives? [1]https://curl.haxx.se/mail/lib-2018-08/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-03 18:11 GMT+02:00 Daniel Stenberg : > https://docs.google.com/spreadsheets/d/1xAntVPAggz9gvx7TI_vUF6G6titRAX5tBOZv0JCXkNY/edit?usp=sharing Thank you everyone for providing results, thank you Daniel for keeping tabs on them. Most of the results are in line with my expectations: - results from vanilla under Windows 10 are better than older systems, which is in line with what Christian reported about larger default send buffer. It's nice to see that the patch still improves the outcome there. - Results on XP and 2003 are almost the same with and without patch, which was to be expected as ideal buffer query was only implemented in Vista SP1. I'm a little concerned about Gisle's FTP results and Jan's results on Virtualbox. I don't think they should block this patch, but they may justify some further enhancements. Thanks again! Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-02 21:33 GMT+02:00 Gisle Vanem : > Testing with the same > file via ftp to my server in Denmark (11 hops) shows a > bit worse result: > running vanilla... > start:0,406000 total:1,219000 > running patched... > start:0,359000 total:1,531000 > > Seems ftp is maxing my line here. Maybe little to do with > Winsock tuning. FTP is a tricky beast. If the results are repeatable, I'd love to take another look. > Besides the 'test' data-file gives the wrong picture under > a VPN-connection. With PPTP/L2TP compression I believe VPN operates on a lower level than TCP, so send buffer usage will not be affected by VPN compression. But you could see speeds faster than what your ISP advertises, which is kind of nice. Thanks for your testing! Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
2018-08-03 4:07 GMT+02:00 Jan Ehrhardt : >>I also have a Windows 8.1 64-bits running in a Virtualbox on the Wondows >>2008 R2 server. No speed improvement. Most of the times the patched >>version is a little bit faster, but sometimes even slower. Typical >>result below. >> > The same happens with other Windows versions in a Virtualbox (on the > Win2k8 server). That one is disturbing. Wonder if this happens because ideal send buffer query fails under virtualbox, or if it returns bogus values (like 8 KiB). Which version of Virtualbox is that? How did you set up the network adapter? I'd like to try and reproduce this here. Thank you, Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Fri, 3 Aug 2018, Ray Satiro wrote: 2. Windows Vista SP2, USA, NYC: Microsoft Windows [Version 6.0.6002] generating test file... running vanilla... start:0.484000 total:15.234000 running patched... start:0.453000 total:2.234000 Yikes! At 28 reported numbers, this is the largest improvement we've seen so far. Almost 7 times faster! -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On 8/2/2018 8:52 AM, Daniel Stenberg wrote: > Please note that we would *love* your assistance here if you're a > Windows user and can offer a few moments of your time to run a few > tests on a few Windows versions and tell us the outcome! Here's a > simple way to help us make curl better without doing any coding at > all! =) > > We want to have more user's experience and results from tests to > determine how we should make curl make uploads on windows as fast as > possible. > > See Daniel's mail below for details. Please report your results to the > list, to me or to Daniel Jeliński and we can make a summary in a few > days. > > -- > > / daniel.haxx.se > > -- Forwarded message -- > Date: Wed, 1 Aug 2018 16:38:02 > From: Daniel Jeliński > Reply-To: libcurl development > To: libcurl development > Subject: Re: Slow Windows uploads (with patch) > > 2018-07-30 18:09 GMT+02:00 Daniel Stenberg : >> The tool could try upload with and without "the patch" to one/two/three >> places and report the results with the exact Windows version used. We >> could >> ask curl users to report *their* results and we collect the results in a >> sheet somewhere. > > How about a CURL build? I built curl binaries with and without the > patch, which users could use for testing on their machines. These are > available for download here: > https://www.dropbox.com/s/5i2a2bth2ea28ys/curl.zip > > Running test is as simple as unpacking and launching testcurl.bat, > with possible extra step of installing MSVC 2010 redistributable. The tests below were all done wired to a router to a cable modem. I ran the test on each OS several times and the results were very close each time, no outliers. 1. Windows XP SP3, USA, NYC: Microsoft Windows XP [Version 5.1.2600] generating test file... running vanilla... start:0.453000 total:7.703000 running patched... start:0.468000 total:7.656000 Press any key to continue . . . 2. Windows Vista SP2, USA, NYC: Microsoft Windows [Version 6.0.6002] generating test file... running vanilla... start:0.484000 total:15.234000 running patched... start:0.453000 total:2.234000 Press any key to continue . . . 3. Windows Server 2008 R2 SP1, USA, NYC: Microsoft Windows [Version 6.1.7601] generating test file... running vanilla... start:0.453000 total:8.125000 running patched... start:0.453000 total:2.203000 Press any key to continue . . . 3. Windows 7 SP1 Enterprise, USA, NYC: Microsoft Windows [Version 6.1.7601] generating test file... running vanilla... start:0.453000 total:8.175000 running patched... start:0.421000 total:2.106000 Press any key to continue . . . 4. Windows 8 (original), USA, NYC: Microsoft Windows [Version 6.3.9600] generating test file... running vanilla... start:0.453000 total:4.718000 running patched... start:0.453000 total:2.031000 Press any key to continue . . . 5. Windows 10, 1607, USA, NYC: Microsoft Windows [Version 10.0.14393] generating test file... running vanilla... start:0.453000 total:4.281000 running patched... start:0.453000 total:1.594000 Press any key to continue . . . 6. Windows 10, 1709, USA, NYC: Microsoft Windows [Version 10.0.16299.309] generating test file... running vanilla... start:0.453000 total:4.281000 running patched... start:0.422000 total:1.484000 Press any key to continue . . . --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Fri, 3 Aug 2018, Daniel Stenberg wrote: With 14 results so far the patch keeps proving itself a good idea: https://docs.google.com/spreadsheets/d/1xAntVPAggz9gvx7TI_vUF6G6titRAX5tBOZv0JCXkNY/edit?usp=sharing At 21 results, the numbers don't move much. The patched version needs on average 53.60% of the time of the vanilla version. The median improved patch time among the reported numbers is at 44.53%: a more than doubled speed. Still only one report of notable worse numbers with the patch. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Windows users! Help us test upload performance tuning?
From Cambridge, UK Microsoft Windows [Version 10.0.15063] generating test file... running vanilla... start:0.64 total:4.578000 running patched... start:0.469000 total:1.907000 -- Richard -Original Message- From: curl-library On Behalf Of Daniel Stenberg Sent: Friday, August 3, 2018 11:00 AM To: libcurl development Subject: Re: Windows users! Help us test upload performance tuning? On Thu, 2 Aug 2018, Gisle Vanem wrote: > But that server is 19 hops away. Testing with the same file via ftp to > my server in Denmark (11 hops) shows a bit worse result: > running vanilla... > start:0,406000 total:1,219000 > running patched... > start:0,359000 total:1,531000 It would probably be valuable if a few others also tried this over FTP as well, to figure out if Gisle's numbers here stand out due to FTP or for other reasons. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Thu, 2 Aug 2018, Gisle Vanem wrote: But that server is 19 hops away. Testing with the same file via ftp to my server in Denmark (11 hops) shows a bit worse result: running vanilla... start:0,406000 total:1,219000 running patched... start:0,359000 total:1,531000 It would probably be valuable if a few others also tried this over FTP as well, to figure out if Gisle's numbers here stand out due to FTP or for other reasons. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Thu, 2 Aug 2018, Daniel Stenberg wrote: We want to have more user's experience and results from tests to determine how we should make curl make uploads on windows as fast as possible. I've added all the results received so far into a google docs sheet avialble for viewing on the link below. With 14 results so far the patch keeps proving itself a good idea: https://docs.google.com/spreadsheets/d/1xAntVPAggz9gvx7TI_vUF6G6titRAX5tBOZv0JCXkNY/edit?usp=sharing -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Hello Daniel, I fired up a Windows 2016 instance in Canada using AWS. First thing I got was an error message MSVCR100.dll is missing. So I installed the visual c++ runtime. And tried again. Microsoft Windows [Version 10.0.14393] generating test file... running vanilla... start:0.469000 total:3.422000 running patched... start:0.391000 total:1.844000 Cheers, Thomas --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Windows users! Help us test upload performance tuning?
>>Jan Ehrhardt's XP test was really slow and if we exclude that from the >>results, the average patched result goes down to 46%. Perhaps completely irrelevant and probably already taken into account: Windows (any network performance) may severely suffer from a virus scanner, or if no AV or security product is installed, Microsoft Windows Defender. Also, when Windows is under heavy network load, it behaves much worse than e.g. Linux or other UNIX flavors (worse=less snappier, hiccups etc). --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg (Thu, 2 Aug 2018 23:32:04 +0200 (CEST)): >>Jan Ehrhardt's XP test was really slow and if we exclude that from the >>results, the average patched result goes down to 46%. > >I also have a Windows 8.1 64-bits running in a Virtualbox on the Wondows >2008 R2 server. No speed improvement. Most of the times the patched >version is a little bit faster, but sometimes even slower. Typical >result below. > >Windows 8.1 64-bits in a Virtualbox, Amsterdam, NL > >Microsoft Windows [Version 6.3.9600] >generating test file... >running vanilla... >start:0,578000 total:5,312000 >running patched... >start:0,594000 total:5,219000 The same happens with other Windows versions in a Virtualbox (on the Win2k8 server). Windows 8.1 32 bits Microsoft Windows [Version 6.3.9600] generating test file... running vanilla... start:0,735000 total:5,219000 running patched... start:0,578000 total:5,218000 Windows 10 64 bits Microsoft Windows [Version 10.0.17134.165] generating test file... running vanilla... start:0,562000 total:5,062000 running patched... start:0,562000 total:5,062000 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg (Thu, 2 Aug 2018 23:32:04 +0200 (CEST)): >Jan Ehrhardt's XP test was really slow and if we exclude that from the >results, the average patched result goes down to 46%. I also have a Windows 8.1 64-bits running in a Virtualbox on the Wondows 2008 R2 server. No speed improvement. Most of the times the patched version is a little bit faster, but sometimes even slower. Typical result below. Windows 8.1 64-bits in a Virtualbox, Amsterdam, NL Microsoft Windows [Version 6.3.9600] generating test file... running vanilla... start:0,578000 total:5,312000 running patched... start:0,594000 total:5,219000 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
On Thu, 2 Aug 2018, Gisle Vanem wrote: But that server is 19 hops away. Testing with the same file via ftp to my server in Denmark (11 hops) shows a bit worse result: running vanilla... start:0,406000 total:1,219000 running patched... start:0,359000 total:1,531000 Seems ftp is maxing my line here. Maybe little to do with Winsock tuning. Maybe, still interesting that the patched version turned 25% worse and thereby this is the only test we've seen so far that did so! Even including this test (and we've received 11 numbers so far), the patched version *average* at 51% of the time of the vanilla build. Jan Ehrhardt's XP test was really slow and if we exclude that from the results, the average patched result goes down to 46%. Remarkable improvements! The 11 tests seen so far has been done with these Windows versions: 10.0.16299.547 10.0.17134.112 10.0.17134.165 10.0.17134.191 10.0.17713.1002 5.1.2600 6.1.7601 It would still help with more data - especially if you happen to run other versions or happen to sit on networks far away from the uploadjp.openspeedtest.com server. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Marcel Raad wrote: Microsoft Windows [Version 10.0.16299.547] generating test file... running vanilla... start:0,656000 total:4,844000 running patched... start:0,516000 total:1,797000 Very good improvement on http here: Microsoft Windows [Version 10.0.17134.191] generating test file... running vanilla... start:0,625000 total:5,593000 running patched... start:0,594000 total:2,719000 But that server is 19 hops away. Testing with the same file via ftp to my server in Denmark (11 hops) shows a bit worse result: running vanilla... start:0,406000 total:1,219000 running patched... start:0,359000 total:1,531000 Seems ftp is maxing my line here. Maybe little to do with Winsock tuning. Besides the 'test' data-file gives the wrong picture under a VPN-connection. With PPTP/L2TP compression. -- --gv --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Windows users! Help us test upload performance tuning?
> -Original Message- > From: curl-library On Behalf Of Marcel > Raad > Sent: Donnerstag, 2. August 2018 19:48 > To: libcurl development > Cc: curl users > Subject: RE: Windows users! Help us test upload performance tuning? > > Looks good here (Windows 10 Pro Preview, Germany, 400/20 Mbit/s cable > connection): > > Microsoft Windows [Version 10.0.17713.1002] > generating test file... > running vanilla... > start:0,64 total:6,062000 > running patched... > start:0,609000 total:2,656000 And another machine in another network in Germany, with Windows 10 1709: Microsoft Windows [Version 10.0.16299.547] generating test file... running vanilla... start:0,656000 total:4,844000 running patched... start:0,516000 total:1,797000 Marcel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Windows users! Help us test upload performance tuning?
> -Original Message- > From: curl-library On Behalf Of Daniel > Stenberg > Sent: Donnerstag, 2. August 2018 14:53 > To: libcurl hacking > Cc: curl users > Subject: Windows users! Help us test upload performance tuning? > > Please note that we would *love* your assistance here if you're a Windows > user > and can offer a few moments of your time to run a few tests on a few > Windows > versions and tell us the outcome! Looks good here (Windows 10 Pro Preview, Germany, 400/20 Mbit/s cable connection): Microsoft Windows [Version 10.0.17713.1002] generating test file... running vanilla... start:0,64 total:6,062000 running patched... start:0,609000 total:2,656000 Marcel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg (Thu, 2 Aug 2018 14:52:51 +0200 (CEST)): >We want to have more user's experience and results from tests to determine how >we should make curl make uploads on windows as fast as possible. From Windows 2008 R2, Amsterdam, NL: Microsoft Windows [Version 6.1.7601] generating test file... running vanilla... start:0,484000 total:8,562000 running patched... start:0,484000 total:2,375000 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Windows users! Help us test upload performance tuning?
Daniel Stenberg in gmane.comp.web.curl.library (Thu, 2 Aug 2018 14:52:51 +0200 (CEST)): >We want to have more user's experience and results from tests to determine how >we should make curl make uploads on windows as fast as possible. Windows 7, from Amsterdam, NL Microsoft Windows [Version 6.1.7601] generating test file... running vanilla... start:0,531000 total:9,657000 running patched... start:0,546000 total:2,684000 -- Jan --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
