MSiebenschuh
Well Known Member
RE: Queue\'s getting backed up (long)
We had this same problem months ago and I thought it was just due to not
running enough queues or using them properly so I put out a similar request.
I got a lot of great answers on queues in general but nothing that solved my
problem of users waiting up to an hour for a reprint of a PO. Here is what
we finally did and it has made a vast improvement of how our users view OW.
Here are all the pieces
1. We wrote a daemon that monitors the f986110 table.
2. We set all user JDE.INI's to point them to a queue called QWAIT
3. We created a new table called the f55999 that contains a listing of all
the jobs by version and environment but most importantly it includes 2 other
fields. One is called speed, the other is forced queue.
4. We created 6 ea - SHORT MEDIUM LONG queues along with a DEFAULT and a
POSTING queue
Here is the process
1. A user submits a job it goes into a queue called QWAIT.
2. The jobs sits in QWAIT with a permanent W status. (This isn't a valid
queue - meaning there is no queue running on the system called QWAIT)
3. The daemon sees a job in the queue QWAIT and finds out THE JOB, THE
VERSION and THE ENVIRONMENT
4. The daemon then looks up the job in the f55999 table to find out if it
goes to a short, medium, or long queue (or in the case of things like
posting jobs that must follow one another - into a forced queue AKA-POSTING)
5. For this example lets say the job goes to a SHORT queue. Now that the
daemon knows this it looks again at the f986110 table and finds out how many
jobs are waiting/processing in each of the SHORT queues (SHORT_1, SHORT_2,
etc) and then load balances accordingly. (i.e. if SHORT_1 thru SHORT_5 are
all in P status (thus no jobs backed up) it would know that this new job
needs to go to SHORT_6. If SHORT_1 thru SHORT_6 are all processing with
SHORT_1 thru SHORT_3 having a job in W status then our new job would go to
SHORT_4.)
6. The daemon now does a SQL command to update the f986110 table for our job
to use the correct queue.
7. The job runs lightning fast and the user can't get to the printer fast
enough.
Using this process we have seen 250+ jobs process in less than an hour and
that wasn't even close to loading the system. I haven't had the opportunity
to load test but as one of our users put it "yeah most of the other stuff in
OW needs work but I can't believe how fast my jobs move now!"
There are some keys to this process. You must have an up to date f55999
table. Meaning that you don't want a lot of jobs going to the DEFAULT queue
(the queue for all jobs that the daemon doesn't find listed in the f55999
table). You also need to make sure that jobs are going to the right type of
queue. You don't want a long job backing up one of your short queues. It is
better to send "possibly" long jobs (based on user data selection maybe
going against the entire company rather than their branch or something along
these lines) to the LONG queues and have them run quickly rather than going
to a SHORT queue and taking an hour.
Hope this helps. It has sure saved our implementation of OW from being
totally despised by users. If anyone out there decides to use this config
please Email me and let me know. I would like to see just how useful this
has been to the community at large. Thanks.
300+ users, HP9000 with 12 procs.
Mark Siebenschuh
HP9000/Oracle/B733
[email protected]
We had this same problem months ago and I thought it was just due to not
running enough queues or using them properly so I put out a similar request.
I got a lot of great answers on queues in general but nothing that solved my
problem of users waiting up to an hour for a reprint of a PO. Here is what
we finally did and it has made a vast improvement of how our users view OW.
Here are all the pieces
1. We wrote a daemon that monitors the f986110 table.
2. We set all user JDE.INI's to point them to a queue called QWAIT
3. We created a new table called the f55999 that contains a listing of all
the jobs by version and environment but most importantly it includes 2 other
fields. One is called speed, the other is forced queue.
4. We created 6 ea - SHORT MEDIUM LONG queues along with a DEFAULT and a
POSTING queue
Here is the process
1. A user submits a job it goes into a queue called QWAIT.
2. The jobs sits in QWAIT with a permanent W status. (This isn't a valid
queue - meaning there is no queue running on the system called QWAIT)
3. The daemon sees a job in the queue QWAIT and finds out THE JOB, THE
VERSION and THE ENVIRONMENT
4. The daemon then looks up the job in the f55999 table to find out if it
goes to a short, medium, or long queue (or in the case of things like
posting jobs that must follow one another - into a forced queue AKA-POSTING)
5. For this example lets say the job goes to a SHORT queue. Now that the
daemon knows this it looks again at the f986110 table and finds out how many
jobs are waiting/processing in each of the SHORT queues (SHORT_1, SHORT_2,
etc) and then load balances accordingly. (i.e. if SHORT_1 thru SHORT_5 are
all in P status (thus no jobs backed up) it would know that this new job
needs to go to SHORT_6. If SHORT_1 thru SHORT_6 are all processing with
SHORT_1 thru SHORT_3 having a job in W status then our new job would go to
SHORT_4.)
6. The daemon now does a SQL command to update the f986110 table for our job
to use the correct queue.
7. The job runs lightning fast and the user can't get to the printer fast
enough.
Using this process we have seen 250+ jobs process in less than an hour and
that wasn't even close to loading the system. I haven't had the opportunity
to load test but as one of our users put it "yeah most of the other stuff in
OW needs work but I can't believe how fast my jobs move now!"
There are some keys to this process. You must have an up to date f55999
table. Meaning that you don't want a lot of jobs going to the DEFAULT queue
(the queue for all jobs that the daemon doesn't find listed in the f55999
table). You also need to make sure that jobs are going to the right type of
queue. You don't want a long job backing up one of your short queues. It is
better to send "possibly" long jobs (based on user data selection maybe
going against the entire company rather than their branch or something along
these lines) to the LONG queues and have them run quickly rather than going
to a SHORT queue and taking an hour.
Hope this helps. It has sure saved our implementation of OW from being
totally despised by users. If anyone out there decides to use this config
please Email me and let me know. I would like to see just how useful this
has been to the community at large. Thanks.
300+ users, HP9000 with 12 procs.
Mark Siebenschuh
HP9000/Oracle/B733
[email protected]
