On Sat, Jan 05, 2013 at 12:26:04AM -0800, Ian Scott wrote:
> On Jan 5, 2013, at 12:06 AM, Willy Tarreau <[email protected]> wrote:
>
> > Did you get a significant performance gain with padlock ? I've not had
> > the chance to test one yet. I don't even know if it requires an engine
> > or not. At least with aes-ni, it's included in the native code, you
> > don't need the engine (and the perf gain is impressive, we achieved
> > 5 Gbps of AES256 per core).
>
> Hi Willy, thanks for that information. I get significant gains with padlock,
> and it does require the engine. On a VIA Nano 1.6GHz I get 600 Mbps of SSL
> throughput on a single connection vs. 240 Mbps without padlock (I'd probably
> get more as for some reason my "openssl speed" benchmark runs are slower than
> others I've seen online by a factor of 2x).
That's already a nice gain.
> The performance gain isn't much with many small requests, though.
This is common. In fact the public key handling is generally not well
accelerated by crypto devices (though padlock has a montgomery multiplier).
Also, the problem is that running AES or SHA1 on small messages generally
is quite fast in software, but here comes with the engine overhead. This is
the problem I noticed with mv_cesa. If I enabled only AES, it was slightly
better than software (a few percent but at least it reduced CPU usage). But
if I enabled SHA1, the results were something like twice as lower. Ideally
we'd need to have the choice to select whether to use hardware or software
depending on the message size. I don't know if SSL engines do that.
> That's interesting about AES-NI not requiring an engine. I'll be getting a
> machine that supports it next week.
You will surely be impressed.
> Perhaps padlock is the only practical use for engine support. I'm not sure
> how many people are clamoring for it.
I don't think that many people will ask for using padlock nowadays, because
commonly when you need SSL you're on a large site and not running on that
small a machine. Also, web sites are dominated by small objects. If you look
at demo.1wt.eu, you'll see that the average object size is around 27kB, and
this is a site which mainly proposes tar.gz files for download. At these
sizes, I doubt that you'll observe that much of a difference between software
and hardware.
Still I really want to bring engine support in haproxy because there are
valid use cases in my opinion. But what I want first is to be able to :
- configure precisely what algorithm goes to the engine (or to what
engine)
- enable or disable engine usage per frontend and per backend
The last point is important because if you're encrypting your backups
via haproxy, you'll probably want to use the engine. But at the same time
you'd rather not use it to encrypt https nor to offload some RDP encryption
because you'd rather let this run at low latency.
Regards,
Willy
