OpenSSL encryption takes a very long time on load

Question

Hi, My question refers to the encryption costs of OpenSSL during load, and here is the problem: When working with SSL over IMAP4 (using an application that we write, some kind of IMAP4 Proxy), we fetch messages in two different ways: 1. full fetch. 2. partial fetch (fetching chunks). The first chunk of the partial fetch and full fetch are almost equivalent in effort as far as the application is concerned. What happens, though, is that when sending the data back to the client (either the whole body or just a chunk of it), we get ridiculous response times due to the SSL encryption. We clearly see that the larger the data is, the more time it takes OpenSSL to encrypt it (linear to the size, and full vs. partial shows it beautifully. The problem is not that it takes more time, but the absolute time that it takes). It brings us to a situation in which full fetch of 80k may result in a 7 seconds response time (vs. just over 1 second when NOT using SSL). Has anyone ever come across a similar issue? Is there any chance that such overhead may be realistic? Does anyone have an idea for accelerating the data back to the client (without adding an external accelerator)? Thanks.

Answer 1

Since you mention you're product is a proxy which you've written, I would first look to see if the problem might be related to Nagle's algorithm. When I see socket performance drop through the floor, this is the first thing I check. Basically, you need to ensure your are writing and flushing data at the right points in your program. If you do it wrong, by default there will be a 0.2 second delay before the data is sent. These delays quickly add up, especially during frequent small requests.