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
