| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Queue Emptying Unexpectedly |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Sep 07, 2009 9:40 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jshailes wrote: |
The messages are of trains moving around a rail network so we need to make associations between messages in order to create the journey. The process of creating this journey, calculating its lateness after each message, and various other info is costly on resources - currently approximately 500ms. These calculations are our bottleneck.
|
Until you know why it takes 500ms, don't bother with any solutions, like an app server.
If a remote DB is your bottleneck, putting this app on the mainframe won't help. You need to make the DB interface faster.
If you are peggging the CPU for 500ms on your tomcat server, then you need more CPU, either by adding more CPUs to the current box, moving to a new box with more CPU or having multiple boxes all pulling from the same queue.
If the 500ms is primarily waiting for disk I/O, you look there for solutions.
etc
etc
etc
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Sep 07, 2009 10:30 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Lots of places where the bottleneck (or bottlenecks) might be.
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Sep 07, 2009 1:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| jshailes wrote: |
The messages are of trains moving around a rail network so we need to make associations between messages in order to create the journey. The process of creating this journey, calculating its lateness after each message, and various other info is costly on resources - currently approximately 500ms. These calculations are our bottleneck.
I'm not all that interested in an interim, I need to get started on a long term solution. Was my reasoning of the app server reasonable? I'm just concerned about sharing resources - the separate processes need to share the same memory space - is this a feature of an app server? |
Maybe you need to look at it like a predictive event system.
Don't care about calculating every time... All I care about is the expected journey and times (that information (schedule) can be calculated well in advance).
The next thing I need is the checkpoints issuing the messages.
When I get the message it tells what checkpoint and what train and what time.
So all I need to do is match the checkpoint and train to the DB entry (unique key) and update the real time.
To know about problems you take the last 5 check points and show the expected (schedule) against updated real time. If there is a difference over the usual std deviation you have a problem .... including if you are missing the updated real time...
This decouples your prediction (building the schedule) from your updates and from your reporting. It frees up CPU for doing recalculations only when needed i.e. standard deviation less then discrepancy between real time and schedule...
If you restrict your on line DB to a 24 to 48 hours schedule, i.e. anything else goes to future or archive tables your current DB space should be restricted and allow for real fast operations.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
