Swift SSL performance

Great writeup. Thanks for sharing it.

I would recommend one additional test that may dramatically alter your recommendations. You should test multiple concurrent clients.

How do you configurations respond in the face of bad clients (eg https://github.com/notmyname/ssl_eventlet_slowloris)? I suspect this will show that it is impractical to run ssl directly on the swift proxy server and you should use an external ssl terminator.

How do the various reverse proxies respond on large uploads? Since nginx spools the data to disk, I suspect this will show that the box running nginx can quickly become overwhelmed in the face of a lot of concurrent uploads (especially when each of them may be several GB in size).

Hi John,

Many thanks for your feedback.

I think multiple clients/bad clients/large uploads are all interesting places to go, but
assuming we leave them for another day, I think there are some wins to be identified
with the existing data - irrespective of how you terminate SSL on the server, eg

* selective client side disabling of SSL compression

If the user knows in advance that his object is not compressible (eg a .gz file) and
the swift client supported disabling SSL compression then the download bandwidth speed should
increase from ~17 MB/s to ~65 MB/s (around 400% faster).

* client side enabling of AES-NI

If the client host has a CPU which supports AES-NI and the swift client supported enabling
use of this, the then a further improvement from ~65 MB/s to ~110MB/s would result
(around 70% faster).

Typo: s/400%/300%

This question was expired because it remained in the 'Needs information' state without activity for the last 15 days.