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.
我的问题是指加载过程中OpenSSL的加密成本,问题在于:当使用基于IMAP4的SSL(使用我们编写的应用程序,某种IMAP4代理)时,我们以两种不同的方式获取消息:1。完整取。 2.部分获取(获取块)。就应用程序而言,部分提取和完全提取的第一个块几乎等同于努力。然而,发生的事情是,当将数据发送回客户端(整个机构或仅仅是一大块)时,由于SSL加密,我们会得到荒谬的响应时间。我们清楚地看到,数据越大,OpenSSL加密它所需的时间就越多(线性与大小呈线性关系,而完全与部分相比则表现得非常漂亮。问题不在于需要更多时间,而在于它的绝对时间需要)。它将我们带到一种情况,即80k的完全提取可能导致7秒的响应时间(而不使用SSL时仅超过1秒)。有没有人遇到过类似的问题?这样的开销是否有可能是现实的?有没有人有想法将数据加速回客户端(不添加外部加速器)?谢谢。
1 个解决方案
#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.
既然你提到你的产品是你写的代理,我首先会看看问题是否与Nagle的算法有关。当我看到插座性能下降时,这是我检查的第一件事。基本上,您需要确保在程序中的正确位置编写和刷新数据。如果做错了,默认情况下,在发送数据之前会有0.2秒的延迟。这些延迟很快就会增加,特别是在频繁的小请求期间。
#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.
既然你提到你的产品是你写的代理,我首先会看看问题是否与Nagle的算法有关。当我看到插座性能下降时,这是我检查的第一件事。基本上,您需要确保在程序中的正确位置编写和刷新数据。如果做错了,默认情况下,在发送数据之前会有0.2秒的延迟。这些延迟很快就会增加,特别是在频繁的小请求期间。