On 01/18/13 10:17, Philip Brown wrote:
On 01/18/13 09:53 AM, Shawn Walker wrote:
libcurl uses libopenssl, which as far as I know, automatically uses
the crypto acceleration available.
I'm uncertain why Python would be implicated here.
If this is truly a crypto acceleration issue, then the same issue
should show up with curl.
Perhaps more data is required before analysis can be performed.
Fair enough. I'm happy to run some timing tests, if you can provide me with
1. a suggested large file target url for SSL speed testing
I'd suggest using the find utility to find the largest file in a
repository's publisher directory; they'll be named like this:
'00fe950a74bb641431343ea8d7848222bb402709'. And should be in a
directory like '$repo/publisher/solaris/file/xx/'.
You can then retrieve the file with something like:
https://$repo/file/0/$filename
2. command line invocation options to more directly test
python/libcurl/whatever else needs to be compared
Use curl's standard options; there's nothing special.
However, I would also mention that in general, amd64-based systems will
have better single-threaded performance for pkg(5). Your earlier test
was not so much a test of transport performance as it is the client's
ability to parse and store json data.
A simple DTrace script that just tallied the amount of execution time
required for every function called during an execution of pkgrepo should
be enough to corroborate.
I suspect that if you did that, you'd see immediately that transport was
unlikely to be the source of the performance difference.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
