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
>
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:
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
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
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
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
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:
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
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
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...
--
/
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
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
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)
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
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:
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
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
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
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
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
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
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
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
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
---
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
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
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,
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
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
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
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
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
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 -#
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}" ^
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
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
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
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
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
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:
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
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
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.
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
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:
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.
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
>
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
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?
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
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.
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
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
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
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
, 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:
> runnin
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
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
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
>>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
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
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.
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
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...
> -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 P
> -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
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
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
82 matches
Mail list logo
