Subject: gnutls vs openssl performance - msg#00002

Previous Message by Date:

Feature request: LIST -a for recursive deleting, listing via STAT -l

Hi, it's nice to see that gnutls is now working well, and that a full-featured version of lftp is in debian again. I have two feature requests for the future: - Use LIST -a when getting dirlisting for recursive deleting. This is somewhere between a bug report and a feature request. When doing "rm -r Directory", lftp will dive into the dir and do LIST there and in all subdirs. Then it will delete the files reported by LIST and then RMD the directories. However, if the dir contains hidden files like ".message", these will not be reported by LIST, therefore not deleted, and RMD will fail with something like: rm: Access failed: 550 Test_Directory/: Directory not empty. Not sure if all ftp servers can handle LIST -a - maybe make this behavior configurable? - Support listing via STAT -l Normal dir listing via LIST will require a new connection to be made. However, most ftp servers (proftpd, vsftpd, glftpd, openftpd...) support dirlisting on the control connection, by sending STAT -l Clients like FlashFXP, UltraFXP, pftpfxp support it. Listing via STAT -l is much faster. Even more when SSL is used, since no separate SSL handshake is required for each dirlisting. It also allows dirlisting when the firewall permits absolutely no other connections than the control connection. Maybe this could be implemented as an optional feature (e.g. ftp:listing-via-stat) bye & thanks for lftp, Tillmann

Next Message by Date:

Re: gnutls vs openssl performance

Tillmann Steinbrecher wrote: Hi, I was quite enthusiastic when I heard that lftp supports gnutls now. However: With gnutls: Transfer speed with ssl max 1.1MB/s, 100% CPU usage With openssl: Transfer speed with ssl max 7.0MB/s, 60% CPU usage Is gnutls generally slow, or is it related to the gnutls implementation in lftp? bye, Till Well, it's quite important to understand that openssl is really heavily optimized, which I haven't seen so much in gnutls. These performances doesn't surprise me much.

Previous Message by Thread:

Feature request: LIST -a for recursive deleting, listing via STAT -l

Hi, it's nice to see that gnutls is now working well, and that a full-featured version of lftp is in debian again. I have two feature requests for the future: - Use LIST -a when getting dirlisting for recursive deleting. This is somewhere between a bug report and a feature request. When doing "rm -r Directory", lftp will dive into the dir and do LIST there and in all subdirs. Then it will delete the files reported by LIST and then RMD the directories. However, if the dir contains hidden files like ".message", these will not be reported by LIST, therefore not deleted, and RMD will fail with something like: rm: Access failed: 550 Test_Directory/: Directory not empty. Not sure if all ftp servers can handle LIST -a - maybe make this behavior configurable? - Support listing via STAT -l Normal dir listing via LIST will require a new connection to be made. However, most ftp servers (proftpd, vsftpd, glftpd, openftpd...) support dirlisting on the control connection, by sending STAT -l Clients like FlashFXP, UltraFXP, pftpfxp support it. Listing via STAT -l is much faster. Even more when SSL is used, since no separate SSL handshake is required for each dirlisting. It also allows dirlisting when the firewall permits absolutely no other connections than the control connection. Maybe this could be implemented as an optional feature (e.g. ftp:listing-via-stat) bye & thanks for lftp, Tillmann

Next Message by Thread:

Re: gnutls vs openssl performance

Tillmann Steinbrecher wrote: Hi, I was quite enthusiastic when I heard that lftp supports gnutls now. However: With gnutls: Transfer speed with ssl max 1.1MB/s, 100% CPU usage With openssl: Transfer speed with ssl max 7.0MB/s, 60% CPU usage Is gnutls generally slow, or is it related to the gnutls implementation in lftp? bye, Till Well, it's quite important to understand that openssl is really heavily optimized, which I haven't seen so much in gnutls. These performances doesn't surprise me much.