| Author |
Message
|
| jhidalgo |
 Posted: Wed Mar 17, 2010 3:06 pm Post subject: Performance implications of SSL channels |
 |
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
Does anyone have an idea of the impact in CPU of implementing SSL encryption on MQ's channels ?
I will depend on the number of messages, size of the keys, etc.. but obviously this is about estimates, I haven't found any estimate tables or anything.
Thanks. |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Mar 17, 2010 3:14 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
It will also depend on the number of channels...
...the choice is to up the spec of the box on which the queue manager is running, or offload it onto a dedicated crypto box, which of course there are multiple flavours/vendors available 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 18, 2010 2:23 pm Post subject: Re: Performance implications of SSL channels |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jhidalgo wrote: |
| I will depend on the number of messages, size of the keys, etc.. but obviously this is about estimates, I haven't found any estimate tables or anything. |
It depends on so many things that it is not that useful to produce tables. Similar story with most software generally, I'm afraid. You really need to try it on the hardware and networks you intend to implement on, then you'll have some "real" data and can make more confident decisions. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 18, 2010 4:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
It's a question frequently asked by management, and has some validity.
The real question should be: what is the risk of compromised business data from not securing message channels? The one thing that an organization cannot adequately insure against loss is business data.
One of my clients came to understand that 80% of their revenue came from the top 20% of their customers. Disclosure of this valuable customer data to competitors would destroy the company.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Mar 18, 2010 11:19 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
It's a question frequently asked by management, and has some validity.
The real question should be: what is the risk of compromised business data from not securing message channels? The one thing that an organization cannot adequately insure against loss is business data.
One of my clients came to understand that 80% of their revenue came from the top 20% of their customers. Disclosure of this valuable customer data to competitors would destroy the company. |
Good point, and well made. Still, I never cease to be amazed at companies that are paranoid about having 'internal' in-transit message traffic secured, but do nothing about securing at-rest messages. I suspect that for every person authorised to put a packet sniffer on a network, there are at least ten authorised to a queue manager/queue. And with the advent of V7.0 and the ability to 'duplicate' any given message natively, it becomes even more important that a more holistic view is taken of WMQ security.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Mar 19, 2010 4:36 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| The real question should be: what is the risk of compromised business data from not securing message channels? |
The OP asked about performance of SSL channels. That question is real enough. Why redirect on to another "real" question? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 19, 2010 5:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Because SSL's impact on cpu, and overall throughput, is marginal (unless the environment is horribly configured).
Yes, the OP asked about SSL's impact on cpu usage; but that doesn't preclude broadening the discussion to focus on the business-driven decisions that likely prompted the question. Saving cpu cycles is not, and should not, be a driving force in deciding whether or not to SSL.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Mar 19, 2010 7:04 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| Because SSL's impact on cpu, and overall throughput, is marginal (unless the environment is horribly configured). |
Or (to be a bit less colourful) maybe it is just resource-constrained. Which means assessing performance impact of any change is necessary. To avoid finding after implementation that SLAs etc. are being broken.
It would be better to find out before deployment that new hardware is needed, not after.
SSL with MQ has different cipherspecs that have different implications for encryption, and higher encryption means higher CPU. If running 1 channel with increased CPU, this will have less impact than (say) running 100 channels concurrently each with increased CPU.
In short, you can't say it is marginal unless you have measured the particular system. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 19, 2010 7:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Of course, I agree with that. My point is that zeroing in on the impact of SSL cpu utilization to the exclusion of all else is a micro-discussion.
So, if cpu increases by 2% or 5%, will this be a show-stopper for SSL?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 19, 2010 7:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| So, if cpu increases by 2% or 5%, will this be a show-stopper for SSL? |
Potentially. I've worked for clients who saw not meeting SLA as a bigger risk than data loss / theft. As exerk indicated above, if the proposed SSL is being added to an internal system already subject to security controls it's a reasonable point to place a higher priority on performance. Espcially in a tight SLA environment.
It's all about context. And as mvic correctly pointed out, the overhead is so variable it has to be viewed on a case by case basis. Where the case includes vunerability of the data, impact of data loss, tightness of SLA, existing security controls, etc, etc, etc.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Mar 19, 2010 7:34 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| So, if cpu increases by 2% or 5%, will this be a show-stopper for SSL? |
1. I don't know if it'll be 2-5 pc on your box.
2. I don't know if 2-5 pc on your box will make the difference between meeting an SLA and not meeting it.
People who discuss performance are not necessarily ignoring the other valid requirements. It was performance the OP asked about, and so that's what the answers are about.
I agree with your mentioning that SSL is vital in some systems for data privacy/security. It was just that you declared that that was the "real" question. I think that both questions are real. |
|
| Back to top |
|
|
|
|
