| Author |
Message
|
| mvic |
 Posted: Thu May 08, 2008 8:05 am Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| KeeferG wrote: |
| NPMCLASS allows for messages to survive restart then that covers most failure scenarios for critical messages. The obvious one it doesn't cover is object corruption but using SAN greatly reduces this risk anyway. |
Your message only benefits from NPMCLASS(HIGH) when it is sitting on a queue that has that setting. Messages spend time flowing between app and queue. Or between queue and queue (via a channel). These "transitional phases" are the times in which persistent messages are protected better than non persistent ones. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu May 08, 2008 9:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Gaya3 wrote: |
If there is any mismatch between the sender and reciever NPM attributes
chances of sequence errors are very high.
|
Not true. The running channel will negotiate what value it should use when both sides are different for a common attribute, like message speed or heart beats. What it ends up choosing is documented in the manuals.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 08, 2008 9:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| most critical messages are put under syncpoint (or should be for performance) |
Syncpoint is related to reliability, not performance.
| Quote: |
| The obvious one it doesn't cover is object corruption but using SAN greatly reduces this risk anyway. |
Object corruption is object corruption, whether on a SAN or a local disk.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu May 08, 2008 9:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| KeeferG wrote: |
| On a similar vein for LogWriteIntegrity. SINGLE v TRIPLE on a SAN. |
You can probably use Single. See this link for a detailed discussion on this and other related topics:
http://www.ibm.com/developerworks/websphere/library/techarticles/0712_dunn/0712_dunn.html
All my channels are NPMSPEED = Normal. We have one app whose performance requirements are so tight that they couldn't tolerate any slowdowns related to channels. We found that the MCAs were writing to disk for their batch info logging even for just non persistent messages. If there was any delay in writing to the SAN, and sometimes there is just for a second or so, it would cause the channel to slowdown for a second. So we made a seperate set of channels for this app and made sure they only send NP messages. DISCINT was set to 4 days to make sure even over a long weekend the channels didn't go to INACTIVE, requiring the overhead of triggering for the first message.
In the lab I started sending tons of NP messages over these fast channels. We then pulled out the fiber cable to the SAN and everything kept flowing!  I then dropped one little persistent message and everything stopped flowing, as the channel at that point needed to log the persistent message.
I don't bother with the queue setting. The developers are confused enough already.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Thu May 08, 2008 9:31 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| Syncpoint is related to reliability, not performance. |
There is a relationship between persistent put speed and syncpoint options.
| Code: |
Put(persistent)(syncpoint)
Put(persistent)(syncpoint)
Put(persistent)(syncpoint)
Put(persistent)(syncpoint)
Put(persistent)(syncpoint)
Commit |
... can go faster than ...
| Code: |
Put(persistent)(no-syncpoint)
Put(persistent)(no-syncpoint)
Put(persistent)(no-syncpoint)
Put(persistent)(no-syncpoint)
Put(persistent)(no-syncpoint) |
... because of optimizations within the queue manager.
What effect syncpoint/no-syncpoint choice has on non-persistent messaging I am not sure. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 08, 2008 9:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| mvic wrote: |
| ... can go faster than ... |
WILL go faster. Definitly the way to go if you are trying to eek out every millisecond for persistent messaging.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 08, 2008 10:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
I stand corrected.
I should have said syncpoint is more related to reliability than to performance.
Yes, there is overhead (instruction path length) devoted to persistent messages (writing to log buffers), and syncpointing (maintaining pointers to uncomitted messages.
If absolute performance is the issue, look to WMQ on z/OS. Way more more horsepower, way more reliability, way more tuning knobs.
_________________
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 |
|
|
| KeeferG |
| Posted: Fri May 09, 2008 12:08 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Cheers guys,
It looks like we may be rebuild our queue managers to get better performing logs to improve persistent performance as the message sizes are quite small and as a result the first 1000 may never get written to disk due to our DefaultQBufferSize. I really can't be bothered in changing the DefaultQBufferSize for each critical queue to ensure messages hit the disk. Not until it is a public parameter of the queue anyway so for now at least we shall look at persistence. In development at least.
As an aside, being a performance person I never like messages on queues. It slows eveything down too much.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 09, 2008 5:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...being a performance person I never like messages on queues. It slows eveything down too much. |
Interesting observation. The same can be said for files in a file-system and data in a database.
_________________
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 May 09, 2008 5:54 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| Quote: |
| ...being a performance person I never like messages on queues. It slows eveything down too much. |
Interesting observation. The same can be said for files in a file-system and data in a database. |
I think KeeferG says this because a non-persistent message is passed more quickly to a waiting getter. A getter that comes along later and has to access the disk for its message gets it delivered a little bit slower than this. Because of the disk access. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 09, 2008 6:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| A getter that comes along later... |
When a message (persistent and non-) is mqput to a queue, it first lands in a buffer.
If the getting application is alive and mqgets it, it gets it from the buffer - not disk. For persistent messages, the message might be held in buffer until it can be comitted to the log (log buffer for z/OS). So, yes and no.
_________________
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 |
|
|
| KeeferG |
| Posted: Fri May 09, 2008 6:25 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
However,
If there is a waiting get process it skips the buffer completly and is passed directly to the waiting get, thus speeding up performance even more.
You can then check to see how many messages avoid the queue and if the ratio is too low, increase the number of waiting threads to improve throughput.
This is a technique that I have had to use on high performance systems for many years.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
|
|
